Closed
Bug 640339
(CVE-2011-1202)
Opened 14 years ago
Closed 14 years ago
generate-id() function leaks information about valid heap addresses
Categories
(Core :: XSLT, defect)
Tracking
()
People
(Reporter: dveditz, Assigned: sicking)
References
()
Details
(Whiteboard: [sg:low])
Attachments
(1 file, 1 obsolete file)
4.41 KB,
patch
|
peterv
:
review+
dveditz
:
approval2.0+
dveditz
:
approval1.9.2.17+
dveditz
:
approval1.9.1.19+
|
Details | Diff | Splinter Review |
As demonstrated at the test URL and announced on Chris Evans' blog the XPath generate-id() function returns a valid heap address which might provide a useful handle in other attacks. Appears to affect all browsers one way or another (Chrome was patched before announcing this).
http://scarybeastsecurity.blogspot.com/2011/03/multi-browser-heap-address-leak-in-xslt.html
Reporter | ||
Updated•14 years ago
|
Version: 1.9.2 Branch → unspecified
Assignee | ||
Comment 1•14 years ago
|
||
Needs a bit more testing, but I think this should do it. I originally used the address of the txExecutionState itself, but since that usually lives on the stack it's possible that that'll be on a predictable address.
Attachment #518223 -
Flags: review?(peterv)
Updated•14 years ago
|
OS: Mac OS X → Windows 7
Comment 2•14 years ago
|
||
Comment on attachment 518223 [details] [diff] [review]
patch to fix
>diff --git a/content/xslt/src/xpath/txMozillaXPathTreeWalker.cpp b/content/xslt/src/xpath/txMozillaXPathTreeWalker.cpp
>+ PRUword nodeid = ((PRUword)aNode.mNode) - ((PRUword)aBase.mNode);
Don't think you need all those brackets.
>diff --git a/content/xslt/src/xslt/txGenerateIdFunctionCall.cpp b/content/xslt/src/xslt/txGenerateIdFunctionCall.cpp
>+ "called xslt extension function \"current\" with wrong context");
s/current/generate-id/
I don't think this can leak info about adresses anymore.
Attachment #518223 -
Flags: review?(peterv) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #518223 -
Flags: approval1.9.2.16?
Attachment #518223 -
Flags: approval1.9.1.18?
Assignee | ||
Comment 3•14 years ago
|
||
Dan, I don't know how you want to do about landing this on branches given that I don't think it can land on trunk right now.
Reporter | ||
Comment 4•14 years ago
|
||
Comment on attachment 518223 [details] [diff] [review]
patch to fix
Approved for 1.9.2.16 and 1.9.1.18, a=dveditz for release-drivers
Attachment #518223 -
Flags: approval1.9.2.16?
Attachment #518223 -
Flags: approval1.9.2.16+
Attachment #518223 -
Flags: approval1.9.1.18?
Attachment #518223 -
Flags: approval1.9.1.18+
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → .x+
Reporter | ||
Comment 5•14 years ago
|
||
S'ok, we'll take the branches now and 4.0.1 when we can.
Assignee | ||
Comment 6•14 years ago
|
||
Checked in to branches:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/768b54fa2f7d
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a201c429788b
Leaving open as it hasn't been check in to trunk yet.
Also nominating for the 2.0 branch as that'll likely be a separate landing.
Reporter | ||
Comment 7•14 years ago
|
||
Comment on attachment 518223 [details] [diff] [review]
patch to fix
Approved for the mozilla2.0 repository, a=dveditz for release-drivers
Attachment #518223 -
Flags: approval2.0+
Assignee | ||
Comment 8•14 years ago
|
||
Checked in on m-c and 2.0:
http://hg.mozilla.org/mozilla-central/rev/c2bd5cf4070e
http://hg.mozilla.org/releases/mozilla-2.0/rev/e01dc3fc20d3
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Updated•14 years ago
|
Alias: CVE-2011-1202
Comment 10•14 years ago
|
||
Assignee | ||
Comment 11•14 years ago
|
||
Tarak, what is this attachment supposed to be? It looks like an executable.
Assignee | ||
Comment 12•14 years ago
|
||
Comment on attachment 529326 [details] [diff] [review]
patch security
Marking obsolete for now as I suspect this was added by mistake.
Attachment #529326 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•