Re: Ncrack on exotic Windows-land

[Brandon Enright <bmenrigh () ucsd edu>]

On Thu, 25 Jun 2009 13:23:47 +0300 or thereabouts ithilgore
<ithilgore.ryu.l () gmail com> wrote:

...snip...
> the peer
> sends us the "Login incorrect" tcp segment and also sends a second
> FIN packet immediately after. What happens with Windows is that it
> will acknowledge the FIN packet with a pure ACK (as it should), but
> immediately after it will send to our peer an RST packet (which it
> shouldn't)!!

Hi ithilgore,

I'm glad (in a really screwed up way) that more than one person has seen
this behavior out of Windows.

In our scenario, we have a group on campus with a Windows Server 2003
box serving a bunch of clients, some of the OS X.  Requests to the
server (through horrible design of Microsoft software in use here) can
sometimes take more than 60 seconds.

What happens is that a OS X box makes a request, and doesn't get a
reply for 60 seconds.  After a minute it still wants to wait for the
answer but it doesn't need its half of the TCP session so it shuts it
down with a FIN that the server ACKs.  Later the server finally
responds with an answer, the OS X client gets it and ACKs, and as soon
as the server sees the ACK it sends a RST.

The end result is that OS X clients can't use the server when requests
take longer than 60 seconds because the server will RST it if it sees
an ACK after the client has closed the connection.

I have no idea why Windows sends the RST, it shouldn't.  The only
explanation I can come up with is that Windows doesn't support one-way
TCP connections.  When I saw this I muttered some anti-Windows,
anti-Microsoft slurs and threw my hands up in disgust.

Since this is affecting thousands of OS X users on campus we'd like an
answer as much as you.  If there is a solution, I'd guess that it is
some setsockopt() option to tell Windows the socket is allowed to be
single-channel.

Regards,

Brandon


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org