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

 
 

bug #37629: buffer overflow from Input::readSWFJpeg3

Submitted by:  Bastiaan Jacques <bjacques>
Submitted on:  Wed 24 Oct 2012 11:38:45 PM UTC  
 
Category: coreSeverity: 6 - Security
Release: masterStatus: Fixed
Privacy: PublicAssigned to: Bastiaan Jacques <bjacques>
Open/Closed: Closed

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project MemberIn charge of this item.
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>
Project Administrator
Thu 25 Oct 2012 07:11:07 PM UTC, comment #5:

Try disabling jemalloc, if you have it enabled.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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:

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:

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>
Project MemberIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 02 Jul 2013 11:25:23 AM UTCbjacquesStatusConfirmed=>Fixed
      Assigned toNone=>bjacques
      Open/ClosedOpen=>Closed
    Thu 08 Nov 2012 08:57:12 PM UTCbjacquesRelease0.8.10=>master
      StatusNeed Info=>Confirmed
    Thu 25 Oct 2012 12:07:30 AM UTCrsavoyeStatusNone=>Need Info
    Wed 24 Oct 2012 11:38:45 PM UTCbjacquesCarbon-Copy-=>Added bwy

    Back to the top


    Powered by Savane 3.1-cleanup