Flash leak of uninitialized data whilst rendering JPEGs

[GoogleCodeExporter]

This is probably another instance of CVE-2013-6629, reference:

http://seclists.org/fulldisclosure/2013/Nov/83

A SWF to reproduce is attached, along with source. To reproduce, host 
JPEGLeak.swf on the same web server / directory as 55.jpg.

Since this is uninitialized data, you can reload the SWF and see the rendered 
JPEG change either slightly or sometimes dramatically. It seems to work best 
with a Flash process that is not fresh. A couple of screenshots are attached to 
illustrate that the rendered images can sometimes differ significantly. The SWF 
file also demonstrates that the uninitialized data can be leaked to script, 
which makes the issue interesting / more serious.

If this is indeed the same underlying issue as CVE-2013-6629, then this patch 
may be useful:

http://src.chromium.org/viewvc/chrome/trunk/src/third_party/libjpeg/jdmarker.c?r
1=228354&r2=228353&pathrev=228354

Original issue reported on code.google.com by cev...@google.com on 8 Jul 2014 at 7:35

Attachments:

• JPEGLeak.swf
• JPEGLeak.as
• 55.jpg
• flashcorrupt1.png
• flashcorrupt2.png

[GoogleCodeExporter]

Original comment by cev...@google.com on 8 Jul 2014 at 9:42

• Added labels: Id-2874

[GoogleCodeExporter]

Oh! This is not fixed in the latest Flash update: 
http://helpx.adobe.com/security/products/flash-player/apsb14-18.html

Original comment by cev...@google.com on 21 Aug 2014 at 9:56

[GoogleCodeExporter]

Original comment by cev...@google.com on 5 Sep 2014 at 10:59

• Added labels: CVE-2014-0557

[GoogleCodeExporter]

http://helpx.adobe.com/security/products/flash-player/apsb14-21.html

Will derestrict in a week or so, etc.

Original comment by cev...@google.com on 9 Sep 2014 at 8:15

• Changed state: Fixed
• Added labels: Fixed-2014-Sep-9

[GoogleCodeExporter]

Making public.

Original comment by cev...@google.com on 23 Sep 2014 at 7:29

• Removed labels: Restrict-View-Commit