7 ms·

> I've been indifferent to all these sidechannel attacks since the original Spectre/Meltdown and continue to maintain my opinion that this is really not of any

> I've been indifferent to all these sidechannel attacks since the original Spectre/Meltdown and continue to maintain my opinion that this is really not of any significance to a single-user PC. The original attacks worked in javascript that could be delivered by a browser to your single-user PC. Being able to steal secrets -- passwords, bank account information, ephemeral encryption keys to other sites -- is absolutely very significant to single-user computers. Dismissing it without consideration for mitigations is malicious IMO.

throw93232 4y ago
It seems disabling JIT on JS VM and only using slow interpreted mode is a good choice.
- codedokode 4y ago
  Also in this case memory consumption will be lower because JIT'ed code takes space. I think that it is a good idea.
  - azinman2 4y ago
    Has anyone produced meaningful benchmarks on real world websites? If I go to arstechnica, or NYTimes, or gmail — what will the difference be between JIT and non-JIT for page load and common operations?
    - game-of-throws 4y ago
      Edge did some benchmarks with their "Super Duper Secure Mode" and found that disabling JIT improves performance more often than not: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
      - Wowfunhappy 4y ago
        > and found that disabling JIT improves performance more often than not Well, kind of... >> We find that disabling the JIT does not always have negative impacts. Our tests that measured improvements in power showed 15% improvement on average and our regressions showed around 11% increase in power consumption. Memory is also a mixed story with negatively impacted tests showing a 2.3% regression, but a larger gain on the tests that showed improvements. Page Load times show the most severe decrease with tests that show regressions averaging around 17%. Startup times, however, have only a positive impact and no regressions. Most people are going to care about page load times more than anything else by far, and that's the one that quite clearly took a hit without JIT. It's great that no JIT makes Edge open faster, but how many times a day do you have to quit and restart your browser?
- hawk_ 4y ago
  is it possible to disable JIT on chrome or Firefox?
  - game-of-throws 4y ago
    I found this blog post for chrome/FF: https://lemmy.eus/post/7660 https://lemmy.eus/post/7660 And Edge has so-called "Super Duper Secure Mode": https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
  - smileybarry 4y ago
    Edge's newer "Enhanced Security"[1] toggles are essentially that, disabling JIT and WebAssembly (alongside other features) on sites you don't frequent. "Strict" disables them on all sites. 1: https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
- titzer 4y ago
  On the V8 teram we had a POC of forcing mispredicted instruction sequences in the interpreter that leaked data. Reorder buffers are 200-600 instructions these days, and indirect branch predictors needed to speculate through bytecode sequences are good enough that an interpreter is not safe.
