Closed
Bug 490790
(CVE-2010-0182)
Opened 16 years ago
Closed 15 years ago
XMLDocument::load() doesn't check nsIContentPolicy
Categories
(Core :: XML, defect)
Core
XML
Tracking
()
VERIFIED
FIXED
People
(Reporter: jwkbugzilla, Assigned: sicking)
References
(Blocks 1 open bug)
Details
(Keywords: verified1.9.1, verified1.9.2, Whiteboard: [sg:low+])
Attachments
(1 file, 1 obsolete file)
5.72 KB,
patch
|
dveditz
:
review+
dveditz
:
approval1.9.2.2+
dveditz
:
approval1.9.1.9+
|
Details | Diff | Splinter Review |
nsXMLDocument::load() will do same-origin checks on the URL to be loaded but won't check content policies. I think it should call content policies with TYPE_XMLHTTPREQUEST and use calling document as context.
Comment 1•15 years ago
|
||
All kinds of things use content policies, and some of them are security related.
Blocks: CSP
Whiteboard: [sg:low+]
Assignee | ||
Comment 2•15 years ago
|
||
I guess I can take this. Not sure if using TYPE_XMLHTTPREQUEST is ok. I agree it's conceptually the same, i just worry that people expect to be able to get to an XHR object.
Assignee: nobody → jonas
Assignee | ||
Updated•15 years ago
|
blocking2.0: --- → final
Assignee | ||
Updated•15 years ago
|
Summary: XMLDocument::load() doesn't check content policies → XMLDocument::load() doesn't check nsIContentPolicy
Assignee | ||
Comment 3•15 years ago
|
||
Wladimir, it would be great if you wanna try to run with this patch to see if things work properly.
Attachment #429031 -
Flags: review?(dveditz)
Comment 4•15 years ago
|
||
Comment on attachment 429031 [details] [diff] [review]
Patch to fix
r=dveditz
In the old code, lack of codebase is not equal to system principal!
Attachment #429031 -
Flags: review?(dveditz) → review+
Reporter | ||
Comment 5•15 years ago
|
||
I don't think I will be able to test before the patch lands.
Assignee | ||
Comment 6•15 years ago
|
||
Turns out that the first patch breaks a bunch of mochitests. The problem is that if we use the document itself as context, the nsDataDocumentContentPolicy content policy blocks the load. Instead we should using the *calling* document as the context.
This patch does that.
Attachment #429031 -
Attachment is obsolete: true
Attachment #429272 -
Flags: review?(dveditz)
Comment 7•15 years ago
|
||
Comment on attachment 429272 [details] [diff] [review]
Patch v2
r=dveditz
Attachment #429272 -
Flags: review?(dveditz) → review+
Updated•15 years ago
|
status1.9.1:
--- → wanted
status1.9.2:
--- → wanted
Assignee | ||
Comment 8•15 years ago
|
||
Checked in. Thanks for finding this!
http://hg.mozilla.org/mozilla-central/rev/ed1612a1ffa8
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•15 years ago
|
Attachment #429272 -
Flags: approval1.9.2.2?
Attachment #429272 -
Flags: approval1.9.1.9?
Comment 9•15 years ago
|
||
Comment on attachment 429272 [details] [diff] [review]
Patch v2
Approved for 1.9.2.2, and 1.9.1.9, a=dveditz for release-drivers
Attachment #429272 -
Flags: approval1.9.2.2?
Attachment #429272 -
Flags: approval1.9.2.2+
Attachment #429272 -
Flags: approval1.9.1.9?
Attachment #429272 -
Flags: approval1.9.1.9+
Assignee | ||
Comment 10•15 years ago
|
||
Checked in to 1.9.1 branch for 1.9.1.9
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4d4f3726d884
And to 1.9.2 branch for 1.9.2.2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/46d94cbc195f
Assignee | ||
Updated•15 years ago
|
Comment 11•15 years ago
|
||
Is there a testcase or some sort of manual reproduction steps for this?
Assignee | ||
Comment 12•15 years ago
|
||
I don't think we have any tests for contentpolicies. The best thing would be if Wladimir could check as I believe he has good tests for contentpolicies.
Reporter | ||
Comment 13•15 years ago
|
||
I added this test to my test suite: https://hg.adblockplus.org/adblockplus/rev/235e750203cb (tested without the version check however, will remove it in the test suite once the releases are out).
Fails in:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9pre) Gecko/20100307 Shiretoko/3.5.9pre
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100307 Namoroka/3.6.2pre
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre
Succeeds in:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9pre) Gecko/20100315 Shiretoko/3.5.9pre
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100315 Namoroka/3.6.2pre
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100312 Minefield/3.7a3pre
Marking as verified.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 14•15 years ago
|
||
Thanks Wladimir!
Comment 15•15 years ago
|
||
Adding verified1.9.1 and verified1.9.2 keywords.
Keywords: verified1.9.1,
verified1.9.2
Updated•15 years ago
|
Flags: wanted1.9.0.x+
Updated•15 years ago
|
Alias: CVE-2010-0182
Updated•15 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•