stealing pictures using canvas toDataURL

RESOLVED FIXED

Status

()

RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: guninski, Assigned: dveditz)

Tracking

({fixed1.8.1})

Trunk
x86
Linux
fixed1.8.1
Points:
---
Bug Flags:
blocking1.8.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate] post ff1.5)

Attachments

(2 attachments)

stealing pictures

using two canvases, fillRect, drawImage and toDataURL it is possible to get
the content of arbitrary accessible images.

testcase to follow.
Created attachment 240004 [details]
stealing pictures
(Reporter)

Updated

12 years ago
Component: Security → Security
Product: Firefox → Core
(Reporter)

Updated

12 years ago
Component: Security → Layout: Canvas
(Assignee)

Comment 2

12 years ago
I guess if there were a sensitive image inside a firewall the user could see but the attacker couldn't reach directly (but somehow guessed the name of--disgruntled insider?) then this could be used to steal those insider images. Wouldn't the real fix be to block "public" pages from including content from "private" URLs?

But you could also use the :visited trick (bug 147777) to see if the victim might be logged on somewhere interesting (or just guess) and steal images that might be plots of sensitive data. Textual data is protected by the same-origin policy (can't reach into a frame with that data, can't use XMLHttpRequest to get it), images have up to now been opaque blobs.

The what-wg spec apparently considered this case, saying in 6.1:
  "Security: To prevent information leakage, the toDataURL() and
  getImageData() methods should raise a security exception if the
  canvas ever had images painted on it that originate from a domain
  other than the domain of the script that painted the images onto
  the canvas."

It looks like canvas attempts to do this. data URLs can't be gotten off the first canvas, only after drawImage() is used to create the second canvas. The problem appears to be that CairoSurfaceFromElement() returns a null URI from a canvas element (makes sense) but then DoDrawImageSecurityCheck() requires that auri not be null to do anything. I think we just switch the order of checks there to fix this.
Assignee: nobody → dveditz
Flags: blocking1.8.1.1?
Summary: stealing pictures → stealing pictures using canvas toDataURL
Whiteboard: [sg:moderate]
(Assignee)

Comment 3

12 years ago
Created attachment 240035 [details] [diff] [review]
Reverse order in DoDrawImageSecurityCheck

With this patch the testcase throws a security exception
Attachment #240035 - Flags: superreview?(pavlov)
Attachment #240035 - Flags: review?(vladimir)
(Assignee)

Comment 4

12 years ago
Probably too late for FF2 initial, but worth trying since this is a new feature and may get scrutiny out of the gate.
Flags: blocking1.8.1?
Whiteboard: [sg:moderate] → [sg:moderate] post ff1.5
Comment on attachment 240035 [details] [diff] [review]
Reverse order in DoDrawImageSecurityCheck

r+sr=me
Attachment #240035 - Flags: superreview?(pavlov)
Attachment #240035 - Flags: superreview+
Attachment #240035 - Flags: review?(vladimir)
Attachment #240035 - Flags: review+

Comment 6

12 years ago
Safe enough for RC2?  If so nom the patch..

Updated

12 years ago
Flags: blocking1.8.1? → blocking1.8.1+

Comment 7

12 years ago
Comment on attachment 240035 [details] [diff] [review]
Reverse order in DoDrawImageSecurityCheck

Approved for RC2.  Please land and mark Fixed1.8.1
Attachment #240035 - Flags: approval1.8.1+
(Assignee)

Comment 8

12 years ago
Fix checked into trunk and 1.8 branch
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: blocking1.8.1.1?
Keywords: fixed1.8.1
Resolution: --- → FIXED
seems fixed on trunk without known regression.
(Assignee)

Updated

12 years ago
Group: security
You need to log in before you can comment on or make changes to this bug.