User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Steps to reproduce: I confirm the reproducibility in the following versions. Firefox 44.0.2 Firefox Beta 45.0b5 Firefox ESR 38.6.1 1. Please access the following page. http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/ ( or http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/www/ ) 2. Wait for about seven seconds. Actual results: Will display an iframe containing the HTML content of file: uri scheme. However, can't get DOM of the iframe. I think not correct that this information is displayed in the iframe. In addition, there is a possibility this exists approach for completely bypass. Expected results: If trying to change a protocol to view-source: uri scheme, that should not be successful. In Nightly it has become that way.

(the ability for web pages to link to view-source was removed in bug 1172165)

Yes, this is fixed by bug 1172165. The testcase given is basically doing this: var lp = function() { fc.location.protocol = "data"; }; var dw = function() { fc.document.body.innerHTML = "<svg onload=document.write(1)>"; }; var lr = function() { fc.location.reload(); }; var lpn = function() { fc.location.pathname = path }; var lp2 = function() { fc.location.protocol = "view-source"; }; which is quite similar to the technique used in bug 1193093 and bug 1245264 (the latter filed by the same reporter as this bug). In any case, backporting bug 1245264 may well fix the issue described in this bug. Needs checking.

Tentatively moving this to docnav. I'll try to test if backporting bug 1245264 fixes this one tomorrow. ni to self for that.

At least at first glance it does. With the patch for bug 1245264 applied locally to a beta tree (which otherwise contained a raw FTP-listing-formatted file listing), we get: JavaScript error: http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/, line 31: NS_ERROR_MALFORMED_URI: JavaScript error: http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/, line 31: NS_ERROR_MALFORMED_URI: JavaScript error: http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/, line 34: Error: Access to 'wyciwyg:file:///Users/' from script denied JavaScript error: http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/, line 35: NS_ERROR_MALFORMED_URI: and the testcase stops at "STEP: 4 / 7". Similar for http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/www/

Note that the "www" case is not a problem before the patches either, because it never allows access to the text, modulo timing attacks (and just loading another site in a subframe is something you can do anyway). The file:// case is a problem insofar as it can hang the browser or cause other damage by reading "interesting" filenames like /dev/tty and whatnot.

(In reply to Boris Zbarsky [:bz] from comment #4) > At least at first glance it does. With the patch for bug 1245264 applied > locally to a beta tree (which otherwise contained a raw > FTP-listing-formatted file listing), we get: > and the testcase stops at "STEP: 4 / 7". Similar for > http://poc.vuln.jp/firefox/trunk/bypass/cross_origin/www/ Clearing needinfo based on this... please ping me if you still expected me to do more testing; it sounds like that is essentially bug 1245264 working as intended.

Is this an effective dupe of bug 1245264 or is it just that the particular testcase uses some of the same techniques?

(In reply to Boris Zbarsky [:bz] from comment #5) > Note that the "www" case is not a problem before the patches either, because > it never allows access to the text, modulo timing attacks (and just loading > another site in a subframe is something you can do anyway). we did restrict view-source: in an iframe prior to bug 1172165, and this technique bypassed that. You may not be able to reach into the cross-origin frame directly but Paul Stone, for example, created several good "click-dragging" PoCs that were able to use this to steal cross-origin info.

(In reply to Al Billings [:abillings] from comment #7) > Is this an effective dupe of bug 1245264 or is it just that the particular > testcase uses some of the same techniques? It's certainly not an exact dupe. I think making it depend on that bug is fine. As I suggested in bug 1171853 comment 9, it might make sense to implement further restrictions on view-source: which would further limit the potential for damage via the route used in this exploit.

Dan, who determined that 46 was still affected? AFAICT this is fixed on 45+ and esr38 from the version we released with 45. I couldn't reproduce with the testcase from comment #0 using 46 beta. Can you clarify?

hm, I maybe have only gotten as far as "Yes, this is fixed by bug 1172165" in comment 2 (fixed in 47), or maybe I dismissed the comments about bug 1245264 fixing it because this one remained open even after those comments. So this is fixed everywhere then, and the bug itself can be resolved fixed?

(In reply to Daniel Veditz [:dveditz] from comment #11) > hm, I maybe have only gotten as far as "Yes, this is fixed by bug 1172165" > in comment 2 (fixed in 47), or maybe I dismissed the comments about bug > 1245264 fixing it because this one remained open even after those comments. > So this is fixed everywhere then, and the bug itself can be resolved fixed? I believe that bug 1245264 fixes this, yes.

Confirmed issue in Fx44, verified fixed in Fx45.0.2 release.