full-disclosure - Firefox 0.92 DoS via TinyBMP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <40F2FEC8.20105@alicampbell.org.uk>
From: fdisclosure at alicampbell.org.uk (Ali Campbell)
Subject: Firefox 0.92 DoS  via TinyBMP

> 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