Re: MSRPC vulnerability 1 billion and six?

[Dave Aitel <dave () immunitysec com>]

I was kinda thinking of the problem as something that affects a lot of 
non-Microsoft products. I can't think that limiting array sizes to 
anything arbitrary is a really good idea. It's one thing to go through 
as Microsoft and fix all your own code. It's another thing to have every 
3rd party piece of software have to go audit their's. So ideally you'd 
fix it in rpcrt right? But then that means you'd want to somehow be able 
to have vulnerable IDL's suddenly become invulnerable. You could have a 
hard limit on memory you'll allocate, or you could have some sort of 
heuristic based on ram.

I guess they have to memset(0) the stuff because it might get blindly 
passed to the client, which would be bad if someone else hasn't cleared it.

So I haven't thought of a GOOD solution. Maybe this is why everyone does 
inline parsers? :>

-dave

H D Moore wrote:
> The way MS has fixed this in the past is via range()'s, here is one that 
> was fixed in some early Windows 2000 SP:
>
>   long function_1f (
>     [in] [unique] [string] wchar_t * arg_00,
>     [in] [string] wchar_t * arg_01,
>     [out] [size_is(arg_03)] char * arg_02,
>     [in] [range(0, 64000)] long arg_03, <<<<<<<<<<<<<<
>     [in] [string] wchar_t * arg_04,
>     [in,out] long * arg_05,
>     [in] long arg_06
>   );
>
> -HD
>
> On Thursday 17 November 2005 16:56, Alexander Sotirov wrote:
>   
> > Dave Aitel wrote:
> >     
> > > Hmm. I guess one possible fix would be
> > > [size_is(size)] [out] * IDL's parsed to be a maximum of
> > > "freememory/2".
> > >       
> > This wouldn't help much, becase the memory is zeroed with rep stosd
> > after it is allocated. Not only does this consume 100% CPU for a while,
> > it also commits every allocated page and might force other programs to
> > get swapped out.
> >
> > Alex
> >