Topic: Windows setting URG value on certain SYN and RST packets Status: SOLVED This is a description of a mysterious Windows URG problem I've noticed a while ago, while working on p0f. It turned out to be memory leak, and Microsoft have acknowledged the problem. ---- FIRST MAIL ---- Date: Tue, 2 Sep 2003 14:09:08 +0200 (CEST) From: Michal Zalewski 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): 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 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 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 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 -- ---- SECOND MAIL ---- Date: Wed, 17 Sep 2003 11:17:16 +0200 (CEST) From: Michal Zalewski 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 --