Hi,
concerning MS09-048 and in particular CVE-2009-1926, we would like to
publish the following advisory:
http://www.recurity-labs.com/content/pub/Microsoft_Windows_CVE-2009-1926_MS09-048.txt
regards,
Fabian "fabs" Yamaguchi, Recurity Labs GmbH
________________________________________________________________________
Recurity Labs GmbH
http://www.recurity-labs.com
entomology@xxxxxxxxxxxxxxxxx
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.
________________________________________________________________________
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/