1322864 - SOP bypass using drag and drop of image.

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Abdulrahman Alqabandi]

Attachment: PoC-SOPB.html

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

Steps to reproduce:

When closing opened popups whilst dragging an image from that popups the dragged object contains a File object once dropped on cross origin document.

1. Open attached PoC
2. Press button to open window
3. Attempt to drag the box as instructed
4. After popup closes, drop the 'image' anywhere on the document

We end up with full contents of a cross origin website.


Actual results:

A file object is created for some reason with the contents of a cross origin image, despite the image being invalid.


Expected results:

Same as when we don't close the window, no File object should be created unless the image loads, even then we should block it if the image is cross origin.

Comment 1

[Abdulrahman Alqabandi]

Works on latest nightly, not latest stable.

Comment 2

[Abdulrahman Alqabandi]

Ran moz regression.  Build '2015-04-10' is first bad (where PoC works) occurrence, couldn't dig deeper, mozreggresion kept crashing.

Comment 3

[Abdulrahman Alqabandi]

Does not work on nightly if multi-process is disabled.

Comment 4

[Abdulrahman Alqabandi]

Also, it's possible to view arbitrary files on local disk if you open PoC within file URI scheme and change the image on the popup to the random file on disk.

Comment 5

[:Gijs (he/him)]

Given that this is e10s-specific, I suspect this is basically the same problem as bug 1317023.

Comment 6

[Abdulrahman Alqabandi]

(In reply to :Gijs Kruitbosch from comment #5)
> Given that this is e10s-specific, I suspect this is basically the same
> problem as bug 1317023.

To be specific, I think this is the same bug as Comment 18 in Bug 1317023. I don't see a connection with the initial address bar spoof since it uses anchor tags. We can still open arbitrary file:// urls if we use the PoC here. We just set the image within popups src to be 'file:///C://' and then instead of dropping the image into document we try to open new tab, we bypass restrictions.

I think there is atleast something to be said about the behavior of dragging objects from closed windows. Chrome for example removes any dragged objects once a popup closes.

Comment 7

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi[test] from comment #6)
> (In reply to :Gijs Kruitbosch from comment #5)
> > Given that this is e10s-specific, I suspect this is basically the same
> > problem as bug 1317023.
> 
> To be specific, I think this is the same bug as Comment 18 in Bug 1317023. I
> don't see a connection with the initial address bar spoof since it uses
> anchor tags. We can still open arbitrary file:// urls if we use the PoC
> here. We just set the image within popups src to be 'file:///C://' and then
> instead of dropping the image into document we try to open new tab, we
> bypass restrictions.
> 
> I think there is atleast something to be said about the behavior of dragging
> objects from closed windows. Chrome for example removes any dragged objects
> once a popup closes.

I don't see why the window being closed matters in this specific case. I believe that the thing that's going wrong here is origin checks for the source of the drag. I pretty much told you this verbatim in bug 1317023. Your non-local webpage shouldn't be able to link to file:///. This check is used in more places than just the URL bar, so I believe addressing that check in bug 1317023 will also fix this bug.

Comment 8

[:Gijs (he/him)]

Actually, looking at this again, maybe I'm wrong and something else fishy is going on here. Also, this crashes on beta on OS X...

https://crash-stats.mozilla.com/report/index/84b678a9-820e-4065-9cb5-4aa322161215

Comment 9

[Abdulrahman Alqabandi]

I would like to just clarify Comment 6, even with multi-process off we can still open file:// uri schemes by drag and dropping an image from a closed popup into a new tab.

Also, shouldn't this be sec-high given the ability to read cross-origin websites (with credentials)? Or will the main SOP bypass here be dealt with in Bug 1317023 and this report will deal with drag and drop from closed windows?

Comment 10

[Neil Deakin]

Isn't the real bug here that we should be validating that the content is really an image? Dragging an image from one origin to another isn't a security issue.

That the source has closed doesn't seem particularly concerning either.

Comment 11

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #10)
> Isn't the real bug here that we should be validating that the content is
> really an image? Dragging an image from one origin to another isn't a
> security issue.
> 
> That the source has closed doesn't seem particularly concerning either.

Potentially, yes. Hector, are we 'just' missing similar checks to the ones you added in bug 1318736 here?

Comment 12

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi[test] from comment #9)
> I would like to just clarify Comment 6, even with multi-process off we can
> still open file:// uri schemes by drag and dropping an image from a closed
> popup into a new tab.

Can you reconcile this with comment #3 ? What are the exact steps that produce something problematic with e10s off, and/or can you upload a new testcase for this problem?

Comment 13

[Abdulrahman Alqabandi]

Attachment: poc.html

(In reply to Neil Deakin from comment #10)
> Isn't the real bug here that we should be validating that the content is
> really an image? Dragging an image from one origin to another isn't a
> security issue.
> 
> That the source has closed doesn't seem particularly concerning either.

The security issue is that we can read full content of external documents with full credentials which can only be achieved if we drag n drop an image from a closed popup. 


(In reply to :Gijs Kruitbosch from comment #12)
> Can you reconcile this with comment #3 ? 

Comment #3 is in reference to the behavior here, ability to read external documents using drag and drop of an image that points to an external website. 

Initially you thought this may be related to Bug 1317023 which is a bug where alongside spoofing, you could also open file:// URI schemes by drag and dropping anchor tags to a new tab, but its e10s specific, as in if multi-process is turned off it wont work.

In comment #5 I tried to prove that this main bug (SOP bypass) is not related to Bug 1317023 (the e10s specific spoof/open file uri scheme), but I failed at mentioning something which I clarified in comment #9. I was trying to say that we can still open file:// URLS (not read them) even if e10s was off, again, to prove that its not related to the e10s specific bug where we can open file: urls only with e10s enabled.


> What are the exact steps that
> produce something problematic with e10s off, and/or can you upload a new
> testcase for this problem?

I attached the testcase that will result in opening file:///C:// (by opening I mean navigate to the URL and not read it) with multi-process off.

1. Open attached PoC, click button
2. Once popup appears, attempt to drag and drop the image into a new tab on your main window
3. 'file:' url opened with multi-process off.

Comment 14

[Abdulrahman Alqabandi]

Here are the different DnD objects (with e10s and without) note that this has to do with this bug (reading external documents) which does not work with e10s off, might shed some light at the issue.

I am basically grabbing a dropped object and trying to grab all the content types within it as well as checking if a file object exists. 

---------------With e10s OFF---------------------------------------------------------------------
text/x-moz-url>>>https://www.mozilla.org/en-US/test
https://www.mozilla.org/en-US/test
text/x-moz-url-data>>>https://www.mozilla.org/en-US/test
text/x-moz-url-desc>>>https://www.mozilla.org/en-US/test
text/uri-list>>>https://www.mozilla.org/en-US/test
text/_moz_htmlcontext>>><html><body></body></html>
text/_moz_htmlinfo>>>0,0
text/html>>><img id="q" src="https://www.mozilla.org/en-US/test" style="border:1px solid red;width:100px;height:100px;">
text/plain>>>https://www.mozilla.org/en-US/test
application/x-moz-file-promise-url>>>https://www.mozilla.org/en-US/test
application/x-moz-file-promise-dest-filename>>>test.htm
-----------------
fileLen:0


---------------With e10s ON---------------------------------------------------------------------
text/uri-list>>>https://www.mozilla.org/en-US/test
application/x-moz-file>>>
Files>>>
-----------------
fileLen:1 <-- this is the object where the contents of 'https://www.mozilla.org/en-US/test' reside.

Comment 15

[Abdulrahman Alqabandi]

One last thought, I think there is a feature that handles drag and dropping things from cross-applications, specifically from the Firefox browser to things like Word documents or anything else. 
I noticed that there is a big difference between dragged objects dropping from and to the same Firefox window and from Firefox to say Google Chrome, this bug here essentially (I assume) tricks Firefox into thinking the dropped object came from an external source. 

https://www.mozilla.org/en-US/security/advisories/mfsa2016-81/ According to the description of that bug (cant access the actual report yet) there is in fact something happening during cross-application DnD's

Comment 16

[Abdulrahman Alqabandi]

Hrmm, I just realized its possible to read valid images from cross-origin (in the form of a file object) with multi-process disabled... Can't read webpages though

So it seems there is still an SOP bypass with or without e10s.

Comment 17

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi[test] from comment #16)
> Hrmm, I just realized its possible to read valid images from cross-origin
> (in the form of a file object) with multi-process disabled... Can't read
> webpages though
> 
> So it seems there is still an SOP bypass with or without e10s.

I would expect that to work with Chrome, Edge and other browsers as well. As Neil said in comment #10, dragging an image from one origin to another isn't a security issue - as a user, I should be able to say, open an image in one tab, and drag it into a google doc in another tab, irrespective of the origin of the image.

It becomes a security issue if you can do this with non-image data and trick the user into disclosing data other than a valid image (an image which they can see, of course).

Comment 18

[Abdulrahman Alqabandi]

Ah, I was under the impression reading valid cross-origin images was an SOP violation. I believe Google gave me this impression from this bug https://bugs.chromium.org/p/chromium/issues/detail?id=380885

Comment 19

[Abdulrahman Alqabandi]

Also, I do agree that dragging an image from one place to another should be allowed and is not a security issue. But I think (correct me if im wrong) that usually there is a server in the middle that requests the images data without the users credentials and then serves it. Or if we are talking about 'contentEditable' elements having images in them, usually its an img tag copy pasted. I think the fact that the request to receive the image is done with credentials is whats bothersome. 

Say a website serves your profile picture using a fixed file like 'profile.php' and it reads off from your cookies to see who you are. If one wants to save this picture to an external application like word then fine, but to drag and drop it within firefox and still allows us to get the full data as if we were you? I think thats problematic.

When I drag and drop an image from one tab to another (in chrome) I get the following dropped object:

-----------------
text/plain>>>http://i.imgur.com/W7FBWyM.jpg
text/uri-list>>>http://i.imgur.com/W7FBWyM.jpg
text/html>>><img style="-webkit-user-select: none" src="http://i.imgur.com/W7FBWyM.jpg">
-----------------
fileLen:0
--------------------------

Now the same using firefox:

text/x-moz-url>>>http://i.imgur.com/W7FBWyM.jpg
http://i.imgur.com/W7FBWyM.jpg
text/x-moz-url-data>>>http://i.imgur.com/W7FBWyM.jpg
text/x-moz-url-desc>>>http://i.imgur.com/W7FBWyM.jpg
text/uri-list>>>http://i.imgur.com/W7FBWyM.jpg
text/_moz_htmlcontext>>><html><body></body></html>
text/_moz_htmlinfo>>>0,0
text/html>>><img src="http://i.imgur.com/W7FBWyM.jpg" alt="http://i.imgur.com/W7FBWyM.jpg">
text/plain>>>http://i.imgur.com/W7FBWyM.jpg
application/x-moz-file-promise-url>>>http://i.imgur.com/W7FBWyM.jpg
application/x-moz-file-promise-dest-filename>>>W7FBWyM.jpg
-----------------
fileLen:0

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

Notice there is never a File object. Only when we drag an image from a closed popup do we get a file object.

I understand it is normal to drag and drop an image from Firefox to a word document, but within Firefox itself it should not be allowed.

Comment 20

[Abdulrahman Alqabandi]

Was looking at the crash in comment #8, looks like its a UaF? Should that be a separate bug report, or?

Comment 21

[Hector Zhao [:hectorz]]

(In reply to :Gijs Kruitbosch from comment #11)
> (In reply to Neil Deakin from comment #10)
> > Isn't the real bug here that we should be validating that the content is
> > really an image? Dragging an image from one origin to another isn't a
> > security issue.
> > 
> > That the source has closed doesn't seem particularly concerning either.
> 
> Potentially, yes. Hector, are we 'just' missing similar checks to the ones
> you added in bug 1318736 here?

My guess is additional check would be helpful, but I'm not really familiar with the involved code to provide meaningful feedback here. Sorry.

Comment 22

[Abdulrahman Alqabandi]

Is there anyone who is willing to take this bug? I have no clue who is better at DnD mechanics.

Comment 23

[Abdulrahman Alqabandi]

https://www.mozilla.org/en-US/security/advisories/mfsa2011-25/

This bug (url above) steals images from remote websites, proving that grabbing images from cross-domain is a security issue.

Comment 24

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #23)
> https://www.mozilla.org/en-US/security/advisories/mfsa2011-25/
> 
> This bug (url above) steals images from remote websites, proving that
> grabbing images from cross-domain is a security issue.

I'm not familiar with that bug, but I would expect it to not involve user interaction. As has been explained repeatedly on this bug, it's expected that you can drag files and images into websites to allow them access to those files/images. So "grabbing images from cross-domain" is only a security issue if not explicitly done via user interaction.

Comment 25

[:Gijs (he/him)]

Andrew, do you know who could own this?

Comment 26

[Andrew McCreight [:mccr8]]

Neil, is this something you could work on? Thanks.

Comment 27

[Abdulrahman Alqabandi]

(In reply to :Gijs from comment #24)
> (In reply to Abdulrahman Alqabandi from comment #23)
> > https://www.mozilla.org/en-US/security/advisories/mfsa2011-25/
> > 
> > This bug (url above) steals images from remote websites, proving that
> > grabbing images from cross-domain is a security issue.
> 
> I'm not familiar with that bug, but I would expect it to not involve user
> interaction. As has been explained repeatedly on this bug, it's expected
> that you can drag files and images into websites to allow them access to
> those files/images. So "grabbing images from cross-domain" is only a
> security issue if not explicitly done via user interaction.

Ah ok, that makes more sense now. Thank you

Comment 28

[Neil Deakin]

To fix the invalid image issue one would likely need to add a check for this within nsContentUtils::GetImageFromContent. I don't know what such a check would be.

I don't think there is any other issue here.

Comment 29

[Abdulrahman Alqabandi]

May I get an update on this bug, please?

Comment 30

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

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

There is no update. If there was, it would be here.

Comment 31

[Abdulrahman Alqabandi]

Attachment: thing.html

Updated the original PoC since it was relying on the (now disabled) ability to programmatically navigate/open a data:text/html, url.

Modified it to work with latest FF (tested latest nightly). Replaced Data: with blob:

Hope someone can work on this soon.

Comment 32

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #31)

Created attachment 9104483 [details]
thing.html

Updated the original PoC since it was relying on the (now disabled) ability to programmatically navigate/open a data:text/html, url.

Modified it to work with latest FF (tested latest nightly). Replaced Data: with blob:

Hope someone can work on this soon.

I can't reproduce with the new testcase on macOS, Firefox 71 beta or nightly 72a1, even after downloading and serving on localhost (to avoid potential for breakage due to bmo's CSP). The files[0] on the datatransfer is undefined. What OS did you test on? Is there somewhere specific I should be dropping the box? Is it possible closing the origin window is breaking this (maybe I'm too slow dropping the image?)

Comment 33

[Abdulrahman Alqabandi]

Attachment: tester.mp4

(In reply to :Gijs (he/him) from comment #32)

I can't reproduce with the new testcase on macOS, Firefox 71 beta or nightly 72a1, even after downloading and serving on localhost (to avoid potential for breakage due to bmo's CSP). The files[0] on the datatransfer is undefined. What OS did you test on? Is there somewhere specific I should be dropping the box? Is it possible closing the origin window is breaking this (maybe I'm too slow dropping the image?)

I tested on Windows 10 home on Nightly 72.0a1 (2019-10-27) (64-bit). Attached video of it in action. Notice there is a little lag in the drag motion somewhere there, I believe its possible if you drop too soon it may not work.

But just to be sure, could you instead drag and drop the broken image (from popup) into the big 'O' located in https://leucosite.com/dnds.html (drop it on the top most O)

For me, I am getting an HTML file with name 'test.html' containing the content of Mozilla website. I would like to see what doing this looks on your OS. (if you dont manage to repro by adjusting steps)

Comment 34

[Abdulrahman Alqabandi]

Forgot one thing

Is there somewhere specific I should be dropping the box?

Make sure to drop it within document and outside of the textarea.

Comment 35

[:Gijs (he/him)]

I can repro on Windows. I get the same content on the leucosite thing, with two exceptions - one is that the x-moz-file-promise-dest-filename is test.html on Windows and just test on Mac. Making the target URL end in test.html fixes that, but doesn't make it work.
The other difference is that on mac, there's a text/_moz_requestmime type, which brought me to https://searchfox.org/mozilla-central/source/dom/base/nsContentAreaDragDrop.cpp#248,256-257, which makes me think something probably breaks there if we get a non-image response. So yay, mac is not affected, more or less by accident I guess?

Anyway, this has actually led me to some of the relevant code at https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/dom/base/nsContentAreaDragDrop.cpp#680 so I will see if I can get a patch for this together.

Comment 36

[:Gijs (he/him)]

Attachment: Bug 1322864, r?NeilDeakin

Comment 37

[:Gijs (he/him)]

https://hg.mozilla.org/integration/autoland/rev/c955ff5ec94ad725d97c66bd01ae15214b475dc5

Comment 38

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/c955ff5ec94a

Comment 39

[:Gijs (he/him)]

I think we should uplift this but it seems sensible to wait at least a little bit to see if we've accidentally broken something people were relying on in terms of copying/dragging images. I'll request uplift for beta next week. Ni to remind myself.

Comment 40

[:Gijs (he/him)]

Comment on attachment 9104890 [details]
Bug 1322864, r?NeilDeakin

Beta/Release Uplift Approval Request

• User impact if declined: security risk of dragging things that are pretending to be images but aren't
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0 with the attachment from comment #31. Drag the black square to the area to the left of the text input in the main window. We shouldn't get HTML output in the text area. AFAICT this was never reproducible on mac.
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): I'm just moving a security check into a utility function to ensure checks we added for copy/paste also apply to drag/drop
• String changes made/needed: nope

Comment 41

[ovidiu boca[:Ovidiu]]

I verified this issue on Windows 10 x 64 with FF 72.0a1(2019-11-03) and I can't reproduce the issue from comment 0 using the attachment from comment 31. Based on this I will mark this issue as verified.

Note: I was able to reproduce the issue on FF Release 70, and I also tested the issue on Mac OS X 10.14 and Ubuntu 16.04 but I couldn't reproduce it, the only OS where this issue is repro is on Windows.

Comment 42

[Pascal Chevrel:pascalc]

Comment on attachment 9104890 [details]
Bug 1322864, r?NeilDeakin

Low risk, verified by QA on nightly, uplift approved for 71 beta 8, thanks.

Comment 43

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/788387ae855ea79a785632ae7506653f332a0f39

Comment 44

[ovidiu boca[:Ovidiu]]

I verified this issue on Windows 10 x64 with FF Beta 71.0b8 and I can confirm the fix.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

Does this need an ESR68 approval request? It grafts cleanly as-landed.

Comment 46

[:Gijs (he/him)]

Comment on attachment 9104890 [details]
Bug 1322864, r?NeilDeakin

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-moderate, straightforward patch
• User impact if declined: sec-moderate security issue
• Fix Landed on Version: 72 uplifted to 71
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a pretty small patch. Effectively, there were 2 callsites for 1 utility function, and we moved an extant security check from one of those 2 callsites into the utility function, so it now applies to both copy and drag/drop support.
• String or UUID changes made by this patch: nope

Comment 47

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9104890 [details]
Bug 1322864, r?NeilDeakin

Moves a security check so it applies to both callers. Approved for 68.3esr.

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/30006ca3a1e1

Comment 49

[Tom Ritter [:tjr]]

Attachment: advisory.txt