________________________________________________________________________ Recurity Labs GmbH http://www.recurity-labs.com entomology@recurity-labs.com Date: 09.09.2009 ________________________________________________________________________ Vendor: Microsoft Corporation Product: Microsoft Windows XP/Vista TCP/IP-Stack Vulnerability: TCP/IP Orphaned Connections Vulnerability Affected Releases: Windows Vista Business SP1/ Windows XP SP3 Severity: Moderate CVE: CVE-2009-1926 ________________________________________________________________________ Vendor communication: 09.12.2008 Initial notification sent to MSRC 10.12.2008 Response from MSRC case manager - The report is being investigated. 23.12.2008 Recurity Labs would like to know whether MSRC considers this a vulnerability. If not so, Recurity Labs would like to mention the issue in an upcoming talk on TCP Denial Of Service vulnerabilities at the 25th Chaos Communication Congress (25C3). 28.12.2008 Recurity Labs agrees not to mention the issue until MSRC has has a chance to classify it. 09.01.2009 MSRC case manager asks for a copy of the presentation-slides. 13.01.2009 Vulnerability is classified as a 'Moderate' DoS by MSRC. 26.02.2009 Update on the issue by MSRC - A fix is scheduled for May or June. 27.03.2009 Update on the issue by MSRC - The fix is still scheduled for June. 08.05.2009 Update on the issue by MSRC - The fix is delayed to August. 29.07.2009 Meeting the MSRC case manager at BlackHat USA and getting a t-shirt. Thanks, nice move. 05.08.2009 Update on the issue by MSRC - The fix is ready but issues arose during testing. The release is rescheduled. 09.09.2009 Microsoft releases MS09-048 ________________________________________________________________________ Overview: The TCP/IP-Stack of the Microsoft Windows XP/Vista Operating System is vulnerable to a remote resource exhaustion vulnerability. By taking advantage of this vulnerability, an attacker can cause a connection's Transmission Control Block (TCB) to remain in memory for an indefinite amount of time without the need for the attacker to further maintain the connection's activity. Description: The vulnerabilities exist in the implementation of TCP's flow-control mechanism, in particular due to incorrect handling of advertised "zero-windows". Zero-windows may be advertised by a TCP after a connection enters the "ESTABLISHED" state to indicate that it is currently not able to accept any data due to limited buffer-space. Given that pending data exists, which the peer TCP needs to deliver, the peer then starts its persist-timer, which periodically queries the value of the flow-control window by issuing so called zero-window-probes. These probes are TCP segments containing a single byte of payload, which force the receiver to generate an acknowledgment, which in turn allows the peer to receive an update on the current value of the flow-control window. As a side effect, the retransmission-timer is disabled because persist- and retransmission-timer are mutually exclusive. The sending TCP is said to be in persist-state. In Windows XP and Windows Vista, connections, which are in the state "FIN_WAIT_1" or "FIN_WAIT_2" respectively do not ever terminate if the flow-control mechanism is in "persist-state". This can be demonstrated as followed: 1. The Attacker establishes TCP-connection with the target. 2. The Attacker sends a specially crafted TCP-segment to the target. The segment must fulfill the following criteria: a) The advertised flow-control window is set to zero. b) If the layer5-application that is in possession of the socket associated with this connection does not automatically send data to the attacker, the segment needs to cause the application to do so. c) To increase the attack speed, the segment-data should cause the layer-5 application to terminate the connection as soon as possible. For example, if the layer-5 application is a web-server, a GET-Request, which references a non-existing resource, is a good choice. When targeting the NetBIOS Session Manager (port 139), simply sending an invalid request such as 'abc\n' is sufficient. 3. Since the layer-5 application closes the socket associated with the connection in response to the attacker's request, the connection moves into state "FIN_WAIT_1" and is now handled only by the kernel. In addition, due to the zero-window advertised by the attacker, the flow-control mechanism enters "persist-state" and now sends the remaining data to the application one byte at a time by using zero-window-probes. 4. The attacker acknowledges zero-window probes. 5. Once no more data is left to send, the connection hangs in "FIN_WAIT_1" and is not removed. In case of Windows Vista, the last zero-window-probe sent also contains a FIN-flag, which, when acknowledged, moves the connection into "FIN_WAIT_2", where it hangs. Solution: Microsoft has published an Security Bulletin to address this issue: http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx ________________________________________________________________________ Credit: The vulnerability was found by Fabian "fabs" Yamaguchi and Bernhard "bruhns" Brehm, Recurity Labs GmbH. Greets to the teams at Recurity Labs and Zynamics. ________________________________________________________________________ The information provided is released "as is" without warranty of any kind. The publisher disclaims all warranties, either express or implied, including all warranties of merchantability. No responsibility is taken for the correctness of this information. In no event shall the publisher be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if the publisher has been advised of the possibility of such damages. The contents of this advisory are copyright (c) 2009 Recurity Labs GmbH and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. ________________________________________________________________________