Hey Hey,

So this came across DailyDave this morning

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

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