exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Microsoft TCP/IP Orphaned Connections

Microsoft TCP/IP Orphaned Connections
Posted Sep 10, 2009
Authored by Fabian Yamaguchi | Site recurity-labs.com

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.

tags | advisory, remote, tcp
systems | windows
advisories | CVE-2009-1926
SHA-256 | 15a60a5f477e09ee40822768593559d188cfaca8a7a7e280c79b97103571951d

Microsoft TCP/IP Orphaned Connections

Change Mirror Download
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@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.
________________________________________________________________________
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close