|
|
|
|
| |
Credit:
The information has been provided by Fabian "fabs" Yamaguchi and Bernhard "bruhns" Brehm.
The original article can be found at: http://www.recurity-labs.com/content/pub/Microsoft_Windows_CVE-2009-1926_MS09-048.txt
|
| |
Vulnerable Systems:
* Windows Vista Business SP1
* Windows XP SP3
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.
Patch Availability:
Microsoft has published an Security Bulletin to address this issue:
http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx
CVE Information:
CVE-2009-1926
Disclosure Timeline:
09.12.2008 Initial notification sent to MSRC
09.09.2009 Microsoft releases MS09-048
|
|
|
|
|
