The default bug view has changed. See this FAQ.
Bug 455472 (CVE-2010-0162)

[FIX]code injection with Content-Type: application/octet-stream, embed and svg - no plugins required

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Core
DOM
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: georgi - hopefully not receiving bugspam, Assigned: bz)

Tracking

({testcase, verified1.9.0.18, verified1.9.1})

Trunk
mozilla1.9.3a1
testcase, verified1.9.0.18, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
blocking1.9.0.18 +
wanted1.9.0.x +

Firefox Tracking Flags

(status1.9.2 beta5-fixed, blocking1.9.1 .8+, status1.9.1 .8-fixed)

Details

(Whiteboard: [sg:moderate])

Attachments

(7 attachments, 1 obsolete attachment)

Created attachment 338822 [details]
svg.bin - ct binary on purpose

ability to upload file with  Content-Type: application/octet-stream to a web server means ability to execute javascript from the same server.

done via:
<embed id="s1" type="image/svg+xml" src="http://sarwar/svgim1.bin">

svgim1.bin is svg containing javascript

no plugins are required
Summary: universal css with Content-Type: application/octet-stream, embed and svg - no plugins required → universal xss with Content-Type: application/octet-stream, embed and svg - no plugins required
Created attachment 338824 [details]
testcase getsvg2.html
Created attachment 338825 [details]
correct testcase
Attachment #338824 - Attachment is obsolete: true
Keywords: testcase
Whiteboard: [sg:low?]
Is this behavior interoperable across browsers?  I would think it is.
> Is this behavior interoperable across browsers?  I would think it is.

the testcase is not buggy in konqueror 3.5.9 - no alert. though i am not sure this version of konq. understands svg at all.

interesting in this bug is that the browser plays something like a plugin if i understand the meaning of embed correctly.
on konqueror 3.5.9

<embed src="http://server/index.bin" type="text/html"></embed>

displays the embedded HTML. this testcase fails on firefox (missing plugin).

will try safari soon.

bz: note that i am not writing about plugins on purpose.
Safari seems to save the file.  Opera puts up the alert.  I don't have IE on hand.  Note that the application/octet-stream special-casing here was added to fix bug 389677.
Oh, and we don't allow subdocuments in embed, except for SVG.
And note also that this behavior is the same for <object> as for <embed>.
confirming that safari prompts for saving the svg, same for html with index.bin
>Oh, and we don't allow subdocuments in embed, except for SVG.

cross site i can get the document via getSVGDocument() but can't get .firstChild
> cross site i can get the document via getSVGDocument()

Hmm.  That might actually be a bug; not sure about that.  Blake, please file it as needed if it is?  I'd think we would disallow this, since it's not getting an XOW.

georgi, is the not being able to get firstChild also true on trunk, or just with Firefox 3?
bz: i am trying to steal the xml cross site and get security exception. on same site i get .firstChild fine. i don't see any bug, except probably even getting the document via getSVGDocument()
> georgi, is the not being able to get firstChild also true on trunk, or just
> with Firefox 3?

to clarify: when svg is served from the same site, i CAN GET .firstChild on both trunk and 1.9 branch.

i fail when it is cross site - this seems reasonable
I don't think you should be able to getSVGDocument() cross-site.  And I'm afraid that if you _can_ do it you might be able to get firstChild on trunk (if not now, then as we remove more redundany security checks).
> I don't think you should be able to getSVGDocument() cross-site.

