Bug 112099 - GIF decoder can read off end of buffer
Summary: GIF decoder can read off end of buffer
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Hin-Chung Lam
URL:
Keywords:
Depends on: 111144
Blocks:
  Show dependency tree / graph
 
Reported: 2013-03-11 20:09 PDT by Peter Kasting
Modified: 2013-03-19 16:10 PDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kasting 2013-03-11 20:09:39 PDT 
Noticed while reviewing various GIF decoder patches.  hclam -- want to fix this while you're touching this stuff?

The bug is that the GIFNetscapeExtensionBlock state of the parser reads the block length from the image file, but then the GIFConsumeNetscapeExtension assumes the block length is at least the 3 that the spec requires.  Therefore, an image can specify "1" or "2" here and then end after that many more bytes, and the parser will happily read another two or one bytes off the end of the buffer.

I believe the correct fix is that the GIFNetscapeExtensionBlock state should call GETN(std::max(3, *currentComponent), GIFConsumeNetscapeExtension);.  A comment explaining this wouldn't be amiss.

I suspect Gecko has the same problem.

The Chrome security guys looked at this and declared it not a security bug, since there seems to be no way to use this OOB read to malicious effect (since it just controls the image loop count).
Comment 1 Hin-Chung Lam 2013-03-11 20:14:19 PDT 
Okay, I'll fix it.
Comment 2 Hin-Chung Lam 2013-03-19 16:10:38 PDT 
The fix is landed in https://bugs.webkit.org/show_bug.cgi?id=111144