[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)
I totally agree with Steve, this should be about finding the right balance. If we ban all non-origin-clean textures, doesn't that rule out some pretty obvious and compelling use cases, such as a slide show app for Flickr photos? Or in-game ads sourced from an ad provider's domain?
I wouldn't want WebGL to be crippled to eliminate just one attack vector when who-knows-how-many equally dangerous holes probably remain in the 2D canvas and other web specifications.
As for possible exploits on the 2D canvas, I would be very surprised if drawImage always took exactly the same amount of time regardless of the source and destination pixel values and the compositing mode. Consider a software implementation with optimized alpha-blending, or a GPU with smart early-out for fully transparent pixels.
To take another example, the 'lighter' compositing mode computes A+B and clamps the result to 255. If the implementation takes longer to execute the clamped path than the default path, then that implementation is vulnerable.
I would also like to put this threat into perspective. Is the ability to read out non-origin-clean pixels among the worst security issues with WebGL in the first place? Personally, I'm more concerned about the ideas that Stephen White brought up, i.e., a malicious script breaking out of the shader sandbox, or being able to sniff data from other GL contexts, or masquerading as a legitimate password dialog.
From: ext email@example.com [mailto:firstname.lastname@example.org]
Sent: 6. lokakuuta 2010 18:58
To: Aarnio Tomi (Nokia-NRC/Tampere)
Subject: RE: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)
Yep. If you were to disable vertex textures and disallow 'discard' and
force all shader loops to run to completion - I can still see a way to
make a timer exploit by using a dependent texture read (use the color of
the texture you are probing to determine the coordinate of a lookup into a
second, very large, texture). By doing this just right, I'm pretty sure
you could make the texture memory cache have to reload a number of times
proportional to the brightness of the texel and get timing variation that
way...at least well enough to read text.
So I agree that we can't stop all possible exploits - but we can make them
extraordinarily difficult. The trick here is to find the right balance
and not make WebGL useless in the name of stopping an exploit that can be
done in ways we obviously can't prevent.
I bet there are possible timing exploits like this in the canvas
compositor and perhaps even in the basic browser page layout stuff. I
don't have the time or the knowledge to find one - but I'd be surprised if
there weren't any.
> Hi Brian, Steve,
> I believe you could fish out the texel values with a timer-based attack
> even without vertex texture support: Just draw N screen-sized quads, where
> N is the number of texels in your secret texture, using a fragment shader
> that samples the same texel for every fragment and consumes time in
> proportion to the texel value (which Steve already showed how to do). If
> you have a very fast GPU and/or bad timers, just increase the size of the
> quad and/or draw it several times until you get measurable differences.
> As a newcomer to web development, I keep wondering if these restrictions
> on image data access are genuinely necessary. They are a giant pain in the
> bottom for the ordinary developer, yet there are ways for attackers to go
> around them, so why bother?
> Best regards,
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of ext Brian Cornell
> Sent: 6. lokakuuta 2010 9:14
> To: Steve Baker
> Cc: public webgl; Chris Marrin
> Subject: Re: [Public WebGL] Proposed change to WebGL spec section 4.2
> (Security Origin Restrictions)
> Back on topic though, your example hack doesn't change whether we have
> finer grained origin control or not, as that will work with the current
> Your hack would argue for even stricter rules (don't allow vertex textures
> and don't allow discard, or don't allow tainted textures to ever be used)
> or giving up on it since somebody will find a way around it anyway.
> On Oct 5, 2010 8:28 PM, "Steve Baker"
> <email@example.com<mailto:firstname.lastname@example.org>> wrote:
>> Brian Cornell wrote:
>>> If I understand the WebGL shader limitations correctly, you black hat
>>> solution would not work because loops that can't be statically
>>> unrolled are not allowed. So you could not use a loop based on the
>>> texel value.
>> If you did a pixel 'discard' inside an 'if' statement many modern cards
>> would do an early-out of the shader if all of the adjacent pixels
>> terminated early. No amount of legalese in the spec will prevent that
>> from happening if that's what the hardware actually does:
>> for ( i = 0 ; i < 256 ; i++ )
>> if ( i > texelBrightness*255 )
>> discard ;
>> read a random texel out of a huge map ;
>> But it doesn't matter...I just thought of something even easier. Even
>> if the vertex and pixel shaders take absolutely the same amount of time
>> no matter what - I can STILL just do this at the end if the vertex
>> gl_Position = vertexPosition.xy * texelBrightness ;
>> ...then I bind the texture to a vertex shader sampler and draw a large
>> quad in the center of the screen.
>> The size of the quad will be proportional to the square of the texel
>> brightness - and the number of pixels we'll draw will be roughly
>> proportional to the brightness - and with finite frame buffer memory
>> speeds that's got to impact the pixel processing time in a sufficiently
>> predictable way for this hack to work. For a useful exploit we might
>> only need to be able to read a 100x20 texel patch of white text on a
>> black background and we've stolen someone's credit card number. You'd
>> only need to distinguish black from white...a simple timing threshold
>> would suffice. Text is pretty readable even in the presence of
>> considerable noise - so random timing variations would be little
>> obstacle to the determined bad guy.
>> So there are plausible exploits even with readTexels and occlusion
>> culling completely disabled.
>> The trouble is that this is the kind of thing that 10 minutes of me
>> thinking about it can turn up. Bad guys trying to recover passwords or
>> credit card numbers will be thinking about this for months or even years
>> - there are an unbelievable number of tiny chinks in the armor that
>> could possibly be exploited.
>> -- Steve
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: