New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2012
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Heap-buffer-overflow in GIFImageReader::read

Reported by attek...@gmail.com, May 15 2012

Issue description

Reprofile as attachment.

Chrome Version: 21.0.1138.0 (Developer Build 137111)
Operating System: Ubuntu 11.04 x86_64

ASAN report:

=================================================================
==2232== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7fed5c5a5e00 at pc 0x7fed6f639bf0 bp 0x7fff382fffc0 sp 0x7fff382fffb8
READ of size 1 at 0x7fed5c5a5e00 thread T0
    #0 0x7fed6f639bf0 in GIFImageReader::read(unsigned char const*, unsigned int, WebCore::GIFImageDecoder::GIFQuery, unsigned int) ???:0
    #1 0x7fed6f631dce in WebCore::GIFImageDecoder::decode(unsigned int, WebCore::GIFImageDecoder::GIFQuery) ???:0
    #2 0x7fed6f6329d6 in WebCore::GIFImageDecoder::frameBufferAtIndex(unsigned long) ???:0
    #3 0x7fed6f4fc18f in WebCore::ImageSource::createFrameAtIndex(unsigned long) ???:0
    #4 0x7fed6f49cffb in WebCore::BitmapImage::cacheFrame(unsigned long) ???:0
    #5 0x7fed6f49e850 in WebCore::BitmapImage::ensureFrameIsCached(unsigned long) ???:0
    #6 0x7fed6f49f834 in WebCore::BitmapImage::startAnimation(bool) ???:0
    #7 0x7fed6f5ffc69 in WebCore::BitmapImage::draw(WebCore::GraphicsContext*, WebCore::FloatRect const&, WebCore::FloatRect const&, WebCore::ColorSpace, WebCore::CompositeOperator) ???:0
    #8 0x7fed6f4dfa17 in WebCore::GraphicsContext::drawImage(WebCore::Image*, WebCore::ColorSpace, WebCore::FloatRect const&, WebCore::FloatRect const&, WebCore::CompositeOperator, WebCore::RespectImageOrientationEnum, bool) ???:0
    #9 0x7fed6f4df504 in WebCore::GraphicsContext::drawImage(WebCore::Image*, WebCore::ColorSpace, WebCore::IntRect const&, WebCore::CompositeOperator, WebCore::RespectImageOrientationEnum, bool) ???:0
    .
    .
    .
    .
    #34 0x7fed7270f3a5 in RenderWidget::InvalidationCallback() ???:0
    #35 0x7fed6d01aeb5 in MessageLoop::RunTask(base::PendingTask const&) ???:0
    #36 0x7fed6d01b5fc in MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) ???:0
    #37 0x7fed6d01cb62 in MessageLoop::DoWork() ???:0
    #38 0x7fed6d026987 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ???:0
    #39 0x7fed6d019b02 in MessageLoop::RunInternal() ???:0
    #40 0x7fed6d017cee in MessageLoop::Run() ???:0
    #41 0x7fed7272a923 in RendererMain(content::MainFunctionParams const&) ???:0
    #42 0x7fed6ced36b2 in (anonymous namespace)::ContentMainRunnerImpl::Run() content/app/content_main_runner.cc:0
    #43 0x7fed6ced1505 in content::ContentMain(int, char const**, content::ContentMainDelegate*) ???:0
    #44 0x7fed6ba49e67 in ChromeMain ??:0
    #45 0x7fed6ba49dcb in main ???:0
    #46 0x7fed64bb1eff in __libc_start_main /build/buildd/eglibc-2.13/csu/libc-start.c:258
