Closed Bug 1322864 Opened 7 years ago Closed 4 years ago

SOP bypass using drag and drop of image.

Categories

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

52 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla72
Tracking Status
firefox-esr68 --- fixed
firefox70 --- wontfix
firefox71 --- verified
firefox72 --- verified

People

(Reporter: qab, Assigned: Gijs)

Details

(Keywords: sec-moderate, Whiteboard: [post-critsmash-triage][adv-main71+])

Attachments

(6 files)

Attached file 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.
Works on latest nightly, not latest stable.
Ran moz regression.  Build '2015-04-10' is first bad (where PoC works) occurrence, couldn't dig deeper, mozreggresion kept crashing.
Does not work on nightly if multi-process is disabled.
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.
Summary: SOP bypass using drag and drop of invalid image. → SOP bypass using drag and drop of image.
Given that this is e10s-specific, I suspect this is basically the same problem as bug 1317023.
Depends on: 1317023
(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.
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
Group: firefox-core-security → core-security
Component: Untriaged → Drag and Drop
No longer depends on: 1317023
Product: Firefox → Core
Group: core-security → dom-core-security
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?
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.
(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?
Flags: needinfo?(bzhao)
(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?
Flags: needinfo?(qab)
Attached file 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.
Flags: needinfo?(qab)
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.
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
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.
(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).
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
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.
Was looking at the crash in comment #8, looks like its a UaF? Should that be a separate bug report, or?
(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.
Flags: needinfo?(bzhao)
Flags: sec-bounty?
Is there anyone who is willing to take this bug? I have no clue who is better at DnD mechanics.
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.
(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.
Andrew, do you know who could own this?
Flags: needinfo?(continuation)
Neil, is this something you could work on? Thanks.
Flags: needinfo?(continuation) → needinfo?(enndeakin)
(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
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.
Flags: needinfo?(enndeakin)
Flags: sec-bounty? → sec-bounty+
Attached file 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.

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

Flags: needinfo?(qab)
Attached video 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)

Flags: needinfo?(qab) → needinfo?(gijskruitbosch+bugs)

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.

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.

Assignee: nobody → gijskruitbosch+bugs
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)
Group: dom-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

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.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: qe-verify+
Whiteboard: [post-critsmash-triage]

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
Flags: needinfo?(gijskruitbosch+bugs)
Attachment #9104890 - Flags: approval-mozilla-beta?
QA Whiteboard: [qa-triaged]

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 on attachment 9104890 [details]
Bug 1322864, r?NeilDeakin

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

Attachment #9104890 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+

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

Flags: needinfo?(gijskruitbosch+bugs)

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
Flags: needinfo?(gijskruitbosch+bugs)
Attachment #9104890 - Flags: approval-mozilla-esr68?

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

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

Attachment #9104890 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main71+]
Attached file advisory.txt
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.