14 ms·

CacheOut: Leaking Data on Intel CPUs via Cache Evictions

607 points by beefhash 7y ago

kohtatsu 7y ago
Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?
- _hl_ 7y ago
  > AMD is not affected by CacheOut, as AMD does not offer any feature akin to Intel TSX on their current offering of CPUs. It seems to be down to the notoriously buggy TSX (hardware transactional memory) in Intel CPUs.
  - rodgerd 7y ago
    It's interesting that TSX seems to be one of those holy grails that causes more problems than it solves - trying to implement TSX caused, I believe, huge problems for Sunacle's Rock processor team.
    - deleted 7y ago
      [deleted]
- eyegor 7y ago
  Amd still has almost no server marketshare. This attack specifically leverages tsx, which is an Intel set of transactional extensions to the cpu microcode. Intel has since published microcode updates to enable you to disable tsx.
  - topspin 7y ago
    > Amd still has almost no server marketshare. Yet another Intel exclusive side channel vulnerability might help change that. This side channel stuff is terrible for cloud operators. Every time they have to adopt another layer of mitigation some fraction of their capacity disappears in a puff of shame and excuses.
  - cosmiccatnap 7y ago
    Not sure you've been keeping up but in 2020 most major server makers have switched or at least offer an epyc varient because the price/performance is better even without Intel's constant security woes
    - eyegor 7y ago
      Yes but most enterprise customers have reacted by buying more Intel chips, because the cost of migrating infrastructure is much greater. Once you're invested deep into the omni-path level interconnects and spend 100k+ on cables alone, buying a few extra blades isn't a huge deal. Speaking as someone who has sat in on meetings where we negotiate with vendors for 1ku pricing. The big migration will happen in about 2-4 years. Typical enterprise schedule is 3-5 year cycles, zen2 launch was 2019.
- Symmetry 7y ago
  In this case AMD just doesn't support TSX instructions. For previous vulnerabilities with Meltdown I'd guess that AMD just didn't feel they had the engineering resources to do after the fact validation of memory access permissions without architecturally leaking data in some weird corner case. But then along comes Meltdown and it turns out that non-architectural leaks are a thing that can happen and if you try to do after the fact validation you can't prevent them.
- makomk 7y ago
  Mostly, it seems to be a difference in design philosphy - AMD processors prevent speculative reads of data that shouldn't be accessible almost everywhere, whereas Intel ones allow them pretty much everywhere. This particular attack requires TSX which AMD processors don't have, but I don't think it'd work on AMD processors anyway because they're not missing the security check that Intel ones are. If I remember rightly, there were other now-mitigated exploits for this line fill buffer leak that didn't require TSX. (The one exception is also interesting. AMD processors allow speculative reads past the end of x86 segments and past BOUND instructions, which of course no-one uses these days. This suggests there may have been a deliberate decision to block them in the more important cases.)
  - temac 7y ago
    It is known since... forever?, that one should not speculate across security boundaries. This was not enough to avoid Spectre, but this was largely enough to avoid TONS of security vulns Intel is also susceptible to. Somebody messed-up big time. Or from a business point of view did they? Intel current problems are manufacturing and the continuously lower power of their "legacy" processor (except due to manufacturing problems, this "legacy" is still mostly the current one) makes it so that people are buying more. Of course there is AMD back in the game, but the market demand is large enough; plus AMD would have been there anyway, and, in the fiction that Intel did take good parts of the perf hit upfront instead of the secu vulns, as competitive as in the current situation. The people most annoyed are the users. Intel got away by pretending this was not really defects in their product but only new SW tricks that they will help defend against, and their clients just let them say that without much complaint (well, I guess big ones got some rebate...) but security researchers and/or processor designers know very well this is bullshit (see the vulns papers and FAQ) and that they simply fucked-up big time on Meltdown, MDS, etc. I don't care that a few other vendors did some of the same mistakes: they are still mistakes and design flaws, and not even something new. Pretty much the only new shinny thing in this stream of vulns was Spectre and the few variants that appeared quite early on (but NOT Meltdown&co). The rest are design flaws that comes from the "oh not a big deal to leak that potentially privileged data, we will drop anything and trap before any derivative can go out anyway" mentality. Yeah, no, I'm sorry but the funding paper about speculation already told to not do that :/ Either they did not do their homework, or they voluntarily chose to violate the rule.
