New type of DDoS attack: TCP protocol bug found in Windows

    Dear Habro readers, before going to the point I want to say right away that the author is not any hacker or malicious programmer exploring with a candle every dark corner of the driver or anything else software, so if this vulnerability is already known, then do not judge strictly, but rather advise the patch.

    So, in the process of debugging the protocol stack for MANET networks , where a modified TCP network connection of a radio network with a computer was tested via an Ethernet gateway, it was accidentally revealed that by incorrectly closing the connection by the client on the server side, it is possible to hold socket resources for an infinitely long time!

    It all started with this:


    The screenshot shows the TCP connection between the client 192.168.0.108 (Ethernet gateway) and the server 192.168.0.187 (OS Windows Vista).

    As you can see, if the sequence number was incorrectly specified in the FIN ACK packet of the client, the Windows server did not close the socket and did not release resources. An attempt to connect again from the same client port (source port 40400) to the server port (destination port 31000) was unsuccessful. The server persistently demanded an ACK in response to a new SYN from the client.

    At first, I decided that it was just some kind of bug on the side of the MANET stack (besides, of course, the wrong seqno in FIN ACK), but after analyzing the flow by sequence / acknowledgement numbers and repeating the same experiment for other ports, it turned out that yes, Windows ...

    Example of another server port (30000):



    Then, having rebooted the computer and repeated everything again. This time the client closed the connection, and the server listened to port 32000.



    The result is the same.

    Then the netstat team looked at the state of the sockets and were horrified ...


    The server keeps open sockets that have not been in nature for many hours !!!
    And most likely, only forced killing of processes or rebooting will save the situation, because obviously in the FIN_WAIT_2 state, Windows does not have a timer for the socket and it does not go into the TIME_WAIT state to clear the resources.

    Summary

    1. We kindly ask you to report the popularity of this vulnerability.
    If this is a newly discovered bug, then it threatens many network products on OS Windows.

    2. It would be interesting to investigate this problem on other servers and OS, primarily Linux.

    3. Learn network protocols!

    PS a
    day has passed since the day the problem was discovered - resources have been allocated so far ...

    Also popular now: