stealing pictures using canvas toDataURL

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: guninski, Assigned: dveditz)

Tracking

({fixed1.8.1})

Trunk
x86
Linux
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.
Product: Firefox → Core
Component: Security → Layout: Canvas
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]
With this patch the testcase throws a security exception
Attachment #240035 - Flags: superreview?(pavlov)
Attachment #240035 - Flags: review?(vladimir)
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+
Safe enough for RC2?  If so nom the patch..
Flags: blocking1.8.1? → blocking1.8.1+
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+
Fix checked into trunk and 1.8 branch
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: blocking1.8.1.1?
Keywords: fixed1.8.1
Resolution: --- → FIXED
seems fixed on trunk without known regression.
Group: security
You need to log in before you can comment on or make changes to this bug.