Unpatched MS DoS in the wild

Hey Hey,

So this came across DailyDave this morning

Quote:

---

I have to assume its just "connect to a service, send it a lot of data".
I don't see why that wouldn't work against SP2. You can connect to services and send lots of data on SP2 as well.

Of course, it's irresponsible of Microsoft to not offer more information on what the vulnerability is, so that customers can be informed and protect themselves. Does anyone have the code itself so all the various IPS/IDS teams out there can provide solutions, and the free software community can devise free solutions? It was probably irresponsible not to allocate resources to the MSRPC development team that would have found and fixed this sort of thing long ago.

I really want to inject Ethereal into every process as a network shim, and have it throw away any packets it doesn't know how to parse. I think that'd be a neat tool for stopping this sort of thing. But then, I don't do defense, so I haven't allocated any resources to it.

-dave
P.S. "Use tons of memory and cause a temporary denial of service? Heck, my Windows machine does that all by itself!"

http://www.microsoft.com/technet/sec...ry/911052.mspx


Microsoft Security Advisory (911052)


Memory Allocation Denial of Service Via RPC

---

A few more emails joined suit.... containing the following links.

http://lists.virus.org/vuln-dev-0511/msg00006.html <-- the original public disclosure
and then the source code on FrSIRT -- http://www.frsirt.com/exploits/20051...vicelist.c.php

Dave also had these comments

Quote:

---

So if I understand this correctly, if you have an IDL of the format:
[in] int size;
[out] [size_is(size)] [string] wchar_t * outstring; //note the lack of an [in] here! (does the [string] matter? Dunno! Any array should work I
think...)

and you send size in as 0x10101010 you get a lot of allocation as it creates the output buffer. So function 0f in that same interface should work as well, as well as numerous thousands of other MSRPC functions that exist on every Microsoft platform.

This is probably not a problem they are going to be able to fix easily.
And it's probably a problem you can find in lots of different ways in lots of different endpoints, up to and including the most recent Windows platform. But I could be wrong, and if I am, I'm sure someone will point it out quickly. That's the great thing about having a real community look at these sorts of things, rather than having a vendor monopoly on security information.

---

Now I'm not a programmer... I can write code.. but I'm definately not a programmer.... Is there truth in what Dave says here? Could this affect a great number of things?

Anyways.. just throught I'd share.

Peace,
HT

Hey Hey,

Here's an update... I just wanted it to catch the attention of people who've already read this.. Again from the DailyDave list.

Quote:

---

This bug is much wider scoped than most people realize, a friend of mine found it when writing his muddle implementation a few months ago. You can trigger it about 12 different ways on Win2000 and at least 2 different ways on XP. The bug itself is pretty silly (oh noes! arbitrary malloc!), but you can use it to exploit out of memory conditions in other services.

On Windows XP SP2, one of the vectors is a function in the "Server"
service, accessible via the \BROWSER pipe.

---

Peace,
HT

Most excellent. I see here that MS claims that the threat is minimal at best for SP1 hosts and that SP2 hosts can go about their business without concern.

Cache that MS page because if Dastardly Dave is correct, the MS folks will quickly change the content.

Hey Hey,

Here's a quick follow-up that Dave posted today based on some of the discussions on his mailing list.

Quote:

---

Well, I can confirm (as can anyone in our Partner's program) that the srvsvc DoS works against up2date XP SP2, or at least, that it works against Justine's laptop. I'm fairly impressed with how well XP SP2 handles a memory overload attack. It chugs along even with no ram left quite well. I can only imagine they have all the ram they need to run explorer and the desktop pre-allocated and you can't kick it out. Things get pretty choppy, of course, but it's at least...viewable. I think a few processes died maybe. It's hard to tell.

So to sum up:
XP SP2 is vulnerable to a memory denial of service from remote anonymous users via named pipes or other MSRPC. This is a lopsided attack and not a simple memory leak - I don't have to send millions of bytes, just about a hundred, and the target allocates as much ram as I want it to and then gets "funny". I imagine this is more annoying (aka
catastrophic) if you're trying to run an Exchange server or something. I haven't tested on 2003 yet. That's next. :>

The srvsvc attack also works against the Win2K image I tested.

-dave

---

Just wanted to point out that Microsoft was again wrong and SP2 users are in harms way.

TH13: Got a copy of that page?

Peace,
HT