Redirects permit cross-domain and local-system image disclosure via CANVAS

VERIFIED FIXED

Status

()

Firefox
Security
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: Michal Zalewski, Assigned: Joe Drew (not getting mail))

Tracking

({verified1.8.1.18})

2.0 Branch
verified1.8.1.18
Points:
---
Bug Flags:
wanted1.9.0.x -
blocking1.8.1.18 +
wanted1.8.1.x +
blocking1.8.0.next -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:high] fixed by 355126, URL)

(Reporter)

Description

9 years ago
Hi,

Chris Evans (Cc:ed) found out that the security restrictions applied to CANVAS toDataURL() and getImageData() methods once drawImage() is called on a given CANVAS to render a non-same-origin image, may be trivially bypassed if image source is initially specified in SRC attribute to be same-origin, but then HTTP 30x redirected to a non-same-origin resource.

This permits theft of potentially sensitive data across domains, should the victim be logged into any services that either store private images, or provide any sensitive visualisations at predictable locations.

Just as amusingly, I noticed that this may be exploited to very accurately enumerate locally installed software - and effectively, fingerprint the computer - by abusing moz-icon: as a redirection target:

http://lcamtuf.coredump.cx/ico_sniff2.html (works in FF2 on Windows)

According to Chris, this does not affect FF3.

Updated

9 years ago
Summary: insufficient checking permits cross-domain image disclosure via CANVAS → Redirects permit cross-domain image disclosure via CANVAS

Comment 1

9 years ago
Duplicate of bug 355126?
(Reporter)

Comment 2

9 years ago
Looks like, except for novelty the moz-icon: vector.

Come on, open since 2006? With where the web is these days, this actually permits quite a few privacy-related attacks in popular services.

Comment 3

9 years ago
Yeah, that is pretty sad.  Do you have any juicy attack scenarios that might motivate us to fix it faster? :)
(Reporter)

Comment 4

9 years ago
Well, moz-icon: for starters, as shown above ;-) This is something that many users probably do not want to happen (the obvious information leak aside, I'm willing to bet that by fingerprinting enough programs installed and their versions, as derived from icon appearance, lets you uniquely identify most machines, too).

The other part is not conceptually different from cross-domain HTML disclosure. Until not long ago, most HTML used to be static and publicly accessible, but this has changed quickly. The same is happening with many images. I'm not gonna paste any specific URLs ;-), but several examples of graphs that might be worth stealing, assuming you're logged into any of these services:

- Your stock portfolio performance at yourbroker.com,
- Your account forecasts on yourbank.com,
- Traffic statistics for your site on foo-traffic-analysis-corp.com
- Advertisement click-through or price charts on foo-ad-solutions.com

I have even seen user names and other personal information dynamically rendered in image views served by a particular service of ours, for the purpose of conveniently embedding somewhere.

Comment 5

9 years ago
Can I get access to bug 355126?

Jesse, you're the guy that sat behind me on the plane to BlackHat right? Nice to bump into you again :)

I can promise to disclose on Tue Sep 16th if you're after motivation to fix it faster :D :D

Comment 6

9 years ago
Hi again, Chris :)  Sorry for not CCing on bug 355126 earlier.

Comment 7

9 years ago
There's a chance I'll be speaking about browser cross-domain security in Japan on Nov 12; I'd recommend fixing it by then, unless there are no plans to ever fix this in the v2 release stream.
preserving as a separate bug because it's got an interesting testcase, but it should be the same fix as bug 355126
Depends on: 355126
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.18?
Summary: Redirects permit cross-domain image disclosure via CANVAS → Redirects permit cross-domain and local-system image disclosure via CANVAS
Whiteboard: [sg:high]
Flags: blocking1.8.1.18? → blocking1.8.1.18+
Assignee: nobody → joe
Whiteboard: [sg:high] → [sg:high] fixed by 355126
Flags: wanted1.9.0.x-
(Assignee)

Updated

9 years ago
Keywords: fixed1.8.1.18
This is fixed in 2.0.0.18. Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/2008102918 Firefox/2.0.0.18 after seeing the bug in 2.0.0.17.

Since it hasn't been resolved fixed, I'm doing that as well. :-)
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.8.1.18 → verified1.8.1.18
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Group: core-security

Updated

8 years ago
Flags: blocking1.8.0.next-
You need to log in before you can comment on or make changes to this bug.