Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 640339 (CVE-2011-1202)

generate-id() function leaks information about valid heap addresses




7 years ago
a year ago


(Reporter: dveditz, Assigned: sicking)


Windows 7

Firefox Tracking Flags

(blocking2.0 Macaw+, status2.0 .1-fixed, status1.9.2 .17-fixed, status1.9.1 .19-fixed)


(Whiteboard: [sg:low], URL)


(1 attachment, 1 obsolete attachment)

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).
Version: 1.9.2 Branch → unspecified
Created attachment 518223 [details] [diff] [review]
patch to fix

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)
OS: Mac OS X → Windows 7
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");


I don't think this can leak info about adresses anymore.
Attachment #518223 - Flags: review?(peterv) → review+
Attachment #518223 - Flags: approval1.9.2.16?
Attachment #518223 - Flags: approval1.9.1.18?
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.
Comment on attachment 518223 [details] [diff] [review]
patch to fix

Approved for and, 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+
blocking2.0: --- → .x+
S'ok, we'll take the branches now and 4.0.1 when we can.
Checked in to branches:

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.
status1.9.1: wanted → .18-fixed
status1.9.2: wanted → .16-fixed
status2.0: --- → ?


6 years ago
blocking2.0: .x+ → Macaw
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+
Checked in on m-c and 2.0:
Last Resolved: 6 years ago
Resolution: --- → FIXED
status2.0: ? → .1-fixed
Duplicate of this bug: 651571


6 years ago
Alias: CVE-2011-1202

Comment 10

6 years ago
Created attachment 529326 [details] [diff] [review]
patch security
Tarak, what is this attachment supposed to be? It looks like an executable.
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
Depends on: 1243337
You need to log in before you can comment on or make changes to this bug.