MS09-048 is Microsoft's Revenge Against XP in the Enterprise

MS09-048 worries me.

Non-Affected Software

Operating System

Windows XP Service Pack 2 and Windows XP Service Pack 3*

How are default configurations of Windows XP not affected by this vulnerability?

By default, Windows XP Service Pack 2, Windows XP Service Pack 3, and Windows XP Professional x64 Edition Service Pack 2 do not have a listening service configured in the client firewall and are therefore not affected by this vulnerability. For the denial of service to succeed, an affected system must have a listening service with an exception in the client firewall. Windows XP Service Pack 2 and later operating systems include a stateful host firewall that provides protection for computers against incoming traffic from the Internet or from neighboring network devices on a private network.

Someone please tell me I am misinterpreting this. It looks to me like this is bad news for the enterprise that operates any listening services on their Windows XP systems. Oh, I don't know, maybe something like Microsoft SMB/CIFS? In other words, if you expose a service within the enterprise, and you allow other systems to connect to it, then you are vulnerable to MS09-048 -- and Microsoft isn't publishing a patch for XP SP2 or XP SP3?

What's worse is that I can't tell if XP SP2 or SP3 is vulnerable to this vulnerability in MS09-048:

TCP/IP Timestamps Code Execution Vulnerability - CVE-2009-1925

A remote code execution vulnerability exists in the Windows TCP/IP stack due to the TCP/IP stack not cleaning up state information correctly. This causes the TCP/IP stack to reference a field as a function pointer when it actually contains other information. An anonymous attacker could exploit the vulnerability by sending specially crafted TCP/IP packets to a computer that has a service listening over the network. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

So, at best we have an unpatched vulnerability that lets anyone in the enterprise remotely crash any XP SP2 and XP SP3 system with at least one listening service (139, 445 TCP) that the attacker can reach. At worst we have an unpatched vulnerability that lets anyone in the enterprise remotely exploit any XP SP2 and XP SP3 system with at least one listening service (139, 445 TCP) that the attacker can reach.

Does anyone know if TCP/IP Timestamps Code Execution Vulnerability - CVE-2009-1925 applies to XP SP2 or XP3?

Incidentally, running Microsoft Update on a Windows XP SP3 system does not show a patch for MS09-048 as available.


Unknown said…
Richard, thank you for posting this. I first read the MS08-048 bulletin and correctly alerted my team that this affects XP. Later in the day, I re-read it and got confused in that XP was listed in the non-affected category.

But my first read, and yours, is correct. Microsoft is just playing dumb by saying a default config has no listening services...but once a user gets on the system, it basically ends up with listening services almost without exception.

But your second question is very valid, and I wish I knew the answer. Basically, is XP then vulnerable to just a DOS or also the remote code exec?
Anonymous said…
It is a confusing bulletin. The bulletin mentions DoS and potential code execution, but the latter is only relevant to CVE-2009-1925.
If you look at the "Vulnerability Severity Rating..." table you'll see that CVE-2009-1925 does not affect 2000, and 2003. I suppose this means that the vulnerability appeared on newer code introduced in Vista.

MS09-048 should still apply to XP for the two other DoS vulnerabilities and the reasons you mention.
Roman said…
Does anyone have a link to the actual details of how this is exploited? I'd like to bang this against a couple XP boxes in our lab. All the stuff I'm coming up with is related to the media circus that went around prior to the talk on 17 Oct of last year.
Brad said…

Not sure if it really sheds light on much, but hopefully if people ask more questions they will post some follow-ups on the MS SRD blog.
Anonymous said…
Is it correct that the vulnerability only manifests itself when you have configured a listening service in the firewall, and when the firewall service is operational? I get the impression you're equating a listening service independent of the firewall with the vulnerability.

I don't know if I agree with you regarding the revenge factor. Most large enterprises I have worked in don't use the Windows XP firewall (the 275,000 seat enterprise I work in now uses a 3rd party product). Microsoft probably knows this and while I like to vilify Microsoft whenever possible, I am not convinced that this particular circumstance is "part of the plan". If the vulnerability is only present when the firewall is configured and active, then I would suggest that not as many enterprises as one would suppose would be vulnerable.
Anonymous, I think you have it backwards. Microsoft is not publishing an XP patch BECAUSE it assumes the "default config" has Windows Firewall denying inbound connections. Without Windows Firewall or any firewall denying all inbound connections to listening services, XP appears to be at least vulnerable to the DOS conditions.
Unknown said…
Thanks for the link, Brad.

The blog mentions Toeplitz hash while talking about CVE-2009-1925.

The mention of hashing could be a clue that the vulnerability has its roots in RSS (Receive side scaling).

Here is my take on it. (Wild guess)

1. The hash is used by RSS to map flows to processors.

2. The hash is not the cheapest to compute. So it is calculated only if a listening service in userland responds to an incoming packet (eg, TCP syn). This explains the note by Richard that you need an exposed listening service. Any service will probably do.

3. Once computed for a flow the hash is probably stored in the TCP state structures. Since the hash always maps a TCP flow to the same value, looking up the precalculated hash presents opportunity for an optimization.

4. It might be possible to overflow the TCP control structures (TCBs) and the mapped hash values in such a way that will result in the lookup of an invalid hash. This might bugcheck because it trips in the kernel. Hence the system DoS.

This does not explain the role of TCP Timestamps in this exploit. Also no idea how it could be used for RCE.

What do others think ?
The bulletin has been updated to clarify that XP is affected, and that it recovers when the attack stops.

No further mention that they won't be patching or why.
Anonymous said…
I'd like some clarification on the "listening service" caveat: in my network, all XP machines have Windows Firewall enabled. The only exception is a incoming rule that allows the AVG server to connect to to TCP 4158. Would this allow any host to exploit this vulnerability or would the firewall drop the packets before it could be exploited?
Anonymous, my understanding is that, unless the AVG server launched the attack, your hosts could not be reached and would therefore not be exposed to the DoS attacks.

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia