3 ms·

Yes, I have the same feeling about the SPECTRE mitigations, for example. No one is going to be attacking my home Linux box with SPECTRE (has anyone ever been at

Yes, I have the same feeling about the SPECTRE mitigations, for example. No one is going to be attacking my home Linux box with SPECTRE (has anyone ever been attacked with SPECTRE?), but by default they remove like 10+% CPU performance, just in case. I disabled the mitigations.

SV_BubbleTime 3y ago
I think the threat there isn’t someone else attacking their VM to get to your machine - but that there was at least some proof of concept over JavaScript remotely. But otherwise I agree.
- monocasa 3y ago
  There's also netspectre which remotely attacks a kernel with malformed network packets. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535
- coldpie 3y ago
  > but that there was at least some proof of concept over JavaScript remotely Yeah, but that's exactly the rube goldberg kinda thing the quote in the OP is parodying. The threat is IF I come across a hostile page, AND I'm running a specific web browser with the right JS properties, AND I am also running the right security-critical software, AND the attacker can correctly guess the memory layout, AND the JS runs for long enough to pull enough bytes to actually be meaningful, AND the attacker can connect the meaningful secret with whatever purpose it's intended for, AND the attacker can pull my legit data out with all the false positives they're getting from running an un-targeted website, THEN they can maybe like log into my old AOL account or something. It just isn't going to happen. There are usecases where SPECTRE is a meaningful attack (shared hosting being the obvious one), but a normal end-user machine? Nah. Certainly not likely enough to nuke 10% CPU perf on every machine by default.
  - paulmd 3y ago
    > AND the attacker can correctly guess the memory layout AMD has several unpatched vulnerabilities that leak the memory layout/page table mappings, effectively nullifying KASLR as well. they can be mitigated by KPTI, but AMD ships that in a disabled state by default because of the performance implications (with ryzen's reliance on giant caches, flushing caches every time they make a syscall would be even more disastrous for them than for Intel, so they cheat and ship insecure-by-default). The rest of that sentence is just an overwrought description of running a javascript segment in a web browser, there's nothing load-bearing there to prevent an attack.
supriyo-biswas 3y ago
For multi tenant environments like a provider running VMs, preventing speculative execution attacks is a priority; otherwise someone can literally see what another tenant is doing (and there are attack demos demonstrating it). Furthermore, the entire concept of paging and virtual memory is built around the concept of not letting one process see what the other one is doing; the described attacks in the prime+probe/flush+reload attacks are quite practical and could let some JS on a website steal passwords (though the information leak rate is a little lower than what you generally get by outright stealing credential files using malware, though that tends to show up on EDRs, whereas speculative execution attacks just show up as memory access patterns with fewer cache hits than what’s expected.) If we’re to say that you don’t need isolation, we could just drop paging and every process just have a view of every other process.
- dataflow 3y ago
  > the entire concept of paging and virtual memory is built around the concept of not letting one process see what the other one is doing... If we’re to say that you don’t need isolation, we could just drop paging and every process just have a view of every other process. This seems to be moving goalposts. It's like saying curtains were built around the idea of not letting one person see inside a house, so the moment IR sensors (or Wi-Fi or radar or whatever) start being able to see in the house, everyone might as well just remove their curtains.
bee_rider 3y ago
Yeah I think these sort of attacks only matter to people who run random code sent by untrusted parties on their machines. But I mean that includes Amazon and everybody that browses the web with JavaScript enabled, so I guess it is a pretty big population that might be interested?
- coldpie 3y ago
  If your threat model now requires a browser in the chain, then we can fix it in the browser, no? https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html https://security.googleblog.com/2018/07/mitigating-spectre-w... Still safe at full CPU perf.
  - bee_rider 3y ago
    I don’t think I’ve described a threat model, just given and example of a single vector that is pretty widespread. I just assume processes on my system can get root if they really want.
- G3rn0ti 3y ago
  Yes, but Spectre was easily fixed by limiting the accuracy of the Browsers’ window.Performance interface AFIR. Meltdown on the other hand required a Kernel patch and a general performance penalty. I also have all meltdown mitigations turned off in the Kernel on my Laptop.
SomeoneFromCA 3y ago
Well it is in a way like "herd immunity" - if everyone around has mitigations on, no one would bother to use it as an attack vector. If everyone would for some reason start disabling mitigations, then the bug will stasrt getting exploited.

SV_BubbleTime 3y ago

I think the threat there isn’t someone else attacking their VM to get to your machine - but that there was at least some proof of concept over JavaScript remotely. But otherwise I agree.

monocasa 3y ago
There's also netspectre which remotely attacks a kernel with malformed network packets. https://arxiv.org/abs/1807.10535 https://arxiv.org/abs/1807.10535
coldpie 3y ago
> but that there was at least some proof of concept over JavaScript remotely Yeah, but that's exactly the rube goldberg kinda thing the quote in the OP is parodying. The threat is IF I come across a hostile page, AND I'm running a specific web browser with the right JS properties, AND I am also running the right security-critical software, AND the attacker can correctly guess the memory layout, AND the JS runs for long enough to pull enough bytes to actually be meaningful, AND the attacker can connect the meaningful secret with whatever purpose it's intended for, AND the attacker can pull my legit data out with all the false positives they're getting from running an un-targeted website, THEN they can maybe like log into my old AOL account or something. It just isn't going to happen. There are usecases where SPECTRE is a meaningful attack (shared hosting being the obvious one), but a normal end-user machine? Nah. Certainly not likely enough to nuke 10% CPU perf on every machine by default.
- paulmd 3y ago
  > AND the attacker can correctly guess the memory layout AMD has several unpatched vulnerabilities that leak the memory layout/page table mappings, effectively nullifying KASLR as well. they can be mitigated by KPTI, but AMD ships that in a disabled state by default because of the performance implications (with ryzen's reliance on giant caches, flushing caches every time they make a syscall would be even more disastrous for them than for Intel, so they cheat and ship insecure-by-default). The rest of that sentence is just an overwrought description of running a javascript segment in a web browser, there's nothing load-bearing there to prevent an attack.

supriyo-biswas 3y ago

For multi tenant environments like a provider running VMs, preventing speculative execution attacks is a priority; otherwise someone can literally see what another tenant is doing (and there are attack demos demonstrating it). Furthermore, the entire concept of paging and virtual memory is built around the concept of not letting one process see what the other one is doing; the described attacks in the prime+probe/flush+reload attacks are quite practical and could let some JS on a website steal passwords (though the information leak rate is a little lower than what you generally get by outright stealing credential files using malware, though that tends to show up on EDRs, whereas speculative execution attacks just show up as memory access patterns with fewer cache hits than what’s expected.) If we’re to say that you don’t need isolation, we could just drop paging and every process just have a view of every other process.

dataflow 3y ago
> the entire concept of paging and virtual memory is built around the concept of not letting one process see what the other one is doing... If we’re to say that you don’t need isolation, we could just drop paging and every process just have a view of every other process. This seems to be moving goalposts. It's like saying curtains were built around the idea of not letting one person see inside a house, so the moment IR sensors (or Wi-Fi or radar or whatever) start being able to see in the house, everyone might as well just remove their curtains.

bee_rider 3y ago

Yeah I think these sort of attacks only matter to people who run random code sent by untrusted parties on their machines. But I mean that includes Amazon and everybody that browses the web with JavaScript enabled, so I guess it is a pretty big population that might be interested?

coldpie 3y ago
If your threat model now requires a browser in the chain, then we can fix it in the browser, no? https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html https://security.googleblog.com/2018/07/mitigating-spectre-w... Still safe at full CPU perf.
- bee_rider 3y ago
  I don’t think I’ve described a threat model, just given and example of a single vector that is pretty widespread. I just assume processes on my system can get root if they really want.
G3rn0ti 3y ago
Yes, but Spectre was easily fixed by limiting the accuracy of the Browsers’ window.Performance interface AFIR. Meltdown on the other hand required a Kernel patch and a general performance penalty. I also have all meltdown mitigations turned off in the Kernel on my Laptop.

SomeoneFromCA 3y ago

Well it is in a way like "herd immunity" - if everyone around has mitigations on, no one would bother to use it as an attack vector. If everyone would for some reason start disabling mitigations, then the bug will stasrt getting exploited.