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 Oct 24 23:38:45 2012  
 
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 Oct 28 11:51:50 2012, 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 Oct 26 03:14:40 2012, 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 Oct 25 19:11:07 2012, comment #5:

Try disabling jemalloc, if you have it enabled.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Thu Oct 25 18:41:11 2012, 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 Oct 25 18:35:09 2012, comment #3:

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

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Thu Oct 25 18:34:40 2012, 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 Oct 25 00:07:30 2012, 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 Oct 24 23:38:45 2012, 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 Jul 2 11:25:23 2013bjacquesStatusConfirmed=>Fixed
      Assigned toNone=>bjacques
      Open/ClosedOpen=>Closed
    Thu Nov 8 20:57:12 2012bjacquesRelease0.8.10=>master
      StatusNeed Info=>Confirmed
    Thu Oct 25 00:07:30 2012rsavoyeStatusNone=>Need Info
    Wed Oct 24 23:38:45 2012bjacquesCarbon-Copy-=>Added bwy

    Back to the top


    Powered by Savane 3.1-cleanup