3 ms·

Based on the description here: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/20

by pwg 9y ago

Based on the description here: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi... These attacks are very practical. Unprivileged code, doing nothing inherently wrong (so very hard to detect), reading arbitrary memory locations contents at a rate of about 2000 bytes per second. Another blog somewhere (I no longer have the URL) indicated that the Google group that helped discover the issue also managed to read arbitrary, normally inaccessible, memory locations from Chrome by running JavaScript. Which makes the attack feasible remotely using nothing but a properly programmed malicious website.

MrBuddyCasino 9y ago
In all fairness, they disabled SharedArrayBuffer and diluted clock precision, so afaik the JS attack vector can be eliminated for patched browsers (FF did the same).
- kodablah 9y ago
  I don't think this is enough. I think this just mitigates the ability to use high precision to determine cache misses on array accesses. The leaked data is still there and the paper says it's one of 64 possibilities. Enabling site isolation helps since it's only process memory. Someone correct me if I misunderstand. EDIT: Also, just confirmed via https://jsfiddle.net/5n6poqjd/ https://jsfiddle.net/5n6poqjd/ that only FF has SharedArrayBuffer disabled. Chrome isn't going to release 64 which has SharedArrayBuffer disabled for a couple of weeks.
- bzbarsky 9y ago
  The SAB and clock changes are all to reduce timer precision. Reducing timer precision doesn't _fix_ the problem, but does reduce the rate of the data leak, which means it takes longer to exfiltrate the same information. Whether this is sufficiennt mitigation depends on your threat model and the exact amount of rate reduction. For example, a leak of 1 byte per hour might be OK in some threat models but not others.
  - MrBuddyCasino 9y ago
    Wasn‘t aware, thx!

by pwg 9y ago

MrBuddyCasino 9y ago

In all fairness, they disabled SharedArrayBuffer and diluted clock precision, so afaik the JS attack vector can be eliminated for patched browsers (FF did the same).

kodablah 9y ago
I don't think this is enough. I think this just mitigates the ability to use high precision to determine cache misses on array accesses. The leaked data is still there and the paper says it's one of 64 possibilities. Enabling site isolation helps since it's only process memory. Someone correct me if I misunderstand. EDIT: Also, just confirmed via https://jsfiddle.net/5n6poqjd/ https://jsfiddle.net/5n6poqjd/ that only FF has SharedArrayBuffer disabled. Chrome isn't going to release 64 which has SharedArrayBuffer disabled for a couple of weeks.
bzbarsky 9y ago
The SAB and clock changes are all to reduce timer precision. Reducing timer precision doesn't _fix_ the problem, but does reduce the rate of the data leak, which means it takes longer to exfiltrate the same information. Whether this is sufficiennt mitigation depends on your threat model and the exact amount of rate reduction. For example, a leak of 1 byte per hour might be OK in some threat models but not others.
- MrBuddyCasino 9y ago
  Wasn‘t aware, thx!