1317023 - e10s - Address bar spoof using privileged URI schemes in drag n drop

Status: RESOLVED FIXED

(Core :: DOM: Events, defect, P2)

Description

[Abdulrahman Alqabandi]

Attachment: wut.html

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

Steps to reproduce:

Note: This is similar to Bug 791597 however I assume the method here is different since that one uses non existent ports/long response time.

Drag n drop the anchor tag in attached PoC. Do the same with the others to see different types.




Actual results:

Since wyciwyg urls are not loaded, they seem to stay in the addressbar and nothing happens even if you hit enter within the addressbar after drag and dropping. (Which is why I find wyciwyg ideal since both about and data uris try to load when you hit enter after dropping)

If the wyciwyg is long enough we end up being able to obfuscate the 'wyciwyg:' part of the url which helps in selling the spoof more. This may not work for you since my resolution is different but I'm sure this part could be modified with the users resolution taken into account.

I also noticed similar behavior with data URI scheme, except if a user were to hit enter after drag and dropping they would end up going to the data uri.


Expected results:

With chrome if you attempt to drag n drop privileged URI schemes it will show you about:blank, so something similar to this would be enough.

Comment 1

[Abdulrahman Alqabandi]

Attachment: screenshot of the resulting spoof (taken right after drop with no other actions taken)

Comment 2

[Abdulrahman Alqabandi]

Just noticed that this works on latest nightly fully, however, on latest stable (49.0.2) only the data URI one works, possible regression?

Comment 3

[Abdulrahman Alqabandi]

Ran mozregression

2015-04-10 <-- PoC worked
2015-04-09 <-- PoC did not work

Comment 4

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi[test] from comment #2)
> Just noticed that this works on latest nightly fully, however, on latest
> stable (49.0.2) only the data URI one works, possible regression?

Given the regression window is over a year ago, is this an e10s change? Can you just post a pushlog regression window, assuming you're using mozregression anyway?

Also, this is potentially a dupe of bug 1217387.

Comment 5

[Abdulrahman Alqabandi]

I wish I could help more but for some reason mozregression crashes after finding the two dates that are separated by a day. No idea how to get what you asked for.

For what its worth, the crash dialog gives me the following:
-----------
platform: Windows-8.1-6.3.9600
python: 2.7.12 FROZEN (32bit)
mozregui: 0.9.4
mozregression: 2.3.8
message: IOError: [Errno 9] Bad file descriptor
traceback:   File "C:\Python27\lib\threading.py", line 774, in __bootstrap
    # random exception *** while trying to report the exception in
  File "C:\Python27\lib\threading.py", line 814, in __bootstrap_inner
    except:


------------------------------------
platform: Windows-8.1-6.3.9600
python: 2.7.12 FROZEN (32bit)
mozregui: 0.9.4
mozregression: 2.3.8
message: TaskclusterRestFailure: 9TjO4tSgQSq2xaljtj1Uww does not correspond to a task that exists.
Are you sure this task exists?
----
errorCode:  ResourceNotFound
statusCode: 404
requestInfo:
  method:   status
  params:   {"taskId":"9TjO4tSgQSq2xaljtj1Uww"}
  payload:  {}
  time:     2016-11-12T14:34:58.629Z