- loeg 7y ago
  It is specific to Intel TSX, which should already be disabled due to earlier published MDS vulnerabilities in the same space.
  - jdsully 7y ago
    Only the implicit TSX has been disabled. You can still use xbegin/xend/xabort. They had an additional mode that would transparently convert many spinlocks into transactions without code changes - that is now gone.
    - loeg 7y ago
      "Should" as in, I think the earlier vulnerability was damning enough that people /should/ have disabled TSX entirely. If they have not already, they /should/ now.
      - jdsully 7y ago
        TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventually.
        cosmiccatnap 7y ago
        That's putting alot of faith in the OS and it's ability to sandbox correctly.
        loeg 7y ago
        Especially when this publication shows that sandboxing correctly isn't possible with TSX.
        loeg 7y ago
Flockster 7y ago
Is this coordinated with OS providers? It only mentioned that Intel released microcode.
demarcus 7y ago
rgy g
emn13 7y ago
I mean, you gotta appeciate their efforts to make something so technical approachable by the general population, including gems like this in their Q&A: :-D: What is an operating system? An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it. Furthermore, the operating system decides how this hardware is shared by your software, and as such has access to all the data stored in your computer's memory. Thus, it is essential to isolate the operating system from the other programs running on the machine.
- cptskippy 7y ago
  > An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface So uh... that's a reference to the IME right? Not the user's installed OS.
  - chmod775 7y ago
    No they're speaking of the (user installed) OS.
    - cptskippy 7y ago
      I was kind of joking and it's also not explicitly stated, that's just the assumption the reader makes.
loeg 7y ago
Tl;dr: Another Intel TSX async abort side channel. See also Intel's advisory: https://software.intel.com/security-software-guidance/software-guidance/l1d-eviction-sampling https://software.intel.com/security-software-guidance/softwa... (cite 23 in the CacheOut PDF).
annoyingnoob 7y ago
Is disabling Hyper-threading a viable work-around in this case?
- sjnu 7y ago
  "CacheOut is effective even in the non HyperThreaded scenario, where the victim always runs sequentially to the attacker."
