Closed
Bug 320375
Opened 19 years ago
Closed 19 years ago
CVE-2006-0298 Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer]
Categories
(Core :: XML, defect, P1)
Core
XML
Tracking
()
RESOLVED
FIXED
mozilla1.8.1
People
(Reporter: peterv, Assigned: peterv)
References
()
Details
(Keywords: fixed1.8.0.1, fixed1.8.1, topcrash, Whiteboard: [sg:low] Read past end of buffer; may expose memory on heap)
Crash Data
Attachments
(1 file)
755 bytes,
patch
|
mrbkap
:
review+
jst
:
superreview+
dveditz
:
approval1.8.0.1+
dveditz
:
approval1.8.1+
|
Details | Diff | Splinter Review |
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•19 years ago
|
Assignee | ||
Comment 1•19 years ago
|
||
Attachment #205954 -
Flags: superreview?(jst)
Attachment #205954 -
Flags: review?(mrbkap)
Assignee | ||
Comment 2•19 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 3•19 years ago
|
||
Comment on attachment 205954 [details] [diff] [review]
v1
sr=jst
Attachment #205954 -
Flags: superreview?(jst) → superreview+
Comment 4•19 years ago
|
||
Comment on attachment 205954 [details] [diff] [review]
v1
r=mrbkap
Attachment #205954 -
Flags: review?(mrbkap) → review+
Updated•19 years ago
|
Flags: blocking1.8.0.1?
Whiteboard: [sg:low] Buffer overflow, at worst may expose memory on heap
Updated•19 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•19 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•19 years ago
|
Attachment #205954 -
Flags: approval1.8.0.1?
Updated•19 years ago
|
Group: security
Assignee | ||
Comment 5•19 years ago
|
||
Checked in on trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8.1?
Comment 6•19 years ago
|
||
Can we bake a few more takes and then we'll consider.
Comment 7•19 years ago
|
||
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+
Updated•19 years ago
|
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
Assignee | ||
Updated•19 years ago
|
Keywords: fixed1.8.0.1,
fixed1.8.1
Updated•19 years ago
|
Target Milestone: mozilla1.9alpha → mozilla1.8.1
Comment 8•19 years ago
|
||
Would like to verify this on the branch, but without a testcase or STR it is tough. Can someone help here?
Updated•19 years ago
|
Flags: testcase-
Comment 9•19 years ago
|
||
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•19 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.
Comment 11•19 years ago
|
||
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.
>
Updated•19 years ago
|
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
Assignee | ||
Comment 12•19 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?
Updated•19 years ago
|
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•19 years ago
|
Summary: Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer] → CVE-2006-0298 Buffer overrun in nsExpatDriver::ParseBuffer [@ nsExpatDriver::ParseBuffer]
Updated•19 years ago
|
Group: security
nsExpatDriver::ParseBuffer is still showing up as a topcrash for Fx 1.5.0.1.
Keywords: topcrash
Updated•14 years ago
|
Crash Signature: [@ nsExpatDriver::ParseBuffer]
You need to log in
before you can comment on or make changes to this bug.
Description
•