Closed Bug 568395 Opened 13 years ago Closed 12 years ago

Bypassing nsIScriptableUnescapeHTML.parseFragment()

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 562547

People

(Reporter: roberto.suggi, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 XPCOMViewer/0.9.2

Hi,

I have recently released a white paper named "Cross Context Scripting
with Firefox", which can be found at:

http://www.security-assessment.com/files/whitepapers/Cross_Context_Scripting_with_Firefox.pdf

After the release of this document, I have noticed that a CVE entry has
been created by NIST:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-1585

The bug is directly referring to the white paper I have released and in
particular to section "2.8 - Bypassing
nsIScriptableUnescapeHTML.parseFragment()". It appears NIST has
categorised that test case and its results as a bug. I have searched on bugzilla mozilla database to find the same bug but there is no entry and that's the reason why I am opening this bug.

Bug Details (copy/paste extract from white paper):

[...]
In this case, we will analyse an example of a vulnerable extension which trusts the nsIScriptableUnescapeHTML parsing function to filter untrusted content which is rendered in a Chrome privileged  window. A malicious user may bypass input filtering performed by the nsIScriptableUnescapeHTML parsing function and perform a XCS injection attack. This extension code is retrieving HTML content which is then appended to a DOM element. That element is part of the browser.xul page (status-bar), as can be seen in the code below:


<script>
var target = document.getElementById("status-bar");
[...]
var fragment = Components.classes["@mozilla.org/feed-unescapehtml;1"]
.getService(Components.interfaces.nsIScriptableUnescapeHTML).parseFragment
(payload, false, null, target);
target.appendChild(fragment);
[...]
</script>

The parseFragment() function performs filtering on both HTML and XML payloads passed via the payload variable. The table on the following page summarises some of the test cases attempted.

Case I (not vulnerable):

Payload:

&lt;textarea title=&quot;a&quot; id=&quot;1&quot; onfocus=&quot;alert(1)&quot;&gt;jjjj&lt;/textarea&gt;

Processed by parseFragment():

<textarea title="a" id="1">jjjj</textarea> 

Comment:

Event attributes such as onLoad, onmouseover are not appended to the DOM.


Case II (not vulnerable):

Payload:

&lt;iframe src=data:text/html;base64,YWFhYWFh width=10 height=3 /&gt;

Processed by parseFragment():

NULL

Comment:

<iframe> is not appended.


Case III (not vulnerable):

Payload:

a&lt;script&gt;dump(1)&lt;/script&gt;

Processed by parseFragment():

a

Comment:

<script> is not appended.


Case IV (vulnerable):

Payload:

&lt;a href=javascript:alert(window)&gt;a&lt;/a&gt;

Processed by parseFragment():

<a href="javascript:alert(window)">a</a>

Comment:

The href attribute points to a JavaScript URI scheme and it is appended to the DOM.


Case V (vulnerable):

Payload:

&lt;form action=&quot;javascript:alert(window)&quot;&gt;&lt;input type=submit&gt;&lt;/form&gt;

Processed by parseFragment():

<form action=”javascript:alert(window)”><input type=submit></form>

Comment:

This goes unfiltered as in the case above.


The last two test cases, using the javascript: URI produced interesting injection vectors for a malicious user. For example, in the <a href> element case, when a user clicks on the link the code will be executed with Chrome privileges.
Even if filtering is performed by the parseFragment() function, other avenues of attack exist by injecting and/or storing potential code that can be triggered by a specific sequence of steps (e.g. click a link, select an option, submit a form).

Please let me know if you require further information.

Regards,

Roberto Suggi Liverani

Reproducible: Always
I think Ehsan's work in bug 520189 might fix this...
Depends on: CVE-2010-2769
(In reply to comment #1)
> I think Ehsan's work in bug 520189 might fix this...

I don't think so.  That bug only changes the behavior of the editor.

BTW, shouldn't this live in the security group?
Given that there's a public paper and CVE with details?  Not sure.
So in particular, you're not changing the paranoid sinks to screen URI attributes?
(In reply to comment #4)
> So in particular, you're not changing the paranoid sinks to screen URI
> attributes?

Not any more than they already do:

<http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsHTMLFragmentContentSink.cpp#976>

But apparently those checks are not enough.  Should we just check and disallow the javascript scheme there?
Hmm.  That CheckLoadURI check will filter out javascript: URIs in all cases except when mTargetDocument->NodePrincipal() is the system principal.  Is that the case here?  It would make a lot of sense to me to use a null principal for this check if the target document is system.
Judging from this in comment 0, I think that's what's happening here:

> In this case, we will analyse an example of a vulnerable extension which trusts
> the nsIScriptableUnescapeHTML parsing function to filter untrusted content
> which is rendered in a Chrome privileged  window
Yeah, then we should do what I suggest in comment 6, I think.
Hi all,

Has this bug being fixed? Please see announcement below: http://www.mozilla.org/security/announce/2011/mfsa2011-08.html

Also, I cannot access https://bugzilla.mozilla.org/show_bug.cgi?id=562547
which is linked in that announcement so I am not sure what the fix relates to.

Also, I am not a Mozilla Security Developer, as reported in that link :-).

Thanks,

Roberto Suggi Liverani
> Has this bug being fixed?

I'm not sure.  Daniel, is this the same issue as bug 562547?

> Also, I am not a Mozilla Security Developer, as reported in that link :-).

You're not, but the person who reported bug 562547 (about a month before you reported this bug) is.
Hi Boris,

Thanks for your input. Just to clarify a bit what happened from my side:

- 28th April 2010 - This bug was originally released within this whitepaper - http://www.security-assessment.com/files/whitepapers/Cross_Context_Scripting_with_Firefox.pdf

- 28th April 2010 - NIST has created a CVE entry (CVE-2010-1585) for the bug reported on the white paper. The same CVE ID is referred in the Mozilla announcement: http://www.mozilla.org/security/announce/2011/mfsa2011-08.html

- 26th May 2010 - Filed this bug in bugzilla.

Cheers,

Roberto
Ah, I see.  Daniel reported bug 562547 based on the CVE.  So yes, this is fixed.  I'll mail Daniel about the mis-attribution.  Thanks for bringing this up!
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Oh, and you should have access to bug 562547 now.
Oh, it's attributed correctly.  Just the description of who you are is wrong.  OK, then!  Still mailing Daniel.  ;)
And my apologies for not reading more carefully!
Hi Boris,

No worries for that ;-).

Since this issue has been resolved, is it possible to have have that link http://www.mozilla.org/security/announce/2011/mfsa2011-08.html rectified?

Or should I contact someone in particular to get the page rectified?

Instead of Mozilla Security Developer -> Security Consultant for Security-Assessment.com ;-)

Cheers,

Roberto
Roberto, I did mail Daniel Veditz about that.  I _think_ he's the right contact for that...

If nothing there changes in a few days, please ping me again?
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.