RESOLVED FIXED54167
REGRESSION(r78149): Return value of read() shouldn't be ignored.
https://bugs.webkit.org/show_bug.cgi?id=54167
Summary REGRESSION(r78149): Return value of read() shouldn't be ignored.
Jarred Nicholls
Reported 2011-02-09 22:12:28 PST
Build break for gcc 4.4.5.
Attachments
Proposed patch (1.34 KB, patch)
2011-02-09 22:15 PST, Jarred Nicholls
no flags
Proposed patch (1.23 KB, patch)
2011-02-10 00:50 PST, Jarred Nicholls
no flags
Jarred Nicholls
Comment 1 2011-02-09 22:15:46 PST
Created attachment 81924 [details] Proposed patch use return value of read in both debug and release modes.
Alexey Proskuryakov
Comment 2 2011-02-10 00:45:52 PST
Comment on attachment 81924 [details] Proposed patch Why not just use the CRASH() version in both debug and release? A quick web search suggests that reads from /dev/urandom never fails in practice, just possibly degrading quality (not sure if there's a proper spec for this). I'm wondering if one Web page will be able to predict random numbers generated in other pages by exhausting OS randomness first.
Jarred Nicholls
Comment 3 2011-02-10 00:48:58 PST
(In reply to comment #2) > (From update of attachment 81924 [details]) > Why not just use the CRASH() version in both debug and release? > Yeah I suppose I could. I don't ever predict /dev/urandom to fail to provide the exact number of requested bytes. I'll revise. > A quick web search suggests that reads from /dev/urandom never fails in practice, just possibly degrading quality (not sure if there's a proper spec for this). I'm wondering if one Web page will be able to predict random numbers generated in other pages by exhausting OS randomness first. Good thought. May want to hit up the Chromium team who added this :)
Jarred Nicholls
Comment 4 2011-02-10 00:50:53 PST
Created attachment 81934 [details] Proposed patch
WebKit Commit Bot
Comment 5 2011-02-10 04:46:38 PST
Comment on attachment 81934 [details] Proposed patch Clearing flags on attachment: 81934 Committed r78203: <http://trac.webkit.org/changeset/78203>
WebKit Commit Bot
Comment 6 2011-02-10 04:46:47 PST
All reviewed patches have been landed. Closing bug.
Csaba Osztrogonác
Comment 7 2011-02-10 05:05:42 PST
*** Bug 54190 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 8 2011-02-10 10:48:42 PST
Adam, I'm still curious about your thoughts on the issue of Web content abusing randomness source, and thus affecting other pages (and even other processes?!). Is there a rate limit or some other protection against that?
Adam Barth
Comment 9 2011-02-10 13:09:09 PST
(In reply to comment #8) > Adam, I'm still curious about your thoughts on the issue of Web content abusing randomness source, and thus affecting other pages (and even other processes?!). Is there a rate limit or some other protection against that? Access to OS randomness is mediated by a cryptographic PRNG in WTF. There shouldn't be a problem with sharing the crypto PRNG with other web pages. If there was, that would be an attack on RC4, and we'd have bigger problems! Now, there's the question of whether it's dangerous to let web pages pull from OS randomness, even mediated by a PRNG. I don't think that's overly dangerous. In many common scenarios, web pages can already pull from OS randomness. For example, the <keygen> element lets you generate certificates, which requires a bunch of OS randomness. As another example, WTF::randomNumber backends to arc4random on Mac, which backends to /dev/urandom. To the extent that web pages can cause WebKit to call WTF::randomNumber, they can already convince us to extract randomness from the OS.
Alexey Proskuryakov
Comment 10 2011-02-11 10:41:42 PST
> Now, there's the question of whether it's dangerous to let web pages pull from OS randomness, even mediated by a PRNG. Yes, that's my concern. Perhaps this hasn't been exploited yet, but it seems likely to be exploitable.
Note You need to log in before you can comment on or make changes to this bug.