1189814 - (CVE-2015-4519) Dragging and dropping image to <textbox> pastes final URL of image after redirects

Status: RESOLVED FIXED

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

Description

[Gervase Markham [:gerv]]

https://fetch.spec.whatwg.org/#atomic-http-redirect-handling says:

"Throughout the platform, redirects (a response whose status is one of 301, 302, 303, 307, and 308) are not exposed to APIs. Exposing redirects might leak information not otherwise available through a cross-site scripting attack."

However, if you have:

<img src="http://foo.com/">

and that URL redirects to "http://bar.com?secret=12345", and then that loads the image, and then if you drag-drop the image to a textbox, the final URL is dropped (and therefore then available to script) rather than the initial URL.

This has been combined with cookie bombing to make a POC to steal Bugzilla secure attachments - see bug 1179241. I talked with Anne VK and he said that whatever we do about cookie bombing, this is also a bug.

Gerv

Comment 1

[Daniel Veditz [:dveditz]]

Not sure if netfuzzer was the first to notice and abuse this (did .mario (H.) also use this?), but worth considering for a separate bounty. Or we might consider it a necessary element of the attack in bug 1179241 and therefore part of a combined bounty for that exploit. Either way, flagging for a bounty so we don't forget about it later.

Comment 2

[Neil Deakin]

This looks to have been done intentionally via bug 1013211.

Maybe Mats can offer some feedback.

Comment 3

[Mats Palmgren (inactive)]

I don't have any info other than what is in the comments on that bug.
Note bug 1013211 comment 12 though about the MIME type being from the final
destination (PNG) rather than what the linked content is (text/html), so
there's some internal confusion to sort out there if you want to backout.
At the time, I saw it a security issue that the user would end up with
a HTML file locally when he thought he was saving an image.

Backing out will likely break saving Deviantart images as desktop wallpaper
again (unless the site has changed since then).

Comment 4

[Gervase Markham [:gerv]]

Anne: thoughts on comment 3? Is there a way to avoid the security problem but keep the DeviantArt-style usecase working?

Gerv

Comment 5

[Anne (:annevk)]

It sounds like we should reveal a different URL to privileged code (e.g., the OS) than to the page. I'm not super familiar with the details of drag-and-drop unfortunately.

Comment 6

[Daniel Veditz [:dveditz]]

So when we drop an image on the desktop we're really just dropping a URL and the OS has to fetch it again? What if it can't (no cookies or whatever)? We've already downloaded the image, why aren't we dropping a locally saved file on the desktop?

If we're dropping a file on the desktop then the URL shouldn't matter, and we can remember the original URL.

Comment 7

[Neil Deakin]

It works differently on each platform. On Mac, the OS supplies us with the destination folder when a drop occurs, and we use nsIWebBrowserPersist to save the uri there. On Windows, I believe the actual image is used.

