- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 Apr 2014 18:13:04 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25345 --- 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 getSecureRandomUint. 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