deleted 7y ago
[deleted]
lukestateson 7y ago
Intel got cash in, but we've got cacheout.
jnordwick 7y ago
Before people get all nutty as usual: This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem. The attacker basically needs to be running a binary on the machine (not JS in a browser or anything). The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With noise reduction to enhance recovery, they said it took twice as long - so about 113 byte/minute. It seems to be able to only be able to control the bottom 12-bits of the address to recover (but I didn't fully get why) and require the process to be either reading or writing the data to get it into L1 cache somehow, so just sitting in RAM isn't good enough. attacker still needs to figure out an address (even with ASLR there is still a lot of guessing, and if you have really sensitive data, just move it every second until you wipe it). Interesting, but kind of a non-issue.
- jandrese 7y ago
  That's a lot of work, but the instant it's in a rootkit everybody will be able to do it. 113 bytes is extracting an AES key from memory in about a minute. It's only really hard and messy for the first guy who implements it, after that it is much easier, albeit still fairly messy. I'm not saying we need to panic, but it's more than a "non-issue".
  - scandinavian 7y ago
    >but the instant it's in a rootkit everybody will be able to do it. This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.
    - jandrese 7y ago
      The first feature of a rootkit is to get root access. A userspace kernel-information leak utility would be very useful for this step.
      - scandinavian 7y ago
dmix 7y ago
As someone unfamiliar with creating scientific papers I'm curious if anyone knows what format the citation modal is using? https://imgur.com/a/bem4e8u https://imgur.com/a/bem4e8u Is it for TeX or a common syntax for some publishing platforms to pick up?
- detaro 7y ago
  Bibtex. Originally for the bibtex tool (which generates bibliographies for (La)TeX documents), but now common with other citation tools too.
- wwwhizz 7y ago
  That's bibtex, for LaTeX.
scandinavian 7y ago
>CacheOut violates the operating system's privacy by extracting information from it that facilitates other attacks, such as buffer overflow attacks. >More specifically, modern operating systems employ Kernel Address Space Layout Randomization (KASLR) and stack canaries. KASLR randomizes the location of the data structures and code used by the operating system, such that the location is unknown to an attacker. Stack canaries put secret values on the stack to detect whether an attacker has tampered with the stack. CacheOut extracts this information from the operating system, essentially enabling full exploitation via other software attacks, such such as buffer overflow attacks. Can anyone explain this scenario? Is this really a realistic scenario? Do they mean if you have code execution on a system, and want to escalate privileges, you would find another network/socket service that is running on the same system, find an exploit in this service, and then leak the stack canary to allow corrupting the stack? There's often easier ways to defeat the stack canary.
- loeg 7y ago
  Yes, it's a local privilege escalation issue, i.e. you must have local code execution first. Leaking KASLR/stack canary just mean you get 90s level triviality of attacking any stack-overflowing API you can find. Without this bug, if you found a stack-overflow you could trigger from your local unprivileged code, the target would likely detect the overflow due to the canary. If you defeated that mechanism, constructing shellcode might be more difficult due to (K)ASLR. With this bug, neither stack canaries nor (K)ASLR are effective defenses against unprivileged programs.
  - scandinavian 7y ago
    Sure, I was just kinda confused that this was the example they presented. I guess for highly targeted attacks, it might be somewhat useful. >Leaking KASLR/stack canary just mean you get 90s level triviality of attacking any stack-overflowing API you can find. It does not seem trivial with this exploit, but maybe I'm just not getting it. With the low accuracy and transfer rate, it seems like a lot of stars need to line up with regards to how the service you attack function.
baybal2 7y ago
Again, I reiterate: it's not humanly possible to make performant, general purpose CPU that is 100% safe from instruction level attacks. Untrusted code execution must go, that's the only way. The genie is out of the bottle now. There will be more and more practical instruction level attacks with each year now.
- NullPrefix 7y ago
  Then it should be written on the product packaging. Big letters.
- heavyset_go 7y ago
  > Untrusted code execution must go, that's the only way. This is how you get corporate rule over what can and can't run on machines you own. Safer architectures can be developed, without handing over control to a third party.
  - baybal2 7y ago
    I don't believe that even a complete comparch-101 in-order, non-pipelined, architecture without branch prediction, and register renaming can be made safe enough. But yes, the industry made an extremely risky bet a decade ago with both virtualisation, and running unsafe Javascript with JIT. It will take many billions for the industry to do a U-turn, and switch back to dedicated servers as a golden standard, and putting a leash on ambitions of browser makers.
    - cpudestw2020 7y ago
      > I don't believe that even a complete comparch-101 in-order, non-pipelined, architecture without branch prediction, and register renaming can be made safe enough. Disagree. You do have to put a lot of work into the process. Formal spec as well as a formal method/simulation. There are certainly a lot of fun things to consider in that, but I don't think it's completely unfeasible. As an aside, one of the things that intrigues me about RISC-V is things such as a formal instruction set spec being openly published [1]. You could apply all sorts of tooling to that before actually creating silicon. > But yes, the industry made an extremely risky bet a decade ago with both virtualisation, and running unsafe Javascript with JIT. Focusing so much on Jitting JS was as bad idea then just like it was now. The entire world of the web is artificially propped up and will probably die the way it should have died when it started: with people frustrated by constant security vulnerabilities enabled by a group of ad companies who don't care about anything but money. > It will take many billions for the industry to do a U-turn, and switch back to dedicated servers as a golden standard, and putting a leash on ambitions of browser makers. WRT Dedicated servers, if anything the industry needs that push now anyway. I've yet to see a 'Real' cost projection on a SaaS 'rewrite'; i.e. if the current thing has been in use 5 years longer than it should have, your cost models should go out 5 years longer than you intend your new solution to exist. Which would be ironic; my pain is in the beancounting side (usually what an org really cares about) yet security will be the more likely scenario. I think the cat is out of the bag for the browser market though. Users have on the whole gotten 're-enclosed' thanks to modern laptops tending towards small eMMC or SSD sizes. But FFS, this sort of thing is the reason WASM scares the daylights out of me. [1] https://github.com/mrLSD/riscv-fs https://github.com/mrLSD/riscv-fs
deleted 7y ago
[deleted]
rurban 7y ago
I've pointed this problem out early last year to libsodium, but they chose to ignore it. My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.
- shakna 7y ago
  > I've pointed this problem out early last year to libsodium, but they chose to ignore it. I'm guessing you're referencing this [0]. libsodium's response that your suggestion wasn't enough seems reasonable, as does their response: > `sodium_memzero` should be considered as best-effort, with reasonable tradeoffs. The documentation for memzero [1] doesn't read like it works 100% of the time, no matter what. It reads like there are tradeoffs involved. > My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs. Your memset_s also doesn't work on big endian, whilst "the so-called 'secure' libs" often do. I'm fine with self-promotion, but don't disparage efforts that have a much larger surface that they deal with, simply because you disagree with the tradeoff they find acceptable. A one-liner isn't enough for that conversation. [0] https://github.com/jedisct1/libsodium/issues/802 https://github.com/jedisct1/libsodium/issues/802 [1] https://download.libsodium.org/doc/memory_management#zeroing-memory https://download.libsodium.org/doc/memory_management#zeroing...
  - rurban 7y ago
    The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance. That time they had no idea about the upcoming cache exploits, they were only apparent to me. So who was right?
    - shakna 7y ago
      > That time they had no idea about the upcoming cache exploits, they were only apparent to me. So who was right? I don't see anything that suggests you did have an idea about "upcoming cache exploits", so I'm afraid I can't say that you were. I saw you mentioning something that would help, but was nowhere near enough, to deal with Spectre, which was then dealt with by microcode, kernels and every other part of the software stack, making attacking libsodium with Spectre something that might not even be possible. > The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance. Not entirely. The main reason is this one: > SPECTRE-like attacks can be conducted during all the time the secret is present, prior to zeroing. The required preconditions and the time window during which a full memory barrier could help, seem to be negligible compared to the actual lifetime of the secret.
ga-vu 7y ago
This appears to be one of the four ZombieLoad/RIDL variations, rather than a new attack: https://zombieloadattack.com/ https://zombieloadattack.com/
- avianes 7y ago
  Yes, this is a RIDL variant called "L1D Eviction Sampling". Bolt the RIDL paper (Addendum 2 B [1]) and the CacheOut paper refer to the CVE-2020-0549: "L1D Eviction Sampling (L1Des) Leakage". But the CacheOut paper describes how to use it in practice and why the intel fix is not sufficient. [1]: https://mdsattacks.com/files/ridl.pdf#page=20 https://mdsattacks.com/files/ridl.pdf#page=20
tuananh 7y ago
it's like all the security researchers are cheering for AMD
eganist 7y ago
Dumb question: authors mention this not being exploitable via JS, but what about WASM?
- johncolanduoni 7y ago
  No, WASM doesn’t expose the ability to generate TSX instructions so it can’t be used to exploit this.

607 points by beefhash 7y ago

Did AMD design their processors with these side channel attacks in mind, or is it a matter of where the security research is focused?

_hl_ 7y ago
> AMD is not affected by CacheOut, as AMD does not offer any feature akin to Intel TSX on their current offering of CPUs. It seems to be down to the notoriously buggy TSX (hardware transactional memory) in Intel CPUs.
- rodgerd 7y ago
  It's interesting that TSX seems to be one of those holy grails that causes more problems than it solves - trying to implement TSX caused, I believe, huge problems for Sunacle's Rock processor team.
  - deleted 7y ago
    [deleted]
eyegor 7y ago
Amd still has almost no server marketshare. This attack specifically leverages tsx, which is an Intel set of transactional extensions to the cpu microcode. Intel has since published microcode updates to enable you to disable tsx.
- topspin 7y ago
  > Amd still has almost no server marketshare. Yet another Intel exclusive side channel vulnerability might help change that. This side channel stuff is terrible for cloud operators. Every time they have to adopt another layer of mitigation some fraction of their capacity disappears in a puff of shame and excuses.
- cosmiccatnap 7y ago
  Not sure you've been keeping up but in 2020 most major server makers have switched or at least offer an epyc varient because the price/performance is better even without Intel's constant security woes
  - eyegor 7y ago
    Yes but most enterprise customers have reacted by buying more Intel chips, because the cost of migrating infrastructure is much greater. Once you're invested deep into the omni-path level interconnects and spend 100k+ on cables alone, buying a few extra blades isn't a huge deal. Speaking as someone who has sat in on meetings where we negotiate with vendors for 1ku pricing. The big migration will happen in about 2-4 years. Typical enterprise schedule is 3-5 year cycles, zen2 launch was 2019.
Symmetry 7y ago
In this case AMD just doesn't support TSX instructions. For previous vulnerabilities with Meltdown I'd guess that AMD just didn't feel they had the engineering resources to do after the fact validation of memory access permissions without architecturally leaking data in some weird corner case. But then along comes Meltdown and it turns out that non-architectural leaks are a thing that can happen and if you try to do after the fact validation you can't prevent them.
makomk 7y ago
Mostly, it seems to be a difference in design philosphy - AMD processors prevent speculative reads of data that shouldn't be accessible almost everywhere, whereas Intel ones allow them pretty much everywhere. This particular attack requires TSX which AMD processors don't have, but I don't think it'd work on AMD processors anyway because they're not missing the security check that Intel ones are. If I remember rightly, there were other now-mitigated exploits for this line fill buffer leak that didn't require TSX. (The one exception is also interesting. AMD processors allow speculative reads past the end of x86 segments and past BOUND instructions, which of course no-one uses these days. This suggests there may have been a deliberate decision to block them in the more important cases.)
- temac 7y ago
  It is known since... forever?, that one should not speculate across security boundaries. This was not enough to avoid Spectre, but this was largely enough to avoid TONS of security vulns Intel is also susceptible to. Somebody messed-up big time. Or from a business point of view did they? Intel current problems are manufacturing and the continuously lower power of their "legacy" processor (except due to manufacturing problems, this "legacy" is still mostly the current one) makes it so that people are buying more. Of course there is AMD back in the game, but the market demand is large enough; plus AMD would have been there anyway, and, in the fiction that Intel did take good parts of the perf hit upfront instead of the secu vulns, as competitive as in the current situation. The people most annoyed are the users. Intel got away by pretending this was not really defects in their product but only new SW tricks that they will help defend against, and their clients just let them say that without much complaint (well, I guess big ones got some rebate...) but security researchers and/or processor designers know very well this is bullshit (see the vulns papers and FAQ) and that they simply fucked-up big time on Meltdown, MDS, etc. I don't care that a few other vendors did some of the same mistakes: they are still mistakes and design flaws, and not even something new. Pretty much the only new shinny thing in this stream of vulns was Spectre and the few variants that appeared quite early on (but NOT Meltdown&co). The rest are design flaws that comes from the "oh not a big deal to leak that potentially privileged data, we will drop anything and trap before any derivative can go out anyway" mentality. Yeah, no, I'm sorry but the funding paper about speculation already told to not do that :/ Either they did not do their homework, or they voluntarily chose to violate the rule.
loeg 7y ago
It is specific to Intel TSX, which should already be disabled due to earlier published MDS vulnerabilities in the same space.
- jdsully 7y ago
  Only the implicit TSX has been disabled. You can still use xbegin/xend/xabort. They had an additional mode that would transparently convert many spinlocks into transactions without code changes - that is now gone.
  - loeg 7y ago
    "Should" as in, I think the earlier vulnerability was damning enough that people /should/ have disabled TSX entirely. If they have not already, they /should/ now.
    - jdsully 7y ago
      TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis. As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventually.
      - cosmiccatnap 7y ago
        That's putting alot of faith in the OS and it's ability to sandbox correctly.
        loeg 7y ago
        Especially when this publication shows that sandboxing correctly isn't possible with TSX.
      - loeg 7y ago

Flockster 7y ago

Is this coordinated with OS providers? It only mentioned that Intel released microcode.

demarcus 7y ago

rgy g

emn13 7y ago

I mean, you gotta appeciate their efforts to make something so technical approachable by the general population, including gems like this in their Q&A: :-D: What is an operating system? An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it. Furthermore, the operating system decides how this hardware is shared by your software, and as such has access to all the data stored in your computer's memory. Thus, it is essential to isolate the operating system from the other programs running on the machine.

cptskippy 7y ago
> An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface So uh... that's a reference to the IME right? Not the user's installed OS.
- chmod775 7y ago
  No they're speaking of the (user installed) OS.
  - cptskippy 7y ago
    I was kind of joking and it's also not explicitly stated, that's just the assumption the reader makes.

loeg 7y ago

Tl;dr: Another Intel TSX async abort side channel. See also Intel's advisory: https://software.intel.com/security-software-guidance/software-guidance/l1d-eviction-sampling https://software.intel.com/security-software-guidance/softwa... (cite 23 in the CacheOut PDF).

annoyingnoob 7y ago

Is disabling Hyper-threading a viable work-around in this case?

sjnu 7y ago
"CacheOut is effective even in the non HyperThreaded scenario, where the victim always runs sequentially to the attacker."

deleted 7y ago

[deleted]

lukestateson 7y ago

Intel got cash in, but we've got cacheout.

jnordwick 7y ago

Before people get all nutty as usual: This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem. The attacker basically needs to be running a binary on the machine (not JS in a browser or anything). The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With noise reduction to enhance recovery, they said it took twice as long - so about 113 byte/minute. It seems to be able to only be able to control the bottom 12-bits of the address to recover (but I didn't fully get why) and require the process to be either reading or writing the data to get it into L1 cache somehow, so just sitting in RAM isn't good enough. attacker still needs to figure out an address (even with ASLR there is still a lot of guessing, and if you have really sensitive data, just move it every second until you wipe it). Interesting, but kind of a non-issue.

jandrese 7y ago
That's a lot of work, but the instant it's in a rootkit everybody will be able to do it. 113 bytes is extracting an AES key from memory in about a minute. It's only really hard and messy for the first guy who implements it, after that it is much easier, albeit still fairly messy. I'm not saying we need to panic, but it's more than a "non-issue".
- scandinavian 7y ago
  >but the instant it's in a rootkit everybody will be able to do it. This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.
  - jandrese 7y ago
    The first feature of a rootkit is to get root access. A userspace kernel-information leak utility would be very useful for this step.
    - scandinavian 7y ago

dmix 7y ago

As someone unfamiliar with creating scientific papers I'm curious if anyone knows what format the citation modal is using? https://imgur.com/a/bem4e8u https://imgur.com/a/bem4e8u Is it for TeX or a common syntax for some publishing platforms to pick up?

detaro 7y ago
Bibtex. Originally for the bibtex tool (which generates bibliographies for (La)TeX documents), but now common with other citation tools too.
wwwhizz 7y ago
That's bibtex, for LaTeX.

scandinavian 7y ago

>CacheOut violates the operating system's privacy by extracting information from it that facilitates other attacks, such as buffer overflow attacks. >More specifically, modern operating systems employ Kernel Address Space Layout Randomization (KASLR) and stack canaries. KASLR randomizes the location of the data structures and code used by the operating system, such that the location is unknown to an attacker. Stack canaries put secret values on the stack to detect whether an attacker has tampered with the stack. CacheOut extracts this information from the operating system, essentially enabling full exploitation via other software attacks, such such as buffer overflow attacks. Can anyone explain this scenario? Is this really a realistic scenario? Do they mean if you have code execution on a system, and want to escalate privileges, you would find another network/socket service that is running on the same system, find an exploit in this service, and then leak the stack canary to allow corrupting the stack? There's often easier ways to defeat the stack canary.

loeg 7y ago
Yes, it's a local privilege escalation issue, i.e. you must have local code execution first. Leaking KASLR/stack canary just mean you get 90s level triviality of attacking any stack-overflowing API you can find. Without this bug, if you found a stack-overflow you could trigger from your local unprivileged code, the target would likely detect the overflow due to the canary. If you defeated that mechanism, constructing shellcode might be more difficult due to (K)ASLR. With this bug, neither stack canaries nor (K)ASLR are effective defenses against unprivileged programs.
- scandinavian 7y ago
  Sure, I was just kinda confused that this was the example they presented. I guess for highly targeted attacks, it might be somewhat useful. >Leaking KASLR/stack canary just mean you get 90s level triviality of attacking any stack-overflowing API you can find. It does not seem trivial with this exploit, but maybe I'm just not getting it. With the low accuracy and transfer rate, it seems like a lot of stars need to line up with regards to how the service you attack function.

baybal2 7y ago

Again, I reiterate: it's not humanly possible to make performant, general purpose CPU that is 100% safe from instruction level attacks. Untrusted code execution must go, that's the only way. The genie is out of the bottle now. There will be more and more practical instruction level attacks with each year now.

NullPrefix 7y ago
Then it should be written on the product packaging. Big letters.
heavyset_go 7y ago
> Untrusted code execution must go, that's the only way. This is how you get corporate rule over what can and can't run on machines you own. Safer architectures can be developed, without handing over control to a third party.
- baybal2 7y ago
  I don't believe that even a complete comparch-101 in-order, non-pipelined, architecture without branch prediction, and register renaming can be made safe enough. But yes, the industry made an extremely risky bet a decade ago with both virtualisation, and running unsafe Javascript with JIT. It will take many billions for the industry to do a U-turn, and switch back to dedicated servers as a golden standard, and putting a leash on ambitions of browser makers.
  - cpudestw2020 7y ago
    > I don't believe that even a complete comparch-101 in-order, non-pipelined, architecture without branch prediction, and register renaming can be made safe enough. Disagree. You do have to put a lot of work into the process. Formal spec as well as a formal method/simulation. There are certainly a lot of fun things to consider in that, but I don't think it's completely unfeasible. As an aside, one of the things that intrigues me about RISC-V is things such as a formal instruction set spec being openly published [1]. You could apply all sorts of tooling to that before actually creating silicon. > But yes, the industry made an extremely risky bet a decade ago with both virtualisation, and running unsafe Javascript with JIT. Focusing so much on Jitting JS was as bad idea then just like it was now. The entire world of the web is artificially propped up and will probably die the way it should have died when it started: with people frustrated by constant security vulnerabilities enabled by a group of ad companies who don't care about anything but money. > It will take many billions for the industry to do a U-turn, and switch back to dedicated servers as a golden standard, and putting a leash on ambitions of browser makers. WRT Dedicated servers, if anything the industry needs that push now anyway. I've yet to see a 'Real' cost projection on a SaaS 'rewrite'; i.e. if the current thing has been in use 5 years longer than it should have, your cost models should go out 5 years longer than you intend your new solution to exist. Which would be ironic; my pain is in the beancounting side (usually what an org really cares about) yet security will be the more likely scenario. I think the cat is out of the bag for the browser market though. Users have on the whole gotten 're-enclosed' thanks to modern laptops tending towards small eMMC or SSD sizes. But FFS, this sort of thing is the reason WASM scares the daylights out of me. [1] https://github.com/mrLSD/riscv-fs https://github.com/mrLSD/riscv-fs

deleted 7y ago

[deleted]

rurban 7y ago

I've pointed this problem out early last year to libsodium, but they chose to ignore it. My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.

shakna 7y ago
> I've pointed this problem out early last year to libsodium, but they chose to ignore it. I'm guessing you're referencing this [0]. libsodium's response that your suggestion wasn't enough seems reasonable, as does their response: > `sodium_memzero` should be considered as best-effort, with reasonable tradeoffs. The documentation for memzero [1] doesn't read like it works 100% of the time, no matter what. It reads like there are tradeoffs involved. > My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs. Your memset_s also doesn't work on big endian, whilst "the so-called 'secure' libs" often do. I'm fine with self-promotion, but don't disparage efforts that have a much larger surface that they deal with, simply because you disagree with the tradeoff they find acceptable. A one-liner isn't enough for that conversation. [0] https://github.com/jedisct1/libsodium/issues/802 https://github.com/jedisct1/libsodium/issues/802 [1] https://download.libsodium.org/doc/memory_management#zeroing-memory https://download.libsodium.org/doc/memory_management#zeroing...
- rurban 7y ago
  The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance. That time they had no idea about the upcoming cache exploits, they were only apparent to me. So who was right?
  - shakna 7y ago
    > That time they had no idea about the upcoming cache exploits, they were only apparent to me. So who was right? I don't see anything that suggests you did have an idea about "upcoming cache exploits", so I'm afraid I can't say that you were. I saw you mentioning something that would help, but was nowhere near enough, to deal with Spectre, which was then dealt with by microcode, kernels and every other part of the software stack, making attacking libsodium with Spectre something that might not even be possible. > The tradeoff they are talking about is leaving secrets in the cache, because mb(lb) is slow. This is not acceptable for security, only for performance. Not entirely. The main reason is this one: > SPECTRE-like attacks can be conducted during all the time the secret is present, prior to zeroing. The required preconditions and the time window during which a full memory barrier could help, seem to be negligible compared to the actual lifetime of the secret.

ga-vu 7y ago

This appears to be one of the four ZombieLoad/RIDL variations, rather than a new attack: https://zombieloadattack.com/ https://zombieloadattack.com/

avianes 7y ago
Yes, this is a RIDL variant called "L1D Eviction Sampling". Bolt the RIDL paper (Addendum 2 B [1]) and the CacheOut paper refer to the CVE-2020-0549: "L1D Eviction Sampling (L1Des) Leakage". But the CacheOut paper describes how to use it in practice and why the intel fix is not sufficient. [1]: https://mdsattacks.com/files/ridl.pdf#page=20 https://mdsattacks.com/files/ridl.pdf#page=20

tuananh 7y ago

it's like all the security researchers are cheering for AMD

eganist 7y ago

Dumb question: authors mention this not being exploitable via JS, but what about WASM?

johncolanduoni 7y ago
No, WASM doesn’t expose the ability to generate TSX instructions so it can’t be used to exploit this.