rasz 4y ago
>The original attacks worked in javascript that could be delivered by a browser to your single-user PC no they didnt, otherwise there would be a demo page you could use right now to check if you are susceptible
- nteon 4y ago
  Yes they did. Here is one such demo: https://leaky.page/ https://leaky.page/
  - rasz 4y ago
    I have never patched even once 2018 install of win10 running chrome on intel Haswell, this demo fails to do anything.
    - tuckerman 4y ago
      Out of curiosity is it also using a circa-2018 chrome install? There have been mitigations pushed to Chrome and V8.
      - rasz 4y ago
        June build Chrome/102.xxx. I just tried 96.xx and [!] error: could not infer memory layout [] retrying. (2 retries left) [!] error: could not infer memory layout [] retrying. (1 retries left) [!] error: could not infer memory layout [!] no retries left Btw some parts (maybe whole thing??) uses WebAssembly and not just js.
        nneonneo 4y ago
        Wasm is trivially accessible from JavaScript, so it's not unreasonable to conflate the two, even if its technically incorrect. Wasm also can't do anything that JS couldn't already do; it's simply more convenient in many cases (and maybe somewhat faster at runtime) to write code in C/C++/Rust/whatever and compile it to Wasm than to write the code in JS. You could (and still can) compile these languages to asm.js instead, in which case the code would actually be JS, albeit a particularly weird dialect. The site pretty clearly says it works on Chrome 88, on Linux. Chrome 91 reduced the resolution of performance.now significantly, which likely broke this website (https://developer.chrome.com/blog/cross-origin-isolated-hr-timers/ https://developer.chrome.com/blog/cross-origin-isolated-hr-t...). You're also trying this out on Windows, which is also not supported by the demo page in its default configuration. But also: this was a demo page put together by a random security researcher on their own, based on a vulnerability from a year ago. It's not a reflection of what a motivated attacker could do with a sufficiently powerful exploitation primitive (say, this Retbleed attack).
icedchai 4y ago
There was never a real world exploit that did anything like that. They were all POCs that read data from themselves under ideal conditions.
- saagarjha 4y ago
  That’s because mitigations were rolled out very quickly.
  - icedchai 4y ago
    True, though I find it hard to believe there are still no real world exploits.
    - saagarjha 4y ago
      There might be! But I haven’t heard of anything publicly yet.
      - lazide 4y ago
        There is very little incentive for victims OR assailants to let anyone know if it has.
- bravetraveler 4y ago
  Say that were true - you knew all of the valued zero-days, attacks, etc - and determined nothing happened yet The plan for the future is... what? Pray that nobody ever makes it practical? I'm not saying anyone should lose sleep, that's silly - but disregarding a vector because there haven't been demonstrations in the wild is also silly. The first, and then likely a collection, will be discovered and traded on black markets. Eventually it'll leak, and then we'll know about it.
  - icedchai 4y ago
    I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical. You'll be looking for a needle in a haystack. There are easier, faster attacks available. I won't lose sleep over it.
userbinator 4y ago
Being able to steal secrets -- passwords, bank account information, ephemeral encryption keys to other sites -- is absolutely very significant to single-user computers. I can tell you that someone's password is "password". There's still the question of which account uses that. Encryption keys are even less easy to use from that perspective, since they are basically random bytes otherwise. What if I told you the AES write key used to secure the TLS connection for this post is D2 B1 CD 58 26 AF 0B 56 29 AE D6 D3 5D 2D 58 96 93 5D 6D 58 26 BA 5A 5A E4 3D D5 7D 55 5C F9 EF ? Would you be able to do anything with that? You even said the keyword yourself: "ephemeral". If I was someone who is being specifically targeted I might care, but I'm willing to bet that the vast majority of users are not, and those who are will know who they are (and something like this is probably the least of their worries.) ...which brings me back to the faulty premise of the original PoCs for these timing side-channels: they require gathering so much information about the environment beforehand, and such careful setup, that someone with that level of knowledge most likely doesn't need to use a side-channel anyway.
- pigeonhole123 4y ago
  The very definition of security through obscurity. As long as you’re obscure enough for no one to care, you’re safe.
- staticassertion 4y ago
  I agree that most attackers aren't going to use this attack, but only because privesc through standard means is well documented and researched. It wouldn't make sense to weaponize this sort of attack while the existing attacks continue to work. But otherwise you're putting way too much stock into your examples annoying attackers out of their work. I assure you, exploit developers will sit there and stare at hex dumps and put enough of those primitives together to build the exploit chain they need. It's purely because security's such a shitshow in other ways that we don't see more attacks leveraging this sort of thing. If someone (like Jann) does enough research, puts it out there, and this becomes something that more hackers are comfortable with, they'll absolutely use this.
titzer 4y ago
> Dismissing it without consideration for mitigations is malicious IMO. But this is par for the course in certain circles who put performance above security for literally decades, because performance is easy to measure (and therefore optimize!), and security isn't. It's the exact same reason we've been gaslit with FUD about needing to write all system software in unsafe languages. Now the chickens are coming home to roost. All those corners we cut to save some memory, some time, or some money are back to haunt us--at every level of the stack. Enjoy the meltdown :)
wokkel 4y ago
That's why you disable JavaScript: we scrutinize downloaded exe files carefully and have virusscanners running all the time while allowing untrusted JavaScript to reach your CPU. As long as there is no effectieve way to tell trusted and untrusted JavaScript apart, having it enabled is silly.

throw93232 4y ago

It seems disabling JIT on JS VM and only using slow interpreted mode is a good choice.

codedokode 4y ago
Also in this case memory consumption will be lower because JIT'ed code takes space. I think that it is a good idea.
- azinman2 4y ago
  Has anyone produced meaningful benchmarks on real world websites? If I go to arstechnica, or NYTimes, or gmail — what will the difference be between JIT and non-JIT for page load and common operations?
  - game-of-throws 4y ago
    Edge did some benchmarks with their "Super Duper Secure Mode" and found that disabling JIT improves performance more often than not: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
    - Wowfunhappy 4y ago
      > and found that disabling JIT improves performance more often than not Well, kind of... >> We find that disabling the JIT does not always have negative impacts. Our tests that measured improvements in power showed 15% improvement on average and our regressions showed around 11% increase in power consumption. Memory is also a mixed story with negatively impacted tests showing a 2.3% regression, but a larger gain on the tests that showed improvements. Page Load times show the most severe decrease with tests that show regressions averaging around 17%. Startup times, however, have only a positive impact and no regressions. Most people are going to care about page load times more than anything else by far, and that's the one that quite clearly took a hit without JIT. It's great that no JIT makes Edge open faster, but how many times a day do you have to quit and restart your browser?
hawk_ 4y ago
is it possible to disable JIT on chrome or Firefox?
- game-of-throws 4y ago
  I found this blog post for chrome/FF: https://lemmy.eus/post/7660 https://lemmy.eus/post/7660 And Edge has so-called "Super Duper Secure Mode": https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
- smileybarry 4y ago
  Edge's newer "Enhanced Security"[1] toggles are essentially that, disabling JIT and WebAssembly (alongside other features) on sites you don't frequent. "Strict" disables them on all sites. 1: https://support.microsoft.com/en-us/microsoft-edge/enhance-your-security-on-the-web-with-microsoft-edge-b8199f13-b21b-4a08-a806-daed31a1929d https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
titzer 4y ago
On the V8 teram we had a POC of forcing mispredicted instruction sequences in the interpreter that leaked data. Reorder buffers are 200-600 instructions these days, and indirect branch predictors needed to speculate through bytecode sequences are good enough that an interpreter is not safe.

rasz 4y ago

>The original attacks worked in javascript that could be delivered by a browser to your single-user PC no they didnt, otherwise there would be a demo page you could use right now to check if you are susceptible

nteon 4y ago
Yes they did. Here is one such demo: https://leaky.page/ https://leaky.page/
- rasz 4y ago
  I have never patched even once 2018 install of win10 running chrome on intel Haswell, this demo fails to do anything.
  - tuckerman 4y ago
    Out of curiosity is it also using a circa-2018 chrome install? There have been mitigations pushed to Chrome and V8.
    - rasz 4y ago
      June build Chrome/102.xxx. I just tried 96.xx and [!] error: could not infer memory layout [] retrying. (2 retries left) [!] error: could not infer memory layout [] retrying. (1 retries left) [!] error: could not infer memory layout [!] no retries left Btw some parts (maybe whole thing??) uses WebAssembly and not just js.
      - nneonneo 4y ago
        Wasm is trivially accessible from JavaScript, so it's not unreasonable to conflate the two, even if its technically incorrect. Wasm also can't do anything that JS couldn't already do; it's simply more convenient in many cases (and maybe somewhat faster at runtime) to write code in C/C++/Rust/whatever and compile it to Wasm than to write the code in JS. You could (and still can) compile these languages to asm.js instead, in which case the code would actually be JS, albeit a particularly weird dialect. The site pretty clearly says it works on Chrome 88, on Linux. Chrome 91 reduced the resolution of performance.now significantly, which likely broke this website (https://developer.chrome.com/blog/cross-origin-isolated-hr-timers/ https://developer.chrome.com/blog/cross-origin-isolated-hr-t...). You're also trying this out on Windows, which is also not supported by the demo page in its default configuration. But also: this was a demo page put together by a random security researcher on their own, based on a vulnerability from a year ago. It's not a reflection of what a motivated attacker could do with a sufficiently powerful exploitation primitive (say, this Retbleed attack).

icedchai 4y ago

There was never a real world exploit that did anything like that. They were all POCs that read data from themselves under ideal conditions.

saagarjha 4y ago
That’s because mitigations were rolled out very quickly.
- icedchai 4y ago
  True, though I find it hard to believe there are still no real world exploits.
  - saagarjha 4y ago
    There might be! But I haven’t heard of anything publicly yet.
    - lazide 4y ago
      There is very little incentive for victims OR assailants to let anyone know if it has.
bravetraveler 4y ago
Say that were true - you knew all of the valued zero-days, attacks, etc - and determined nothing happened yet The plan for the future is... what? Pray that nobody ever makes it practical? I'm not saying anyone should lose sleep, that's silly - but disregarding a vector because there haven't been demonstrations in the wild is also silly. The first, and then likely a collection, will be discovered and traded on black markets. Eventually it'll leak, and then we'll know about it.
- icedchai 4y ago
  I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical. You'll be looking for a needle in a haystack. There are easier, faster attacks available. I won't lose sleep over it.

userbinator 4y ago

Being able to steal secrets -- passwords, bank account information, ephemeral encryption keys to other sites -- is absolutely very significant to single-user computers. I can tell you that someone's password is "password". There's still the question of which account uses that. Encryption keys are even less easy to use from that perspective, since they are basically random bytes otherwise. What if I told you the AES write key used to secure the TLS connection for this post is D2 B1 CD 58 26 AF 0B 56 29 AE D6 D3 5D 2D 58 96 93 5D 6D 58 26 BA 5A 5A E4 3D D5 7D 55 5C F9 EF ? Would you be able to do anything with that? You even said the keyword yourself: "ephemeral". If I was someone who is being specifically targeted I might care, but I'm willing to bet that the vast majority of users are not, and those who are will know who they are (and something like this is probably the least of their worries.) ...which brings me back to the faulty premise of the original PoCs for these timing side-channels: they require gathering so much information about the environment beforehand, and such careful setup, that someone with that level of knowledge most likely doesn't need to use a side-channel anyway.

pigeonhole123 4y ago
The very definition of security through obscurity. As long as you’re obscure enough for no one to care, you’re safe.
staticassertion 4y ago
I agree that most attackers aren't going to use this attack, but only because privesc through standard means is well documented and researched. It wouldn't make sense to weaponize this sort of attack while the existing attacks continue to work. But otherwise you're putting way too much stock into your examples annoying attackers out of their work. I assure you, exploit developers will sit there and stare at hex dumps and put enough of those primitives together to build the exploit chain they need. It's purely because security's such a shitshow in other ways that we don't see more attacks leveraging this sort of thing. If someone (like Jann) does enough research, puts it out there, and this becomes something that more hackers are comfortable with, they'll absolutely use this.

titzer 4y ago

> Dismissing it without consideration for mitigations is malicious IMO. But this is par for the course in certain circles who put performance above security for literally decades, because performance is easy to measure (and therefore optimize!), and security isn't. It's the exact same reason we've been gaslit with FUD about needing to write all system software in unsafe languages. Now the chickens are coming home to roost. All those corners we cut to save some memory, some time, or some money are back to haunt us--at every level of the stack. Enjoy the meltdown :)

wokkel 4y ago

That's why you disable JavaScript: we scrutinize downloaded exe files carefully and have virusscanners running all the time while allowing untrusted JavaScript to reach your CPU. As long as there is no effectieve way to tell trusted and untrusted JavaScript apart, having it enabled is silly.