But this bug is about dropping on a textbox, which will drop the image URL (as textboxes don't accept images). Prior to bug 1013211, this used imgIRequest::URI (non-redirected uri) but now it uses imgIRequest::currentURI.

Comment 8

[Mario Gomes]

Keep in mind that it isn't necessary to drop the content into a textbox, it can obtained also by using "ondragstart" + "event.dataTransfer.getData". 

Try this:
data:text/html,<img style="height:500px;width:300px;" src="http://foo.com" ondragstart="alert(event.dataTransfer.getData('text/plain'));"></img>

Comment 9

[Anne (:annevk)]

Thank you Mario. Replace "http://foo.com" with "http://google.com" to see why this is a problem. You get "http://www.google.com/?..." back which currently there is no way to get to.

Neil, we can leak ::URI to the textbox and dataTransfer. We can leak currentURI to the OS and non-web content. Would that still break sites?

Comment 10

[Mats Palmgren (inactive)]

Attachment: fix (backout the DND part from bug 1013211)

This simply backs out the changes to dom/base/nsContentAreaDragDrop.cpp
from bug 1013211.  It should restore the previous behavior for DND.
The other parts of 1013211 needs to stay because there are other
code that uses the added methods now.

Builds for testing:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-11ac37c2d524

I briefly tested the STR in bug 1013211 in a local Windows debug build
with this patch and I couldn't reproduce it.  I'll do some more testing
later with the Opt builds.  AFAICT, the site is still using a 301 redirect
to a HTML page so it appears nothing have changed on the site.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=11ac37c2d524

Comment 11

[Mats Palmgren (inactive)]

Attachment: mochitest (DO NOT LAND UNTIL BUG IS PUBLIC)

Comment 12

[Neil Deakin]

Comment on attachment 8650427 [details] [diff] [review]
fix (backout the DND part from bug 1013211)

You may want to add a synthesizeMouse for the mouseup event to the test.

Comment 13

[Mats Palmgren (inactive)]

Attachment: mochitest (DO NOT LAND UNTIL BUG IS PUBLIC)

OK, thanks.

Comment 14

[Mats Palmgren (inactive)]

I've tested the win32 Opt Try build on Windows 7 and it seems to work just fine.
I wasn't able to reproduce the original problem in bug 1013211 while saving 10 images.
I don't recall what my failure rate was at the time, but bug 1013211 comment 8
mentions "50/50".  So with some luck the original problem is just gone.

Comment 15

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f19d55717b0a

Comment 16

[Mats Palmgren (inactive)]

Comment on attachment 8650427 [details] [diff] [review]
fix (backout the DND part from bug 1013211)

Approval Request Comment
[Feature/regressing bug #]:1013211
[User impact if declined]:reveals redirect URL when drag-n-drop images
[Describe test coverage new/current, TreeHerder]:passed tests on Try, the attached testcase works locally
[Risks and why]: very low risk as it backsout the change in the DnD code, returning to previous behavior.  The risk is that bug 1013211 returns (saving images from deviantart.com) but it appears to work in my testing [a trunk build]. (Would be good if QA can verify that in Aurora/Beta builds too.)
[String/UUID change made/needed]:none

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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

Sounds like this should probably have esr38/b2g37 approval requests as well?

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8650427 [details] [diff] [review]
fix (backout the DND part from bug 1013211)

Fix a moderate sec issue. Taking it.

Comment 19

[Mats Palmgren (inactive)]

Comment on attachment 8650427 [details] [diff] [review]
fix (backout the DND part from bug 1013211)

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: reveals redirect URL when dragging images
Fix Landed on Version: trunk/aurora/beta
Risk to taking this patch (and alternatives if risky): very low risk as it backsout the change in the DnD code, returning to previous behavior.  The risk is that bug 1013211 returns (saving images from deviantart.com) but it appears to work in my testing [a trunk build]. (Would be good if QA can verify that in ESR builds too.)
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/9d5c76e1a730

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f707a90dd831

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8650427 [details] [diff] [review]
fix (backout the DND part from bug 1013211)

OK, let's take this for ESR38.

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Kamil or Florin, can one of you have a look to verify this fix? Thanks!

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/270a1de2f863

Comment 25

[Andrei Vaida [:avaida]]

I tried to reproduce the bug on an affected build (e.g. 40.0.3) using the steps from Bug 1013211, Comment 9, with no success. Is there anyone else that might be able to verify the fix on esr38 [1] and 41.0b8 [2]? I'd really appreciate it.


[1] https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-esr38-*
[2] https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/41.0b8-candidates/build1/

Comment 26

[Kamil Jozwiak [:kjozwiak]]

Mats, going through the example via comment # 8 sufficient enough for verification? Example:

* using a m-c build (20150820030202)
** output -> https://www.google.ca/?gfe_rd=cr&ei=Wh7zVdi0EpLd8geX15zoDA&gws_rd=ssl

* using the latest m-c build:
** output -> http://google.com/

Maybe going through bug # 1013211 and making sure that it's correctly working as well?

Comment 27

[Mats Palmgren (inactive)]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #26)
> Mats, going through the example via comment # 8 sufficient enough for
> verification? Example:

Yes, I believe this is the expected before/after results.

> Maybe going through bug # 1013211 and making sure that it's correctly
> working as well?

Yes, please.  File a new bug if you see a problem there.  Thanks!

Comment 28

[Kamil Jozwiak [:kjozwiak]]

Reproduced the issue using the following build:
- https://archive.mozilla.org/pub/firefox/nightly/2015-08-20-03-02-02-mozilla-central/

Went through verification using the following builds:
- https://archive.mozilla.org/pub/firefox/nightly/2015-09-14-03-02-05-mozilla-central/
- https://archive.mozilla.org/pub/firefox/nightly/2015-09-14-00-40-20-mozilla-aurora/
- https://archive.mozilla.org/pub/firefox/candidates/41.0b9-candidates/build1/
- https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-esr38-macosx64/1442054391/
- https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-esr38-linux64/1442054391/
- https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-esr38-win32/1442054391/

Test Cases: (using the poc mentioned in comment # 8)

- ensured that the alert didn't include the entire link when dragging the img from the poc
- ensured that dropping the img from the poc into textboxes didn't dump the entire link

* OSX 10.10.5 x64 -> PASSED 
** fx43 -> PASS
** fx42 -> PASS
** fx41 -> PASS
** fxESR38 -> PASS

* Ubuntu 14.04.3 x64 VM -> PASSED
** fx43 -> PASS
** fx42 -> PASS
** fx41 -> PASS
** fxESR38 -> PASS

Windows 10 x64 (VM) -> PASSED
** fx43 -> PASS
** fx42 -> PASS
** fx41 -> PASS
** fxESR38 -> PASS

Relating to Bug # 1013211, I couldn't reproduce the original issue using the steps outlined in bug # 1013211 comment # 9. However, I did go through each of the above OS's/channels and tried downloading the image about 100 different times into different directories and couldn't reproduce the original problem.