468270 - cairo UMR can lead to information leak via canvas' drawImage

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

Reported by [e-mail] to [e-mail].

The similar bug he refers to is bug 408076.

I've only been able to reproduce on Windows, and only in 2.0.0.x (Mac and Windows, 3.0.x/2.0.0.x/trunk).

========

Hello,
 
I believe I have recently found a minor security flaw in one of your products - Firefox 2.x, to be exact.
As far as I know, this version of the web browser is affected by a bug that causes a heap-based information leak
to occur while rendering some malformed .BMP graphical files. The vulnerability concerns the RLE8-decoding function.
 
When the application tries to correctly decompress the real contents of an image, it does not check the uncompressed
data size - in case there isn't any data (or there is one byte of decompressed data VS 4095 pixels of the image)
to be put in the image pixel buffer, it stays unfilled (since it's a part of the heap - it isn't cleaned in any way, either)
till the renderer draws the old memory contents on the screen. Yet there's no junk-memory displayed if one of  
End-Of-Line / End-Of-File markers are put at the end of  compressed image data.
More detailed RLE8 compression/decompression article can be found at:
http://msdn.microsoft.com/en-us/library/ms532328(VS.85).aspx
 
The bug is similar to the one found by Gynvael Coldwind, in a sense (http://www.hispasec.com/laboratorio/vulnerabilidad_firefox_en.pdf).
The proof of concept files are enclosed to this message in a ZIP archive (they don't differ much from these provided by Gynvael).
 
I want to coordinate the disclosure. Opera and Apple vendors are also affected.
Please give me a sign with your opinion about this issue.

Best regards,
Matthew 'j00ru' Jurczyk // Hispasec Sistemas

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Attachment: PoC image

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Attachment: PoC

Slightly modified to run straight from BMO, uses attachment 351714 [details].

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Attachment: original zipped PoC

Comment 4

[:Gavin Sharp [email: [e-mail]]]

This doesn't appear to be caused by a problem by the BMP/ICO decoder itself, despite the reporter's comments. The data for the given image is the consistent between multiple loads even though the testcase does give random results (verified by comparing data passed to gfxImageFrame::SetImageData/SetAlphaData). Loading the image directly also seems to work OK, which makes me suspect the UMR is somewhere in canvas or cairo code instead.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

This was fixed on trunk by either bug 343655 or bug 342366 (the former appears to be much more likely). That also explains why this is Windows only.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&branchtype=match&date=explicit&mindate=2006-08-09+02%3A00&maxdate=2006-08-10+05%3A00 is the regression range I found that led to comment 5.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hm, this slipped through the cracks for me -- is a patch for this still needed?

Comment 8

[Samuel Sidler (old account; do not CC)]

(In reply to comment #7)
> Hm, this slipped through the cracks for me -- is a patch for this still needed?

Yes.

Comment 9

[Daniel Veditz [:dveditz]]

This is not needed for Thunderbird 2, and the patches in the bugs mentioned in comment 5 can't easily be landed on that branch (assume a massive graphics backend rewrite). We're unfortunately going to have to WONTFIX this. For the people left on the old versions this minor information leak is the least of their worries going forward.

Unless the linux distro folks can roust the programmer resources to tackle this. Asac, want to leave this open?