
Date: Wed, 17 Sep 2003 11:17:16 +0200 (CEST)
From: Michal Zalewski <lcamtuf@dione.ids.pl>
To: bugtraq@securityfocus.com, vulnwatch@vulnwatch.org
Cc: full-disclosure@netsys.com
Subject: Windows URG mystery solved!


I finally have more details about the Windows URG pointer memory leak,
first reported here:

  http://www.securityfocus.com/archive/82/335845/2003-08-31/2003-09-06/0

It is a vulnerability.

After a long and daunting hunt, I have determined that pretty much all
up-to-date Windows 2000 and XP systems are vulnerable to the problem, and
that it is not caused by any network devices en route or such, but the
issue is present only in certain conditions.

I have initially reported I see a minority population of systems
exhibiting this pattern. It turns out the majority of population is
vulnerable, simply not exhibiting this behavior all the time.

It is exhibited whenever a data transfer is occuring at the time the
initial SYN is sent. The URG value would often contain a random piece of
a packet (frequently data) belonging to the other connection.

This happens during regular browsing, and will also be triggered by
background downloads, etc.

I do not want to exaggerate the impact of this vulnerability, the amount
of data disclosed is fairly low, but it's still quite cool.

Cheers,
--
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-09-17 10:44 --






Date: Tue, 2 Sep 2003 14:09:08 +0200 (CEST)
From: Michal Zalewski <lcamtuf@coredump.cx>
To: vuln-dev@securityfocus.com
Cc: vulndiscuss@vulnwatch.org
Subject: certain versions of Windows XP leaking memory in TCP packets?


Hello list,

While writing the new version of my passive oS fingerprinting tool, p0f
(no, this time, it's not a shameless plug), I was trying to come up with a
number of new metrics that can be used for this purpose. One of the ideas
was to look for glitches such as non-zero values in sections of the packet
that are irrelevant and should be zeroed, in particular the ACK value in
SYN packets with no ACK flag set, and URG pointer in SYN packets with no
URG flag set.

This and several other "quirk checks" turned out to be quite useful. I
kept running p0f on one of the servers, and found out there is a sizable
(but minority) population of what looks like Windows XP systems that
appear to be setting URG pointer in SYN packets with no URG flag to values
that seemed to be random (whereas other devices that had this "feature",
were using a fixed value, such as 0xcccc), but sometimes repeated in two
subsequent connections from the same source.

Quite unfortunately, none of those machines ever visited my signature
submission page at http://lcamtuf.coredump.cx/p0f-help/, so I do not have
any detailed configuration information and couldn't perform more detailed
checks, so I'm just posting it here for your consideration and eventual
testing. Here's a sample (observe URG value):

<Tue Sep  2 13:02:48 2003> A:3827 - Windows XP (2) (PLEASE REPORT!) [GENERIC]
  Signature: [16384:119:1:48:M1460,N,N,S:U:Windows:?]
  -> server:80 (distance 9, link: ethernet/modem)
  -- EXTRA TCP VALUES: ACK=0x0, UNUSED=0, URG=0x819e

<Tue Sep  2 13:02:48 2003> A:3829 - Windows XP (2) (PLEASE REPORT!) [GENERIC]
  Signature: [16384:119:1:48:M1460,N,N,S:U:Windows:?]
  -> server:80 (distance 9, link: ethernet/modem)
  -- EXTRA TCP VALUES: ACK=0x0, UNUSED=0, URG=0xdc19

<Tue Sep  2 13:02:49 2003> A:3830 - Windows XP (2) (PLEASE REPORT!) [GENERIC]
  Signature: [16384:119:1:48:M1460,N,N,S:U:Windows:?]
  -> server:80 (distance 9, link: ethernet/modem)
  -- EXTRA TCP VALUES: ACK=0x0, UNUSED=0, URG=0x8158

<Tue Sep  2 13:02:49 2003> A:3833 - Windows XP (2) (PLEASE REPORT!) [GENERIC]
  Signature: [16384:119:1:48:M1460,N,N,S:U:Windows:?]
  Signature: [16384:119:1:48:M1460,N,N,S:U:Windows:?]
  -> server:80 (distance 9, link: ethernet/modem)
  -- EXTRA TCP VALUES: ACK=0x0, UNUSED=0, URG=0x8158

Now, my immediate quess would be that this Windows box is leaking the
contents of some previously sent packets by not zeroing the buffer used to
construct a new packet completely. It's less likely, but not impossible,
that this URG value is set by some network device or is not related to the
previous packet.

Any ideas? Or perhaps you have any XP boxes to point to
http://lcamtuf.coredump.cx/p0f-help or
https://coredump.cx:443/~lcamtuf/p0f-help/ to submit configuration
details and help me find out which systems are affected and why?

Thanks,
--
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-09-02 13:26 --

