lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 09 Sep 2009 15:28:20 +0200
From: Fabian Yamaguchi <fabs@...urity-labs.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: TCP/IP Orphaned Connections Vulnerability

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@...urity-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.
________________________________________________________________________

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