i definitely can get cross site |getSVGDocument()| on both trunk and 1.9 branch.
.firstChild throws cross site
Created attachment 338868 [details]
demo for cross site getSVGDocument()
There seems to be a little confusion around this bug.  Cross-site means that one site can script into another site, which is not quite the same thing as uploading a file to a server that then results in code execution.
The point georgi is making is that this allows you to inject code to run with the given server's permissions, from whence it can script other pages on that server.
To clarify, I agree that this can result in malicious code injection, but it is not clear to me whether that's the only issue or if we also have an issue with cross-domain code injection via DOM navigation.
DOM navigation of what?
(In reply to comment #14)
> I don't think you should be able to getSVGDocument() cross-site.  And I'm
> afraid that if you _can_ do it you might be able to get firstChild on trunk (if
> not now, then as we remove more redundany security checks).

We should split this into a new bug. Either getSVGDocument needs to do a security check or we need to wrap object elements in XOWs, even when same-origin (like we do for HTML[I]FrameElements.
Filed bug 455629.
ok, the description of this bug is flamable.

looks like bz got the idea of potential misuse and code injection.
Summary: universal xss with Content-Type: application/octet-stream, embed and svg - no plugins required → code injection with Content-Type: application/octet-stream, embed and svg - no plugins required
since the validity of this bug is questioned i won't reopen it if someone invalidates it.

>Oh, and we don't allow subdocuments in embed, except for SVG.

if this is true wouldn't treating svg content type specially be a nice ugly kludge?
>if this is true wouldn't treating svg content type specially be a nice ugly
>kludge?

this seems dumb. <object> has same trouble with at least text/html
Right.  That's what I said in comment 8.

Comment 27

8 years ago
Given the publicity around a similar issue with Flash, I find it hard to believe this will remain secret for long.

http://news.slashdot.org/story/09/11/12/2337236/Flash-Vulnerability-Found-Adobe-Says-No-Fix-Forthcoming?art_pos=1
Component: Security → SVG
Product: Firefox → Core
QA Contact: firefox → general

Comment 28

8 years ago
If I understand correctly, this is "[sg:high] against any site that allows uploads".
Flags: blocking1.9.2?
We could probably avoid dispatching eType_Document if the type was application/octet-stream or text/plain on the channel...  Would that help?

Comment 30

8 years ago
Not really.  It needs to be whitelist-based, since many sites allow anything to be uploaded as image/jpeg.
Uh... if it's uploaded as image/jpeg, we're not going to render it as SVG, so there's no problem.  Or am I missing something?
I don't think this should block, since it's in 1.9.1 and earlier. But it does seem to me we should do comment #29 ASAP. Boris, do you want to take this?
Flags: blocking1.9.2? → blocking1.9.2-
blocking1.9.1: --- → ?
status1.9.1: --- → wanted
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.17?
Whiteboard: [sg:low?] → [sg:low?][3.6.x]
Created attachment 413073 [details] [diff] [review]
Proposed fix

I assume that landing the testcase with the fix is not a problem, but if it is please tell me so!
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #413073 - Flags: review?(jst)
Component: SVG → DOM
QA Contact: general → general
Summary: code injection with Content-Type: application/octet-stream, embed and svg - no plugins required → [FIX]code injection with Content-Type: application/octet-stream, embed and svg - no plugins required

Updated

8 years ago
Attachment #413073 - Flags: review?(jst) → review+
Comment on attachment 413073 [details] [diff] [review]
Proposed fix

We might want to take this for 1.9.2...  I think this should be fairly safe web-compat wise.
Attachment #413073 - Flags: approval1.9.2?
blocking1.9.1: ? → .7+
Flags: blocking1.9.0.17? → blocking1.9.0.17+
Comment on attachment 413073 [details] [diff] [review]
Proposed fix

approval1.9.2 requests aren't currently being monitored, since we're nearing RC freeze and there are too many outstanding requests, so I'm clearing this request. Feel free to re-request approval if you are confident that it's worth drivers' time to consider whether this non-blocker needs to land for 1.9.2 at this stage.
Attachment #413073 - Flags: approval1.9.2?
Attachment #413073 - Flags: approval1.9.2?
Comment on attachment 413073 [details] [diff] [review]
Proposed fix

a192=beltzner

Need to keep an eye out for web compat issues, but need to get this in for rc
Attachment #413073 - Flags: approval1.9.2? → approval1.9.2+
Pushed http://hg.mozilla.org/mozilla-central/rev/71b14537359b
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Created attachment 415906 [details] [diff] [review]
1.9.2 branch merge
Pushed http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c76bdccb63c9
status1.9.2: --- → final-fixed
Created attachment 415907 [details] [diff] [review]
1.9.1 branch merge
Attachment #415907 - Flags: approval1.9.1.7?
Created attachment 415913 [details] [diff] [review]
1.9.0 merge
Attachment #415913 - Flags: approval1.9.0.17?
Comment on attachment 415913 [details] [diff] [review]
1.9.0 merge

Approved for 1.9.1.7 and 1.9.0.17, a=dveditz for release-drivers
Attachment #415913 - Flags: approval1.9.0.17? → approval1.9.0.17+
Attachment #415907 - Flags: approval1.9.1.7? → approval1.9.1.7+
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2e73012d6766

Checked into CVS:

Checking in content/base/test/Makefile.in;
/cvsroot/mozilla/content/base/test/Makefile.in,v  <--  Makefile.in
new revision: 1.82; previous revision: 1.81
done
RCS file: /cvsroot/mozilla/content/base/test/test_bug455472.html,v
done
Checking in content/base/test/test_bug455472.html;
/cvsroot/mozilla/content/base/test/test_bug455472.html,v  <--  test_bug455472.html
initial revision: 1.1
done
Checking in content/base/src/nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <--  nsObjectLoadingContent.cpp
new revision: 1.101; previous revision: 1.100
status1.9.1: wanted → .7-fixed
Keywords: fixed1.9.0.17
Boris, I have one question before verifying this fix. The 3rd testcase (demo for cross site getSVGDocument) should still fail? Or are both alert boxes expected?
The 3rd testcase should have two alerts; the first should say "doc=[object SVGDocument]" and the second should have "exception=....."
Verified fixed on 1.9.1 with builds on all platforms by running the above three testcases.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8pre) Gecko/20100128 Shiretoko/3.5.8pre (.NET CLR 3.5.30729) ID:20100128044603
OS: Linux → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.3a1
Keywords: verified1.9.1
Verified for 1.9.0.18 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.16pre) Gecko/2010020215 GranParadiso/3.0.18pre (.NET CLR 3.5.30729) using test cases.
Keywords: fixed1.9.0.18 → verified1.9.0.18
Whiteboard: [sg:low?][3.6.x] → [sg:low?]
Depends on: 455629
Whiteboard: [sg:low?] → [sg:moderate]
Alias: CVE-2010-0162
Depends on: 548290
Group: core-security
You need to log in before you can comment on or make changes to this bug.