BUG: All http access blocked after running Perl script

[Mikko Noromaa]

BUG: All http access blocked after running Perl script

SUMMARY: Windows Vista blocks all http access from all users after running
the attached script (at the end of this post).

DESCRIPTION:

Create a file accessible at http://127.0.0.1/test.htm and run the attached
script. After about 12000-13000 fetches, the script starts reporting an
unknown error. After that, all http access on the computer is blocked on all
user accounts (after logging off and back on). When starting IE, it reports
an error immediately. I found no other way of fixing this than rebooting my
computer.

The problem can be reproduced by using any URL in the script, including a
real remote URL. The problem first occurred when I was running a real script
that fetched lots of real Web pages in a loop like the test script.

My guess is that either Perl is leaking some socket resources (and Vista
can't release them on process exit), or that Vista is somehow considering
the flood of http requests as an attack, and disabling http because of that.
It probably shouldn't disable http indefinitely, though. I have uninstalled
all anti-virus software and disabled the Windows Firewall, but the problem
persists.

Notice that the script was running without Administrative access, but it
still caused a systemwide problem.

TEST SCRIPT:

use strict;
use LWP::UserAgent;
my $n=1;
while (1) {
print "Fetching page $n...";
my $ua = LWP::UserAgent->new;
my $req = HTTP::Request->new(GET => "http://127.0.0.1/test.htm");
$req->header('Accept' => 'text/html');
my $res = $ua->request($req);
if ($res->is_success) {
print " OK!\n";
$n++;
}
else {
print " ERROR: " . $res->status_line . ".\n";
sleep 1;
}
}

 

[Mikko Noromaa]

Hi,

Yes, I am running the latest x86 version of ActiveState Perl (5.8.8. "with
50 registered patches").

There are no interesting messages in the Event Logs, but after the problem
appears, I start getting other strange errors as well. For example,
PostgreSQL starts rejecting new connections, and other network-related apps
fail. Also, the following is logged in the System log: "The DNS proxy agent
was unable to allocate 0 bytes of memory". Memory seems fine in Task Manager
(my computer has 3 GB installed). DameWare Mini Remote Control reports
"error 10013: An attempt was made to access a socket in a way forbidden by
its access permissions". Generally all socket-related operations seem to
fail (not just http).

I don't think this is a Perl problem because of the following reasons:

1. It only happens on Vista. XP runs the test script fine for hours.

2. The problem persists after Perl.exe has exited. Windows should release
all resources held by user-mode applications, shouldn't it? And especially
Vista should not let non-administrative programs affect other users.

3. The problem doesn't appear if I add a "sleep 1" in the test script and
run the script for hours. It only appears when many http requests are made
in rapid succession. This sounds like some kind of attack detection logic
that doesn't get properly reset.

Did you (or anyone else) reproduce the problem?

 

[Mikko Noromaa]

Hi,

Thank you for the info! I am running 32-bit Vista Business on a desktop
Intel Core 2 Quad. My perl -v reported the exact same version as yours.

My test.htm file is a simple 5-byte text file containing the string "abc".
And I just got an involuntary repro from my real script that does about 1.5
requests per second against a remote server...

If anyone else can confirm this bug, I'd appreciate the info. I think I'll
have to contact MS support on this one.

 

[Mikko Noromaa]

Hi,

I've found out some new information about the problem:

1. The Internet Connection Sharing (ICS) service seems to be the culprit.
The problem goes away when I stop this service. However, restarting brings
the problem back immediately.

2. While ICS is enabled, and my Vista computer is crippled, other computers
on my network can succesfully connect to the Internet through ICS.

3. I found several other posts on the net describing probably the same
problem. All of them pointed to ICS and described the same symptoms.
However, none of them offered any real solutions.

So this definately looks like some kind of badly broken "intrusion
detection" logic in the Internet Connection Sharing service. I hope someone
from MS is reading this and takes appropriate actions. Contrary to other
reports on the net, I believe I have a solid repro case (the Perl script in
the original post).

 

[Mikko Noromaa]

Thanks, I'll check if my real app has the same inefficiency.

 

[Chuck]

BUG: All http access blocked after running Perl script

SUMMARY: Windows Vista blocks all http access from all users after running
the attached script (at the end of this post).

OK, I'll bite.

What purpose does the script serve?

"If it hurts every time you poke yourself in the eye with a sharp stick
(AOHELL), the obvious solution is to quit poking yourself in the eye with a
sharp stick (AOHELL).

If you absolutely MUST poke yourself in the eye with a sharp stick (AOHELL),
then feel free to seek assistance from the maker of the sharp stick (AOHELL)."

 

[Mikko Noromaa]

What purpose does the script serve?

From my original post:

"The problem can be reproduced by using any URL in the script, including a
real remote URL. The problem first occurred when I was running a real script
that fetched lots of real Web pages in a loop like the test script."

Ever heard of Web spidering?

 

[Guest]

I also got this problem when using bittorrent, a webbrowser and an IM. All
http-traffic stops working and i lose contact with the trackers on
bittorrent, it says "an attempt was made to access a socket in a way
forbidden by its access permissions" but the transfers in bittorrent keep on
going. The IM also keeps working and I can ping www.microsoft.com.

It has happened three times in two days and I have had Vista business
installed since january 24th but I enabled ICS just a few days ago.

Resetting the network adapter doesn't work. I have now disabled ICS and I
just have to wait and see if that solved the problem.