0x7fed5c5a5e00 is located 0 bytes to the right of 7552-byte region [0x7fed5c5a4080,0x7fed5c5a5e00)
allocated by thread T0 here:
    #0 0x7fed73b1a5b2 in malloc ??:0
    #1 0x7fed6ecee7bb in WTF::fastMalloc(unsigned long) ???:0
    #2 0x7fed6f45cbdf in WebCore::SharedBuffer::buffer() const ???:0
    #3 0x7fed6f45ca7e in WebCore::SharedBuffer::data() const ???:0
    #4 0x7fed6f631d4e in WebCore::GIFImageDecoder::decode(unsigned int, WebCore::GIFImageDecoder::GIFQuery) ???:0
    #5 0x7fed6f631721 in WebCore::GIFImageDecoder::isSizeAvailable() ???:0
    #6 0x7fed6f4fbf28 in WebCore::ImageSource::isSizeAvailable() ???:0
    #7 0x7fed6f49e411 in WebCore::BitmapImage::isSizeAvailable() ???:0
    #8 0x7fed6f49e32a in WebCore::BitmapImage::dataChanged(bool) ???:0
    #9 0x7fed6f4f9ef4 in WebCore::Image::setData(WTF::PassRefPtr<WebCore::SharedBuffer>, bool) ???:0
    #10 0x7fed6fe8b2a4 in WebCore::CachedImage::data(WTF::PassRefPtr<WebCore::SharedBuffer>, bool) ???:0
    #11 0x7fed6f246782 in WebCore::ImageDocumentParser::appendBytes(WebCore::DocumentWriter*, char const*, unsigned long) ???:0
    #12 0x7fed6fdc9d40 in WebCore::DocumentLoader::commitData(char const*, unsigned long) ???:0
    #13 0x7fed6eac5cac in WebKit::FrameLoaderClientImpl::committedLoad(WebCore::DocumentLoader*, char const*, int) ???:0
    #14 0x7fed6fdc9fde in WebCore::DocumentLoader::commitLoad(char const*, int) ???:0
    #15 0x7fed6fe60343 in WebCore::ResourceLoader::didReceiveData(char const*, int, long long, bool) ???:0
    #16 0x7fed6fe3cb1c in WebCore::MainResourceLoader::didReceiveData(char const*, int, long long, bool) ???:0
    #17 0x7fed6fe61908 in WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) ???:0
    #18 0x7fed6e54bd18 in ResourceDispatcher::OnReceivedData(IPC::Message const&, int, base::FileDescriptor, int, int) ???:0
    #19 0x7fed6e54a031 in ResourceDispatcher::DispatchMessage(IPC::Message const&) ???:0
    #20 0x7fed6e548326 in ResourceDispatcher::OnMessageReceived(IPC::Message const&) ???:0
    #21 0x7fed6e4439db in ChildThread::OnMessageReceived(IPC::Message const&) ???:0
    #22 0x7fed6d135a95 in IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&) ???:0
==2232== ABORTING
Stats: 9M malloced (11M for red zones) by 21919 calls
Stats: 0M realloced by 87 calls
Stats: 6M freed by 11193 calls
Stats: 0M really freed by 0 calls
Stats: 60M (15370 full pages) mmaped in 15 calls
  mmaps   by size class: 8:32766; 9:8191; 10:4095; 11:2047; 12:1024; 13:512; 14:256; 15:128; 16:128; 17:32; 18:16; 20:4; 22:1;
  mallocs by size class: 8:18308; 9:1607; 10:1458; 11:207; 12:100; 13:107; 14:20; 15:9; 16:96; 17:4; 18:1; 20:1; 22:1;
  frees   by size class: 8:8461; 9:1059; 10:1347; 11:98; 12:67; 13:88; 14:11; 15:4; 16:53; 17:2; 18:1; 20:1; 22:1;
  rfrees  by size class:
Stats: malloc large: 7 small slow: 134
Shadow byte and word:
  0x1ffdab8b4bc0: fa
  0x1ffdab8b4bc0: fa fa fa fa fa fa fa fa
More shadow bytes:
  0x1ffdab8b4ba0: 00 00 00 00 00 00 00 00
  0x1ffdab8b4ba8: 00 00 00 00 00 00 00 00
  0x1ffdab8b4bb0: 00 00 00 00 00 00 00 00
  0x1ffdab8b4bb8: 00 00 00 00 00 00 00 00
=>0x1ffdab8b4bc0: fa fa fa fa fa fa fa fa
  0x1ffdab8b4bc8: fa fa fa fa fa fa fa fa
  0x1ffdab8b4bd0: fa fa fa fa fa fa fa fa
  0x1ffdab8b4bd8: fa fa fa fa fa fa fa fa
  0x1ffdab8b4be0: fa fa fa fa fa fa fa fa



 
radamsa-0.2.3-133.gif
7.4 KB View Download

Comment 1 by kenrb@chromium.org, May 15 2012

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=47682436

Uploader: kenrb@chromium.org

Crash Type: Heap-buffer-overflow READ 1
Crash Address: 0x7f240c12fe00
Crash State:
  - crash stack -
  GIFImageReader::read
  WebCore::GIFImageDecoder::decode
  WebCore::GIFImageDecoder::frameBufferAtIndex
  