details:
{
  "taskId": "9TjO4tSgQSq2xaljtj1Uww"
} - {
    "requestInfo": {
        "time": "2016-11-12T14:34:58.629Z",
        "params": {
            "taskId": "9TjO4tSgQSq2xaljtj1Uww"
        },
        "method": "status",
        "payload": {}
    },
    "message": "9TjO4tSgQSq2xaljtj1Uww does not correspond to a task that exists.\nAre you sure this task exists?\n----\nerrorCode:  ResourceNotFound\nstatusCode: 404\nrequestInfo:\n  method:   status\n  params:   {\"taskId\":\"9TjO4tSgQSq2xaljtj1Uww\"}\n  payload:  {}\n  time:     2016-11-12T14:34:58.629Z\ndetails:\n{\n  \"taskId\": \"9TjO4tSgQSq2xaljtj1Uww\"\n}",
    "code": "ResourceNotFound",
    "details": {
        "taskId": "9TjO4tSgQSq2xaljtj1Uww"
    }
}
traceback:   File ".\mozregui\bisection.py", line 72, in bisect_further
  File "..\mozregression\bisector.py", line 585, in bisect
  File ".\mozregui\bisection.py", line 98, in _bisect
  File ".\mozregui\bisection.py", line 132, in _bisect_next
  File "..\mozregression\bisector.py", line 384, in init_handler
  File "..\mozregression\bisector.py", line 72, in initialize
  File "..\mozregression\build_range.py", line 94, in __getitem__
  File "..\mozregression\build_range.py", line 41, in build_info
  File "..\mozregression\build_range.py", line 35, in _fetch
  File "..\mozregression\fetch_build_info.py", line 143, in find_build_info
  File "C:\Python27\lib\site-packages\taskcluster\sync\Queue.py", line 88, in status
  File "C:\Python27\lib\site-packages\taskcluster\sync\syncclient.py", line 60, in makeHttpRequest
  File "C:\Python27\lib\site-packages\taskcluster\sync\syncclient.py", line 92, in _makeHttpRequest
  File "C:\Python27\lib\site-packages\taskcluster\baseclient.py", line 337, in _raiseHttpError

------------------------

I'd be happy to post a pushlog regression window if you could tell me what I'm doing wrong?

Comment 6

[:Gijs (he/him)]

I actually can't reproduce with the wyciwyg or about links on either current beta 50 or on the builds from 2015, so I'm not sure how to help track this down. On e10s builds from those dates in 2015, I can't drag the links at all to begin with (never mind dragging them on the location bar, which I presume is what you're doing - comment #0 is not very clear).

Are you reproducing in e10s? Non-e10s? Both? Does it work on a clean profile?

Comment 7

[:Gijs (he/him)]

