Closed Bug 568395 Opened 15 years ago Closed 14 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: 14 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.