7 ms·

"Meltdown" is an Intel bug. "Spectre" is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandb

"Meltdown" is an Intel bug. "Spectre" is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code. Any system which keeps data from multiple customers (or whatever) in the same process is going to be highly vulnerable.

simion314 9y ago
From the article it seems that is not 100% sure AMD and ARM are not affected by metldown, only that they could not trigger the issue, but authors mention this "However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed."
- jhallenworld 9y ago
  I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until retire, but other implementations are possible. Anyway, so it could be that AMD and ARM are vulnerable, but it's possible that they are not.
  - olliej 9y ago
    There are two different issues. 1. Intel only (so far) is related to prefetching privileged memory 2. More or less everyone: Speculatively executing code that has variable execution time.
  - bonzini 9y ago
    > I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.
    - contrarian_ 9y ago
      I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.
      - londons_explore 9y ago
        The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs. Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs. This attack shows a side channel which is general purpose, reliable, and fast.
        contrarian_ 9y ago
        > The mistake is clear from the design There is no fundamental reason why speculative instructions should be allowed to mutate the cache. OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1] [1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL, 2006, pp. 473-482. doi: 10.1109/ACSAC.2006.20
        bonzini 9y ago
        > There is no fundamental reason why speculative instructions should be allowed to mutate the cache. There is: hundreds of instructions can be in flight speculatively at the same time, especially if you take hyperthreading into account. Good luck rolling them all back. The question is not whether the cache should be mutated during speculative execution. It's what kinds of speculative execution are allowed, and in some cases it's not even clear if fences should be placed by the programmer (whack-a-mole style), the compiler (not sure how) or the processor (probably not). It's non-obvious enough that how to solve it is to some extent a research problem.
Certhas 9y ago
After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?
- labster 9y ago
  I don't know much about this particular flaw, but I imagine it'll be pretty hard until someone releases an exploit kit, and then pretty easy after that.
  - contrarian_ 9y ago
    It's an arms race, there will always be new ways of exploiting this flaw in unexpected ways unless speculation is disabled entirely on existing CPUs.
- FranOntanaya 9y ago
  It doesn't look that hard, and in any case, we will suffer the mitigation consequences either way.
  - contrarian_ 9y ago
    Worse, no mitigation will ever be complete against Spectre, unless flat out disabling speculation across memory loads.
    - wilun 9y ago
      With the right new instructions inserted at the right place, assisted by a good type system, and a processor that does not share its resources like crazy in highly uncontrolled ways, this seems fixable. Sadly, I feel the only part that won't happen will be the programming language part, but who knows.
- olliej 9y ago
  it isn't. There have been a few PoC referenced on twitter, and the spectre paper itself reference a PoC in browser hosted javascript (e.g. random ad can scan memory) it's obviously not a free + zero time activity, but I'm going to assume someone making an ad to scan memory isn't super concerned about end user cpu usage or battery life..
kibwen 9y ago
> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Here's the synchronized announcement from Chrome/Chromium: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca https://sites.google.com/a/chromium.org/dev/Home/chromium-se... "Chrome's JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional mitigations and hardening measures which will further reduce the impact of this class of attack. The mitigations may incur a performance penalty." Chrome 64 will be hitting stable this month, which means that it ought to be possible to benchmark the performance penalty via testing in Chrome beta. Anybody tried yet?
- dannyw 9y ago
  The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.
  - kibwen 9y ago
    I don't get the impression that those are the full extent of the changes though; I think those two were called out only because they're API changes rather than implementation details. Haven't checked the code so I could be wrong, of course.
    - deleted 9y ago
      [deleted]
    - deleted 9y ago
      [deleted]
    - mirashii 9y ago
      A little bit more info can be found here [1]. In particular, site isolation [2] will also assist in protecting against this vulnerability. [1] https://support.google.com/faqs/answer/7622138#chrome https://support.google.com/faqs/answer/7622138#chrome [2] http://www.chromium.org/Home/chromium-security/site-isolation http://www.chromium.org/Home/chromium-security/site-isolatio...
binarycrusader 9y ago
"Spectre" is very bad news and affects all modern CPUs It's not yet clear whether it affects all modern CPUs, notably I have yet to see any mention of modern POWER/MIPS/SPARC-based designs. If someone has pointers, those particular cases would probably be quite interesting.
- pizlonator 9y ago
  It affects CPUs that do speculative execution. Pretty sure some powers do.
  - binarycrusader 9y ago
    I wonder to what degree some systems are affected. I believe Solaris already uses separate address spaces on SPARC for user and kernel. I haven’t looked over the SPARC architecture manual to see if they allow speculative execution beyond privilege boundaries.
    - olliej 9y ago
      That only prevent reading over higher privilege (the meltdown vulnerability) it doesn't protect the arbitrary user land reads from spectre.
- cthalupa 9y ago
  https://access.redhat.com/security/vulnerabilities/speculativeexecution https://access.redhat.com/security/vulnerabilities/speculati... Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).
  - deleted 9y ago
    [deleted]
asveikau 9y ago
> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code. It seems like keeping untrusted code in a separate address space would be a suitable workaround? A lot of comments here seem to be implying that meltdown-style reading of separate address spaces is possible via Spectre, and my read is that it wouldn't.
- valleyer 9y ago
  No, the Spectre paper discusses cross-process attacks too. First, you use BTB poisoning to coerce the victim process to branch-mispredict to code of your choice (a "gadget"). You can get that code to load memory of your choice, which can be the code of shared libraries (which are usually loaded only once into physical memory for all processes). Then you can do timing attacks using the last-level cache to determine whether that memory is in cache. It's certainly not easy, but it's doable.
  - rtpg 9y ago
    This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton misses, if you can't control what the victim process accesses, it seems harder to exploit. We're all talking about how Spectre is this magic "get access to any memory from any process". But it looks to me like it's a new class of attack, that still requires specific entry points for the software you're trying to attack. I'd like to be proven wrong on this, but it _feels_ like this is more of a software thing like other timing bugs. In theory you can write software that isn't vulnerable EDIT: my reading of the "JS Spectre implementation" is "JIT code runs in the process of the browser + you can write JS code to read the process's own memory". I can imagine messiness with extensions (1Password in particular).
    - stupidcar 9y ago
      I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch. Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likely go. Then you trigger the victim process in the way you know will cause a very similar branching operation. Even though it's operating within an entirely different process, the branch predictor uses what it learnt in the hostile process to predict the branch result in the victim process. It jumps to the address the hostile process taught it, and starts to speculatively execute code there. Eventually, it figures out it guessed wrong, but by then it's too late, and the information has leaked via a side-channel in a way that the hostile process can detect. So, essentially, you're use the branch predictor's cache to send the memory address. And you're not sending it to the victim process, you're sending it directly to the CPU. The victim process will never even know it's been attacked, because when the branch predictor hides the consequences of its incorrect guess from being detected by conventional means.

simion314 9y ago

From the article it seems that is not 100% sure AMD and ARM are not affected by metldown, only that they could not trigger the issue, but authors mention this "However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed."

jhallenworld 9y ago
I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until retire, but other implementations are possible. Anyway, so it could be that AMD and ARM are vulnerable, but it's possible that they are not.
- olliej 9y ago
  There are two different issues. 1. Intel only (so far) is related to prefetching privileged memory 2. More or less everyone: Speculatively executing code that has variable execution time.
- bonzini 9y ago
  > I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.
  - contrarian_ 9y ago
    I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.
    - londons_explore 9y ago
      The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs. Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs. This attack shows a side channel which is general purpose, reliable, and fast.
      - contrarian_ 9y ago
        > The mistake is clear from the design There is no fundamental reason why speculative instructions should be allowed to mutate the cache. OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1] [1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL, 2006, pp. 473-482. doi: 10.1109/ACSAC.2006.20
        bonzini 9y ago
        > There is no fundamental reason why speculative instructions should be allowed to mutate the cache. There is: hundreds of instructions can be in flight speculatively at the same time, especially if you take hyperthreading into account. Good luck rolling them all back. The question is not whether the cache should be mutated during speculative execution. It's what kinds of speculative execution are allowed, and in some cases it's not even clear if fences should be placed by the programmer (whack-a-mole style), the compiler (not sure how) or the processor (probably not). It's non-obvious enough that how to solve it is to some extent a research problem.

Certhas 9y ago

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?

labster 9y ago
I don't know much about this particular flaw, but I imagine it'll be pretty hard until someone releases an exploit kit, and then pretty easy after that.
- contrarian_ 9y ago
  It's an arms race, there will always be new ways of exploiting this flaw in unexpected ways unless speculation is disabled entirely on existing CPUs.
FranOntanaya 9y ago
It doesn't look that hard, and in any case, we will suffer the mitigation consequences either way.
- contrarian_ 9y ago
  Worse, no mitigation will ever be complete against Spectre, unless flat out disabling speculation across memory loads.
  - wilun 9y ago
    With the right new instructions inserted at the right place, assisted by a good type system, and a processor that does not share its resources like crazy in highly uncontrolled ways, this seems fixable. Sadly, I feel the only part that won't happen will be the programming language part, but who knows.
olliej 9y ago
it isn't. There have been a few PoC referenced on twitter, and the spectre paper itself reference a PoC in browser hosted javascript (e.g. random ad can scan memory) it's obviously not a free + zero time activity, but I'm going to assume someone making an ad to scan memory isn't super concerned about end user cpu usage or battery life..

kibwen 9y ago

> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Here's the synchronized announcement from Chrome/Chromium: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca https://sites.google.com/a/chromium.org/dev/Home/chromium-se... "Chrome's JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional mitigations and hardening measures which will further reduce the impact of this class of attack. The mitigations may incur a performance penalty." Chrome 64 will be hitting stable this month, which means that it ought to be possible to benchmark the performance penalty via testing in Chrome beta. Anybody tried yet?

dannyw 9y ago
The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.
- kibwen 9y ago
  I don't get the impression that those are the full extent of the changes though; I think those two were called out only because they're API changes rather than implementation details. Haven't checked the code so I could be wrong, of course.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - mirashii 9y ago
    A little bit more info can be found here [1]. In particular, site isolation [2] will also assist in protecting against this vulnerability. [1] https://support.google.com/faqs/answer/7622138#chrome https://support.google.com/faqs/answer/7622138#chrome [2] http://www.chromium.org/Home/chromium-security/site-isolation http://www.chromium.org/Home/chromium-security/site-isolatio...

binarycrusader 9y ago

"Spectre" is very bad news and affects all modern CPUs It's not yet clear whether it affects all modern CPUs, notably I have yet to see any mention of modern POWER/MIPS/SPARC-based designs. If someone has pointers, those particular cases would probably be quite interesting.

pizlonator 9y ago
It affects CPUs that do speculative execution. Pretty sure some powers do.
- binarycrusader 9y ago
  I wonder to what degree some systems are affected. I believe Solaris already uses separate address spaces on SPARC for user and kernel. I haven’t looked over the SPARC architecture manual to see if they allow speculative execution beyond privilege boundaries.
  - olliej 9y ago
    That only prevent reading over higher privilege (the meltdown vulnerability) it doesn't protect the arbitrary user land reads from spectre.
cthalupa 9y ago
https://access.redhat.com/security/vulnerabilities/speculativeexecution https://access.redhat.com/security/vulnerabilities/speculati... Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).
- deleted 9y ago
  [deleted]

asveikau 9y ago

> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code. It seems like keeping untrusted code in a separate address space would be a suitable workaround? A lot of comments here seem to be implying that meltdown-style reading of separate address spaces is possible via Spectre, and my read is that it wouldn't.

valleyer 9y ago
No, the Spectre paper discusses cross-process attacks too. First, you use BTB poisoning to coerce the victim process to branch-mispredict to code of your choice (a "gadget"). You can get that code to load memory of your choice, which can be the code of shared libraries (which are usually loaded only once into physical memory for all processes). Then you can do timing attacks using the last-level cache to determine whether that memory is in cache. It's certainly not easy, but it's doable.
- rtpg 9y ago
  This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton misses, if you can't control what the victim process accesses, it seems harder to exploit. We're all talking about how Spectre is this magic "get access to any memory from any process". But it looks to me like it's a new class of attack, that still requires specific entry points for the software you're trying to attack. I'd like to be proven wrong on this, but it _feels_ like this is more of a software thing like other timing bugs. In theory you can write software that isn't vulnerable EDIT: my reading of the "JS Spectre implementation" is "JIT code runs in the process of the browser + you can write JS code to read the process's own memory". I can imagine messiness with extensions (1Password in particular).
  - stupidcar 9y ago
    I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch. Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likely go. Then you trigger the victim process in the way you know will cause a very similar branching operation. Even though it's operating within an entirely different process, the branch predictor uses what it learnt in the hostile process to predict the branch result in the victim process. It jumps to the address the hostile process taught it, and starts to speculatively execute code there. Eventually, it figures out it guessed wrong, but by then it's too late, and the information has leaked via a side-channel in a way that the hostile process can detect. So, essentially, you're use the branch predictor's cache to send the memory address. And you're not sending it to the victim process, you're sending it directly to the CPU. The victim process will never even know it's been attacked, because when the branch predictor hides the consequences of its incorrect guess from being detected by conventional means.