(also, not sure how the data: URL drag would really mean anything, because you could just link to the data URI, which would behave the same, and there's no way that we can break that)

Comment 8

[Abdulrahman Alqabandi]

Attachment: mozspoof.png

I'm using mozregression with clean profile and re-downloaded '2015-04-10' firefox nightly 64 bit

One other thing that may or may not affect the outcome is that I'm on a touchscreen enabled laptop which could potentially mess around with some things?

Comment 9

[Abdulrahman Alqabandi]

Oh also I'm on windows 8.1 64 bit. I will set up a couple of VMs and see what I get.

Comment 10

[:Gijs (he/him)]

I can reproduce with e10s on now, it seems. I wonder if this is e10s-specific (my 50 beta install has e10s turned off).

Comment 11

[:Gijs (he/him)]

m-c pushlog:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f57f60ee58a&tochange=fec90cbfbaad

Comment 12

[:Gijs (he/him)]

That'd be bug 936092, it seems, considering I can't drag any links in e10s before that bug anyway.

Comment 13

[:Gijs (he/him)]

Can you reproduce this outside of e10s? (on non-release builds, you can go to tools > options > untick ("Enable e10s (multi-process)" or "Enable multi-process Nightly", depending on how old the build is)

Comment 14

[Abdulrahman Alqabandi]

I can confirm this does not work when I untick multi-process, tested on latest nightly.

Comment 15

[:Gijs (he/him)]

The problem is that we hit this check when we do a drop on the location bar:

https://dxr.mozilla.org/mozilla-central/rev/5e76768327660437bf3486554ad318e4b70276e1/dom/base/contentAreaDropListener.js#125-127

and at that point in e10s the mozSourceNode is the XUL <browser> from which the drag originated, which as a nodePrincipal of course has the principal of browser.xul... which means 'anything goes'.

The impact of the location bar drag here is very minimal, but I'm worried that potentially other drags would be more dangerous.

Talking to Olli on IRC, I think we need to find a way to send the content principal along as part of the drag data directly, instead of the source node. The principal is serializable so this should work even in the e10s case. Olli suggested that it should be enough to modify:

http://searchfox.org/mozilla-central/rev/8562d3859b89ac89f46690b9ed2c473e0728d6c0/widget/nsDragServiceProxy.cpp#68,77

and have the receiving side store the principal on the data transfer, exposing it through a [ChromeOnly] attribute so the chrome code can check it.

Comment 16

[Abdulrahman Alqabandi]

Oh so according to what Comment 15 says we can open any URL using drag and drop (if we drag n drop to a new tab) tested file: urls and about:, did not think of that! I will try to see if anything more severe could be done.

Comment 17

[Abdulrahman Alqabandi]

Sort of off-topic: Is it intended behavior that you can't drag and drop a data URI and open it in a new tab? Works on chrome but not on FF.

Comment 18

[Abdulrahman Alqabandi]

Attachment: DnD-PoC.html

Another interesting behavior, does not work when e10s is off.

Open Google Chrome (or IE, not sure if it will work on edge or other browsers) and go to 'https://jpillora.com/base64-encoder/' this website simply grabs any files dropped and turns them into base64 encoded data uri.

Now open the new PoC on firefox then drag and drop the invalid image into the other browser and into that website. The full content of file:///C: is sent

Comment 19

[Abdulrahman Alqabandi]

Note: discard the instructions within the PoC in the last comment I just made, its really late and I get sloppy :P (that PoC is originally on another report I have)

Comment 20

[:Gijs (he/him)]

Andrew, is there someone in platform who would be available to work on this? I need to focus on other things right now, but I think the current state is problematic enough that it should be addressed sooner rather than later.

Comment 21

[Abdulrahman Alqabandi]

May I get an update on this bug, please?

Comment 22

[Al Billings [:abillings - ex-MoCo]]

(In reply to Abdulrahman Alqabandi from comment #21)
> May I get an update on this bug, please?

Please don't post this in each of your bugs. If there are any updates, they will appear in bugzilla comments and changes. If you don't see either, there are no updates.

Comment 23

[:Gijs (he/him)]

This was mitigated in bug 1379842 (for 56 and later) by using the content principal when the source node is a XUL:browser. This isn't quite perfect in the iframe case, but it makes the cases in this bug unexploitable, I believe.

Abdulrahman, can you verify that this is right?

Dan, should we open this up?

Comment 24

[Tooru Fujisawa [:arai]]

(In reply to :Gijs from comment #23)
> Dan, should we open this up?

given that the target of this bug is 52, ESR is still affected, right?

Comment 25

[Abdulrahman Alqabandi]

(In reply to :Gijs from comment #23)
> This was mitigated in bug 1379842 (for 56 and later) by using the content
> principal when the source node is a XUL:browser. This isn't quite perfect in
> the iframe case, but it makes the cases in this bug unexploitable, I believe.
> 
> Abdulrahman, can you verify that this is right?
> 
> Dan, should we open this up?

Yes, tested latest nightly and stable and looks good to me. Will do more testing and will comment again if I find anything.
P.S. Apologies for the late reply.

Comment 26

[:Gijs (he/him)]

Olli, do you want to mark this as fixed for 56+ but keep hidden (because 52esr as comment #24 notes) or do you think there's more left to do here?

Comment 27

[Olli Pettay [:smaug][[e-mail]]]

Probably not more to do here, but should we consider to take bug 1379842 to esr if possible.

Comment 28

[Daniel Veditz [:dveditz]]

Spoofing bugs usually don't meet the bar for ESR backporting; the next ESR is coming soonish (will be based on current Nightly) so people won't have too long to wait. Unsure how well this fix will backport since we've done a bunch-- we did have triggeringPrincipal on the ESR branch but we've had a lot of fixes since so it might not be in good shape.This probably doesn't meet the bar