W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2014

[Bug 25345] Set window.crypto and all properties of window.crypto writable to false

From: <bugzilla@jessica.w3.org>
Date: Tue, 15 Apr 2014 18:13:04 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25345-7213-Z1x1JrrT3l@http.www.w3.org/Bugs/Public/>

--- Comment #5 from Boris Zbarsky <bzbarsky@mit.edu> ---
Franz, thank you for the code link.

Protecting against incompetence (i.e. someone accidentally setting
crypto.getRandomValues to a crappy algorithm) is easier than protecting against
malice (someone deliberately messing with your execution environment to screw
you over).  Your proposal would do the former, but not the latter.

Looking at the linked code, here are some ways to attack it that work even if
crypto.getRandomValues cannot be tampered with:

1)  Redefine String.fromCharCode to ignore the passed-in value and instead
return whatever the attacker wants.  This allows the attacker to control the
return values of random.getRandomBytes().

2)  Redefine window.DataView to create objects that the attacker controls. 
This allows the attacker to control the return values of getSecureRandomUint()
and hence getSecureRandom() without affecting getRandomBytes.

3)  Redefine Math.pow or Math.abs.  This allows the attacker to control the
return values of getSecureRandom() without affecting getRandomBytes or

4)  Redefine Math.floor or Math.pow to control getRandomBigInteger.

I didn't look at any of the code outside random.js, but I'm fairly certain that
there are similar issues in that code too.

The only way to make this stuff safe is to either make sure any other injected
code runs in a caja-like sandbox or to explicitly freeze all the properties you
depend on, which include a lot more than just window.crypto and
window.crypto.getRandomValues.  So if we just made the latter unforgeable that
would mostly give people a false sense of security, as far as I can tell.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 15 April 2014 18:13:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:42 UTC