Closed Bug 655987 (CVE-2011-2366) Opened 13 years ago Closed 13 years ago

Respond to the WebGL cross-domain image theft vulnerability

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox5 + fixed
firefox6 + fixed
firefox7 + fixed
blocking2.0 --- -
status2.0 --- wanted
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: bjacob, Unassigned)

References

(
URL
)

Details

(Whiteboard: [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6][testday-20110826]) 

Proof-of-concept:

http://www.contextis.co.uk/resources/blog/webgl/poc/index.html

The proof-of-concept consists in loading a cross-domain image as a WebGL texture, and rendering each pixel using a shader program that takes an amount of time proportional to the R, G, B values of pixels. By timing this, they get an approximation of the image.

The attacker has to make a compromise between image quality and time. The higher the wanted quality, the longer it takes to steal.

The biggest hurdle that an attacker faces is that it's usually hard to know the URLs of sensitive images to steal. If the attacker knows URLs to steal and is able to get users to run WebGL scripts, if some users will stay long enough on his page (between 1 and 30 minutes needed depending on image size/quality), he can steal their images with that technique.
The main proposed response to this is to block loading cross-domain images without CORS approval as WebGL textures. We also need to add a check for IsWriteOnly when loading canvases as WebGL textures, otherwise people could just use a canvas as proxy to load cross-domain images.

Other possible responses include:
 * do nothing (if you think that there is no serious security problem here --- but I think that the proof-of-concept is serious enough).
 * enforce constant-time-per-texel in WebGL shaders that use cross-domain textures (no loops, etc). (Would require serious ANGLE changes to happen first --- outside of our control. Google does not even consider the issue to be serious at the moment, so it doesn't seem that they're rushing to do these ANGLE changes).

I think we should implement the no-cross-domain-textures-without-CORS idea for now, if we want anything to happen soon.
(In reply to comment #1)
> I think we should implement the no-cross-domain-textures-without-CORS idea
> for now, if we want anything to happen soon.

I agree.
Original blog post is public http://www.contextis.com/resources/blog/webgl/
Is there any point in keeping this bug hidden?

I'm dubious this is generically sg:high but it certainly would be for any site that has confidential information embedded in images. I wonder if some of those bank sign-ons that use a personalized image for security use predictable image locations? If so this could be used to defeat that protection against phishing.
blocking2.0: --- → -
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
status2.0: --- → wanted
status-firefox5: --- → affected
tracking-firefox5: --- → ?
tracking-firefox6: --- → ?
Whiteboard: [sg:high]
(In reply to comment #3)
> Original blog post is public http://www.contextis.com/resources/blog/webgl/
> Is there any point in keeping this bug hidden?

Given that it was hidden, I mentioned in comment 1 Google'sposition on this matter, which they stated on the _private_ WebGL list.
Was "Google's position" informed by input from their security team? CC'ing Chris Evans to see if they really think this is no big deal and potentially coordinate an approach to a fix.
Whiteboard: [sg:high] → [sg:high] (moderate in practice?)
(In reply to comment #5)
> Was "Google's position" informed by input from their security team? CC'ing
> Chris Evans to see if they really think this is no big deal and potentially
> coordinate an approach to a fix.

To be clear, it was just expressed by two engineers, not security team AFAIK. The two Google engineers who replied in this thread didn't think that this security issue was worth limiting what content can do with cross-domain images.
Blocks: 655367
I believe the opinion that it's not a matter of concern might actually come from Khronos group? Not 100% sure.
I haven't looked into it myself. I'm more concerned about the disappointingly nebulous claims of "arbitrary code execution" -- I'm try to track down any concrete bugs.
(In reply to comment #7)
> I believe the opinion that it's not a matter of concern might actually come
> from Khronos group? Not 100% sure.

The WebGL team at Google said that at this point they were against the idea of  limiting cross-domain textures. I hope to discuss that with them during tomorrow's WebGL phone call.

> I haven't looked into it myself. I'm more concerned about the
> disappointingly nebulous claims of "arbitrary code execution" -- I'm try to
> track down any concrete bugs.

I'm not concerned about that because they don't have any actual exploit to back their claims there; and their claims about "kernel mode" are meaningless since WebGL shaders have almost nothing to do with the kernel mode part of graphics drivers. When there's a vulnerability in a driver that can be exploited by a crafted shader, that's either a vulnerability in the shader compiler, which is just like any DLL, or that's a vulnerability about accessing illegal video memory (more rare case, only seen on Mac OS 10.5); either way, we respond by blacklisting the OS/driver in question, and we're safe.
We've also seen some system-wide DOS vulnerabilities on Mac, where a crafted shader can freeze the whole graphics system, but have no data at this point about what's happening there. In any case it's just a DOS.
Yeah, I talked to Apple a bit about their DOS issue. Since they own the OS code, and tend to favour a single GPU vendor, they're in good shape to fix themselves up. Since development versions of Safari have WebGL, maybe they already did that.

I reached out to US-CERT to explain the way the blacklisting operates; Chrome does the same thing.

Thanks for driving the texture issue forward.
(In reply to comment #8)
> (In reply to comment #7)
> > I believe the opinion that it's not a matter of concern might actually come
> > from Khronos group? Not 100% sure.
> 
> The WebGL team at Google said that at this point they were against the idea
> of  limiting cross-domain textures. 

Limiting textures to same-origin in the absence of CORS seems like a no-brainer to me if any kind of program (including shaders) can read the texture data. (I'm shocked that such a limit wasn't in place already.)

I think it would make sense to support CORS for relaxing the same-origin restriction eventually, but adding CORS support seems like too big a thing to put into a chemspill if this issue gets that status.

I can see why without CORS but with same-origin restriction doing stuff like serving textures from a CDN would be annoying, though.
Depends on: 656277
Johnath, suggested that Brandon and Sid might be interested in knowing that fixing this will require us to send the Origin header for images.
(In reply to comment #12)
> Johnath, suggested that Brandon and Sid might be interested in knowing that
> fixing this will require us to send the Origin header for images.

Indeed, they may be utterly uninterested, but I do know that they have gone a couple rounds on origin headers in general; wouldn't want them to miss all the fun.
There is no chance of getting a CORS solution into Firefox 5. The question now is whether this bug is worth an interim fix that simply blocks cross-origin images (or tainted canvases) used in WebGL. That would make Fx4 permissive, Fx5 restrictive, and Fx6 CORS.

For now marking tracking-firefox5, but if we don't want Fx5 different and then Fx6 different again maybe we don't want that interim solution.
tracking-firefox5: ? → +
tracking-firefox6: ? → +
You make this call.

During today's WebGL conference call, I said that while I hoped that we would have time to implement the CORS relaxation before we have to ship the fix (disallowing cross-domain textures), I couldn't make any promises as our security team could decide at any time that we need to ship the fix. Google said they understood what I was saying, and were in the same situation.

So really, security team --- it's your call. Meanwhile I'll just write the patch (tomorrow at the latest) for simply blocking cross-domain textures and tainted canvases, so we can ship it if/when you think we should.
I don't see that this bug is actually a huge short-term deal. I've found a ton of cross-origin image theft bugs that work in near-zero time, with perfect image fidelity. And those were never a big deal, as sensitive cookie authenticated images are not a large part of the web -- and of the tiny number that are, many are served at unpredictable URLs.

Contrast the severity of those earlier bugs with this new bug where the theft takes ages and is unreliable and it's pretty clear we're looking at a low severity issue?
(In reply to comment #16)
> I don't see that this bug is actually a huge short-term deal. I've found a
> ton of cross-origin image theft bugs that work in near-zero time, with
> perfect image fidelity.

Hmm, that makes me curious. Can you point to bugzilla.mozilla.org bugs?

> And those were never a big deal, as sensitive cookie
> authenticated images are not a large part of the web -- and of the tiny
> number that are, many are served at unpredictable URLs.

There are also potentially issues with images on intranets at guessable URLs.

It certainly would be convenient if the security community reached a consensus that cross-origin image data should not be considered sensitive. I don't know how you'd make such a decision though.
I think I forgot to update this bug, but during today's WebGL call, Google's WebGL team said they now consider this to be a 'very severe' issue. They said it was the example of a scanned copy of a cheque on one's bank's website that made them change their minds. They are now pushing for the same solution as we do, i.e. disallow cross-domain textures without CORS. 

People with a Khronos account can check the minutes:
https://cvs.khronos.org/wiki/index.php/3D_Web/12May2011Minutes
Which bank hosts scanned check images at predictable locations?
(In reply to comment #19)
> Which bank hosts scanned check images at predictable locations?

I don't know about the 'predictable locations' part, and indeed that is the key to exploitability here.

However, it makes me uncomfortable that security depends on the predictability of image URLs.
I just clicked 'View Cheque' on a check in my account at TD Canada, a major Canadian bank.

Resulting URL:
https://easywebsoc.tdcanadatrust.com/servlet/ca.tdbank.banking.servlet.ChequeFrontImageLoadingServlet?MagicNum=13052494*****

(where the last 5 stars were 5 decimal digits --- I'm obfuscating them here)

The 'MagicNum' here seems to be just the current Unix epoch time in milliseconds. The server seems to refuse to let me download it a second time, but that may be just because my bank charges for he 'View Cheque' service.

I concede that this doesn't look very easy to exploit but I'm no security expert.
Opera just said they agreed with the proposed solution (block cross-domain textures without CORS).
Should the summary of this bug be changed to "block cross-domain textures without CORS" ?  Also, who is going to own this?
I'm sorry. I see that is (presumably) what bug 656277 is doing.
Whiteboard: [sg:high] (moderate in practice?) → [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6]
Whiteboard: [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6] → [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6][blocks-fx5b5]
Depends on: 662599
Bug 656277, blocking cross-domain textures, landed, including on beta (Firefox 5). So the security issue is gone. Closing this security bug.

What remains to do now is the CORS relaxation: bug 662599. This will ease getting affect web pages working again.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6][blocks-fx5b5] → [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6]
Marking as fixed 5/6 since it landed for aurora and beta.  Would like to track for FF7 since we'd like to soften this in 662599 to match other vendors.
status-firefox5: affected → fixed
status-firefox6: --- → fixed
tracking-firefox7: --- → ?
Alias: CVE-2011-2366
Group: core-security
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0

Is there any way how i could test that this issue was fixed?
I followed the url in this bug and if i click on the buttons steal me, below each image, and i can see the images.
Is that the intended behaviour or should that test fail?
Thanks.
The proof-of-concept, 
  http://www.contextis.co.uk/resources/blog/webgl/poc/index.html
defaults to a same-domain image. That's why "stealing" works. If you load a cross-domain image, it shouldn't work anymore.
Verified using Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 beta 2.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6] → [sg:high] (moderate in practice?) [656277 has a fix potentially for 5 and 6][testday-20110826]
You need to log in before you can comment on or make changes to this bug.