CVE-2006-0298 Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer]

RESOLVED FIXED in mozilla1.8.1

Status

()

Core
XML
P1
normal
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: peterv, Assigned: peterv)

Tracking

({fixed1.8.0.1, fixed1.8.1, topcrash})

Trunk
mozilla1.8.1
fixed1.8.0.1, fixed1.8.1, topcrash
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.1 +
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low] Read past end of buffer; may expose memory on heap, crash signature, URL)

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
Jst discovered this while helping me debug my patch for bug 274777 (I'd already fixed it without realizing it in my patch for bug 22942).

See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/src/nsExpatDriver.cpp&rev=3.86&mark=879#871 It should read |startOffset = aLength / sizeof(PRUnichar);|.
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
(Assignee)

Comment 1

12 years ago
Created attachment 205954 [details] [diff] [review]
v1
Attachment #205954 - Flags: superreview?(jst)
Attachment #205954 - Flags: review?(mrbkap)
(Assignee)

Comment 2

12 years ago
There's quite a bit of crashes in Talkback that seem caused by this: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsExpatDriver::ParseBuffer&vendor=MozillaOrg&product=Firefox15&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid It's number 37 in the topcrashers list for 1.5. The crash usually happens when we access the buffer, probably with an index that's too big: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/parser/htmlparser/src/nsExpatDriver.cpp&mark=892&rev=MOZILLA_1_8_BRANCH#872
Summary: Buffer overrun in nsExpatDriver::ParseBuffer → Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer]
Comment on attachment 205954 [details] [diff] [review]
v1

sr=jst
Attachment #205954 - Flags: superreview?(jst) → superreview+
Comment on attachment 205954 [details] [diff] [review]
v1

r=mrbkap
Attachment #205954 - Flags: review?(mrbkap) → review+

Updated

12 years ago
Flags: blocking1.8.0.1?
Whiteboard: [sg:low] Buffer overflow, at worst may expose memory on heap

Updated

12 years ago
Whiteboard: [sg:low] Buffer overflow, at worst may expose memory on heap → [sg:low] Read past end of buffer; at worst may expose memory on heap

Updated

12 years ago
Whiteboard: [sg:low] Read past end of buffer; at worst may expose memory on heap → [sg:moderate] Read past end of buffer; may expose memory on heap

Updated

12 years ago
Attachment #205954 - Flags: approval1.8.0.1?

Updated

12 years ago
Group: security
(Assignee)

Comment 5

12 years ago
Checked in on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Flags: blocking1.8.1?

Comment 6

12 years ago
Can we bake a few more takes and then we'll consider.
Comment on attachment 205954 [details] [diff] [review]
v1

a=dveditz
Please add the fixed1.8.0.1 and fixed1.8.1 when checked in to the branches
Attachment #205954 - Flags: approval1.8.1+
Attachment #205954 - Flags: approval1.8.0.1?
Attachment #205954 - Flags: approval1.8.0.1+
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
(Assignee)

Updated

12 years ago
Keywords: fixed1.8.0.1, fixed1.8.1
Target Milestone: mozilla1.9alpha → mozilla1.8.1
Would like to verify this on the branch, but without a testcase or STR it is tough. Can someone help here?

Updated

12 years ago
Flags: testcase-
In order to certify the 1.5.0.1 release, I have been asked to verify this bug. Can I please get some help getting a testcase or STR to verify?  Thanks.
(Assignee)

Comment 10

12 years ago
I'll try to come up with a testcase but it's not trivial. This bug was discovered through code inspection.
Note that there are a bunch of talkbacks (see comment 2), but I never got the crash myself.
Peter: I don't want to cause excessive work, so if it will take too much time we can have someone inspect the code to verify.

(In reply to comment #10)
> I'll try to come up with a testcase but it's not trivial. This bug was
> discovered through code inspection.
> Note that there are a bunch of talkbacks (see comment 2), but I never got the
> crash myself.
> 

Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
(Assignee)

Comment 12

12 years ago
The patch that caused this wasn't checked in on the 1.7.x branch.
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
Whiteboard: [sg:moderate] Read past end of buffer; may expose memory on heap → [sg:low] Read past end of buffer; may expose memory on heap

Updated

12 years ago
Summary: Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer] → CVE-2006-0298 Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer]
Group: security
nsExpatDriver::ParseBuffer is still showing up as a topcrash for Fx 1.5.0.1.
Keywords: topcrash
Crash Signature: [@ nsExpatDriver::ParseBuffer]
You need to log in before you can comment on or make changes to this bug.