SOP bypass using drag and drop of image.
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Tracking
()
People
(Reporter: qab, Assigned: Gijs)
Details
(Keywords: sec-moderate, Whiteboard: [post-critsmash-triage][adv-main71+])
Attachments
(6 files)
1.23 KB,
text/html
|
Details | |
266 bytes,
text/html
|
Details | |
1.26 KB,
text/html
|
Details | |
4.81 MB,
video/mp4
|
Details | |
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr68+
|
Details | Review |
313 bytes,
text/plain
|
Details |
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.
Reporter | ||
Comment 1•7 years ago
|
||
Works on latest nightly, not latest stable.
Reporter | ||
Comment 2•7 years ago
|
||
Ran moz regression. Build '2015-04-10' is first bad (where PoC works) occurrence, couldn't dig deeper, mozreggresion kept crashing.
Reporter | ||
Comment 3•7 years ago
|
||
Does not work on nightly if multi-process is disabled.
Reporter | ||
Comment 4•7 years ago
|
||
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.
Reporter | ||
Updated•7 years ago
|
Assignee | ||
Comment 5•7 years ago
|
||
Given that this is e10s-specific, I suspect this is basically the same problem as bug 1317023.
Reporter | ||
Comment 6•7 years ago
|
||
(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.
Updated•7 years ago
|
Comment hidden (obsolete) |
Assignee | ||
Comment 8•7 years ago
|
||
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
Updated•7 years ago
|
Reporter | ||
Comment 9•7 years ago
|
||
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•7 years ago
|
||
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.
Assignee | ||
Comment 11•7 years ago
|
||
(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?
Assignee | ||
Comment 12•7 years ago
|
||
(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?
Reporter | ||
Comment 13•7 years ago
|
||
(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.
Reporter | ||
Comment 14•7 years ago
|
||
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.
Reporter | ||
Comment 15•7 years ago
|
||
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
Reporter | ||
Comment 16•7 years ago
|
||
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.
Assignee | ||
Comment 17•7 years ago
|
||
(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).
Reporter | ||
Comment 18•7 years ago
|
||
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
Reporter | ||
Comment 19•7 years ago
|
||
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.
Reporter | ||
Comment 20•7 years ago
|
||
Was looking at the crash in comment #8, looks like its a UaF? Should that be a separate bug report, or?
Comment 21•7 years ago
|
||
(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.
Updated•7 years ago
|
Reporter | ||
Comment 22•7 years ago
|
||
Is there anyone who is willing to take this bug? I have no clue who is better at DnD mechanics.
Reporter | ||
Comment 23•7 years ago
|
||
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.
Assignee | ||
Comment 24•7 years ago
|
||
(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.
Assignee | ||
Comment 25•7 years ago
|
||
Andrew, do you know who could own this?
Comment 26•7 years ago
|
||
Neil, is this something you could work on? Thanks.
Reporter | ||
Comment 27•7 years ago
|
||
(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•7 years ago
|
||
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 hidden (off-topic) |
Comment hidden (off-topic) |
Updated•7 years ago
|
Reporter | ||
Comment 31•5 years ago
|
||
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.
Assignee | ||
Comment 32•4 years ago
|
||
(In reply to Abdulrahman Alqabandi from comment #31)
Created attachment 9104483 [details]
thing.htmlUpdated 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?)
Reporter | ||
Comment 33•4 years ago
|
||
(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 isundefined
. 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)
Reporter | ||
Comment 34•4 years ago
|
||
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.
Assignee | ||
Comment 35•4 years ago
|
||
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 | ||
Comment 36•4 years ago
|
||
Assignee | ||
Comment 37•4 years ago
|
||
Comment 38•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 39•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 40•4 years ago
|
||
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
Updated•4 years ago
|
Comment 41•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
uplift |
Comment 44•4 years ago
•
|
||
I verified this issue on Windows 10 x64 with FF Beta 71.0b8 and I can confirm the fix.
Comment 45•4 years ago
|
||
Does this need an ESR68 approval request? It grafts cleanly as-landed.
Assignee | ||
Comment 46•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
uplift |
Updated•4 years ago
|
Comment 49•4 years ago
|
||
Updated•4 years ago
|
Description
•