[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)
----- Original Message -----
> 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?
Those are exactly the use cases that CORS was created for -- all it would take is for Flickr and the ad network to send the right http headers to explicitly indicate that their resources can be used from a foreign domain.
> 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.
It's not an issue of "degree of badness"; any security issues that we know about, especially if we can reproduce, we have to do something about. The issues that Stephen brought up are certainly dangerous issues, but they are either things that we are explicitly dealing with (breaking out of shader sandbox, sniffing data from other GL contexts), or things that we can't really do anything about (spoofing). If any bugs were found that would allow code to break out of the sandbox, they would be treated as security bugs and fixed.
> -----Original Message-----
> From: ext firstname.lastname@example.org [mailto:email@example.com]
> 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
> 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
> you could make the texture memory cache have to reload a number of
> proportional to the brightness of the texel and get timing variation
> way...at least well enough to read text.
> So I agree that we can't stop all possible exploits - but we can make
> 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
> 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.
> -- Steve
> > 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,
> > Tomi
> > From: firstname.lastname@example.org
> > [mailto:email@example.com] 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
> > method.
> > 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.
> > -Brian
> > On Oct 5, 2010 8:28 PM, "Steve Baker"
> > <firstname.lastname@example.org<mailto:email@example.com>> 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 ;
> >> else
> >> 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
> >> shader:
> >> 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 firstname.lastname@example.org.
> To unsubscribe, send an email to email@example.com with
> the following command in the body of your email:
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: