bugGnash - The GNU Flash player - Bugs: bug #37629, buffer overflow from...

 
 

bug #37629: buffer overflow from Input::readSWFJpeg3

Submitter:  Bastiaan Jacques <bjacques>
Submitted:  Wed 24 Oct 2012 11:38:45 PM UTC
   
 
Category:  core Severity:  6 - Security
Release:  master Status:  Fixed
Privacy:  Public Assigned to:  bjacques
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 28 Oct 2012 11:51:50 AM UTC, comment #7: 

The source of the problem is different than I thought. readSWFJpeg3() is clearly written with a 3-bytes per pixel decoded image in mind, but in this case libjpeg is decoding to a 4-byte per pixel format. In other words, the following will fail if put inside readSWFJpeg3():

assert( j_in->getComponents() == 3);

The rest of the code, including the allocation, is done with this assumption in mind.

Still left to discover is whether it is possible to include this JPEG data into an AVM1 movie.

Bastiaan Jacques <bjacques>
Group Member
Fri 26 Oct 2012 03:14:40 AM UTC, comment #6: 

If I build with --disable-jemalloc, I can reproduce the failure on both x86 and x86_64 Fedora platforms. Jemalloc is used by default as it has better performance anyway, but using the system malloc should work too.

Rob Savoye <rsavoye>
Group administrator
Thu 25 Oct 2012 07:11:07 PM UTC, comment #5: 

Try disabling jemalloc, if you have it enabled.

Bastiaan Jacques <bjacques>
Group Member
Thu 25 Oct 2012 06:41:11 PM UTC, comment #4: 

On my x86_64 Fedora 17 system, I can't reproduce this with this URL. I do get an empty window frame, but don't see any jpegs getting loaded anywhere. So of course it doesn't segfault. I was testing this with current Gnash master though, and not the Redhat package. I am curious if your problem is related to running on a 64 bit system.

Rob Savoye <rsavoye>
Group administrator
Thu 25 Oct 2012 06:35:09 PM UTC, comment #3: 

I suppose that should be libtool --mode=execute, by the way.

Bastiaan Jacques <bjacques>
Group Member
Thu 25 Oct 2012 06:34:40 PM UTC, comment #2: 


> Can I get a top level URL that launches this file ? I haven't been able to reproduce this from what's in the Redhat bug report.


Try: libtool valgrind gui/gnash http://www.htc.com/assets/swf/InteractivePhone.swf?version=0.01

> Do you know if the same files work on a 32bit system ?


Haven't tried this on a 32-bit system.

Bastiaan Jacques <bjacques>
Group Member
Thu 25 Oct 2012 12:07:30 AM UTC, comment #1: 

While we should fix the jpeg core dump, I do notice the SWF file is AVM2, which won't work in Gnash anyway. Can I get a top level URL that launches this file ? I haven't been able to reproduce this from what's in the Redhat bug report. Do you know if the same files work on a 32bit system ?

Rob Savoye <rsavoye>
Group administrator
Wed 24 Oct 2012 11:38:45 PM UTC, original submission:  

Downstream bug is https://bugzilla.redhat.com/show_bug.cgi?id=827313&list_id=730634 .

Please see the attached backtrace there. I thought it was a rather curious stacktrace, and after a rather long search I formed a theory that the wrong buffer size was being passed into libjpeg because of this comment in the libjpeg-turbo sources:

  /*
   * Round up the requested size to a multiple of ALIGN_SIZE so that
   * algorithms can straddle outside the proper area up to the next
   * alignment.
   */


This comment is part of the libjpeg internal allocator, whereas we allocate our own buffer. So perhaps that's the difference. I ran a few SWFs containing JPEGs through Valgrind/Gnash, but Valgrind did not complain at all. Then I ran
the SWF from the downstream bug report and Valgrind exited rather indignantly after complaining:


==15224== Thread 2:
==15224== Invalid write of size 1
==15224==    at 0x9A56228: ??? (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x9A606C7: ??? (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x9A59617: ??? (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x9A541FF: jpeg_read_scanlines (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x59EB78F: gnash::image::JpegInput::readScanline(unsigned char*) (GnashImageJpeg.cpp:409)
==15224==    by 0x59E8B77: gnash::image::Input::readSWFJpeg3(boost::shared_ptr<gnash::IOChannel>) (GnashImage.cpp:307)


Perhaps the difference stems from different image (and thus, buffer) sizes.

So my theory is that the downstream bug is caused by the buffer being too small and some degree of good/bad fortune, and should, presumably, be fixed by aligning the buffer size.

Bastiaan Jacques <bjacques>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rsavoye (Updated the item)
  • -email is unavailable- added by bjacques (Submitted the item)
  • -email is unavailable- added by bjacques
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-02 bjacques StatusConfirmed Fixed
        Assigned toNone bjacques
        Open/ClosedOpen Closed
    2012-11-08 bjacques Release0.8.10 master
        StatusNeed Info Confirmed
    2012-10-25 rsavoye StatusNone Need Info
    2012-10-24 bjacques Carbon-Copy- Added bwy

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code