Re: [Full-Disclosure] Firefox 0.92 DoS via TinyBMP

[Ali Campbell <fdisclosure@xxxxxxxxxxxxxxxxxx>]

> This is precisely the point that almost everyone is missing
> completely (but still clamoring "it works on X, it doesn't work on
> Y"), and that Sapheriel pinpointed: the core problem lies in the 
> Windows .bmp implementation.
>
> So, I wonder aloud, what is the purpose of publishing 'advisories' 
> that misattribute this flaw to IE [1] or Firefox or any of the other
> hundreds or thousands of programs that use it and can be DoSed as a
> result?
>
> st3ng4h

I agree when you say that it's probably a flaw in the BMP lib 
implementation. But as I've pointed out once already, Windows isn't the 
only afflicted platform:

Ali-Campbells-Computer:~ alicampbell$ uname -a

Darwin Ali-Campbells-Computer.local 7.4.0 Darwin Kernel Version 7.4.0: 
Wed May 12 16:58:24 PDT 2004; root:xnu/xnu-517.7.7.obj~7/RELEASE_PPC 
Power Macintosh powerpc

Ali-Campbells-Computer:~ alicampbell$ top

<!-- snip -->
  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE VSIZE
<!-- snip -->
 1449 firefox-bi   0.5%  0:11.84  10   191   293  18.4M  37.2M  46.9M 
3.32G
<!-- snip -->

That's VSIZE=3.32 gigabytes.

As others have also observed, there isn't any machine slowdown when I 
try this either on Windows or OS X, despite the large amount of virtual 
memory sucked up. I'm postulating that this is because memory is being 
malloc()ed but not actually written to, so physical page frames for it 
never get allocated. I could be wrong though, as my current knowledge of 
kernels falls squarely in the "tourist" category.

Ali

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html