Minimized Testcase (7.38 Kb): https://cluster-fuzz.appspot.com/download/AMIfv97yKGNnPYClvH8zVY5eCnNMuSluwwCJ0SXyU0-vHuGCsq3wkjVgzyRq71O-7d5twYCTDLwZjNUBpQ_vt1shjXpkKPOTwhEKKG_YjboFhchsktiXNsc4teJRW7YaVl2mK_Y8Ngb7tWjR4g7I3CH3ZmYTShWw_g

Comment 2 by kenrb@chromium.org, May 15 2012

Cc: pkasting@chromium.org
Labels: -Pri-0 -Area-Undefined Pri-2 Area-WebKit OS-All SecImpacts-Stable SecImpacts-Beta Mstone-19 SecSeverity-Low

This is a 1 byte OOB read on a heap buffer. The extra byte could affect pixel transparency in the resulting image, so seems like it could be recoverable. The overrun read could potentially be 3 bytes, though recovery would be hard for the other two.

The problem is in the decoding FSM loop in GIFImageReader::read(). 
In the gif_extension state of the FSM in GIFImageReader, it gets the next state and the length of the extension from the input.

It ensures that there is enough remaining data in the buffer for the given extension length that was read, but it doesn't verify that the parser won't munge more input than that during the next pass through the parsing loop.

In this case, it sets the next state as 'gif_control_extension' and sets length to 3 (exactly the amount of data left in the buffer), but the gif_control_extension state reads 4 bytes from the buffer.

Comment 3 by kenrb@chromium.org, May 15 2012

Status: Available
Cc: -pkasting@chromium.org
Owner: pkasting@chromium.org
Status: Assigned
The spec states that for gif_control_extension, the length field must have the value 4.  So this GIF is mal-formed.  The problem is that the decoder trusts the length specified in this field.

I believe the correct fix is for the reader here to mandate the spec-supplied lengths for the various extension blocks, ignoring the specified length.

This is also a problem in Mozilla's current decoder; see http://mxr.mozilla.org/mozilla-central/source/image/decoders/nsGIFDecoder2.cpp#799 .  We should probably file a bug upstream with them.
Patch available for review on https://bugs.webkit.org/show_bug.cgi?id=86531 .
Filed Mozilla bug as https://bugzilla.mozilla.org/show_bug.cgi?id=755523 .
Status: Fixed
Fixed upstream in WebKit r117333.  I will leave it to others to decide if this should indeed be merged to any branches.
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Merge-Approved
Status: FixUnreleased
We will handle the merges, thanks Peter.
Refixed in r117373.  Make sure you merge both changes since the first one breaks GIF decoding for some invalid GIFs that apparently exist in the real world.

Comment 10 by kenrb@chromium.org, May 17 2012

Here are the WebKit revision links for convenience and to avoid confusion from the automatic formatting of r numbers to Chromium revisions:
http://trac.webkit.org/changeset/117333
http://trac.webkit.org/changeset/117373
Project Member

Comment 11 by ClusterFuzz, May 18 2012

ClusterFuzz has detected this issue as fixed in range 137694:137702.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=47682436

Uploader: kenrb@chromium.org

Crash Type: Heap-buffer-overflow READ 1
Crash Address: 0x7f240c12fe00
Crash State:
  - crash stack -
  GIFImageReader::read
  WebCore::GIFImageDecoder::decode
  WebCore::GIFImageDecoder::frameBufferAtIndex
  
Fixed: https://cluster-fuzz.appspot.com/revisions?range=137694:137702

Minimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97yKGNnPYClvH8zVY5eCnNMuSluwwCJ0SXyU0-vHuGCsq3wkjVgzyRq71O-7d5twYCTDLwZjNUBpQ_vt1shjXpkKPOTwhEKKG_YjboFhchsktiXNsc4teJRW7YaVl2mK_Y8Ngb7tWjR4g7I3CH3ZmYTShWw_g

If you suspect that the result above is incorrect, try re-doing that job on the testcase report page.
Labels: -Mstone-19 -Merge-Approved Mstone-21
Seems like this can just roll into M21.
Labels: CVE-2012-2849
Project Member

Comment 14 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Status: Fixed
Project Member

Comment 16 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-WebKit -SecImpacts-Stable -SecImpacts-Beta -Mstone-21 -SecSeverity-Low Cr-Content Security-Severity-Low Security-Impact-Stable Security-Impact-Beta M-21 Type-Bug-Security
Project Member

Comment 17 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 18 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 20 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 23 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 24 by sheriffbot@chromium.org, Jun 14 2016

Labels: -security_impact-beta
Project Member

Comment 25 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 26 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment