7 ms·

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 basica

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
      Okay, we have differing definitions of what a rootkit is it seems.
      - foota 7y ago
        They mean in the implementation of a rootkit.
- jnordwick 7y ago
  we have yet to even find Specter in a kit, this will never see the light of day, especially since it is so easy to avoid (turn TSX off). You also, don't get to extract constantly. You only get a shot when the data is in the LFB, so the program needs to be actively reading or writing it to keep it moving back and forth from L1 and L2, at least that is the way I read the paper.
- userbinator 7y ago
  113 bytes is extracting an AES key from memory in about a minute. How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demonstrate something flashy like "we read a key/password/secret/something important from memory in a few minutes" while conveniently ignoring to mention the countless hours spent aligning everything just right so they could show off the one "magic trick". In a lot of the cases there's barely even any control over where it reads. Every time something like this comes up, I feel compelled to post some bytes from somewhere random in the memory of a random process on my machine to show just how much I care; here you go: E8 7F 00 00 00 A1 64 30 40 00 89 45 D8 8D 45 D8 C4 20 00 00-CE 20 00 00-D8 20 00 00-E2 20 00 00 F8 20 00 00-00 21 00 00-0E 21 00 00-16 21 00 00 26 21 00 00-36 21 00 00-42 21 00 00-56 21 00 00 66 21 00 00-76 21 00 00-84 21 00 00-96 21 00 00 AA 21 00 00-00 00 00 00-FF FF FF FF-B4 16 40 00 C8 16 40 00-7C 20 00 00-00 00 00 00-00 00 00 00 EC 20 00 00-00 20 00 00-00 00 00 00-00 00 00 00 Of course if you are being targeted then the concern may go up, but I still think that attackers would have lower-hanging-fruit than this, seeing as setting up one of these reads to get one secret would itself require such intimate knowledge of your machine's configuration and state that they probably already know what they want.
  - slovenlyrobot 7y ago
    > How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? I don't mean to understate the difficulty of the task, but I've also seen probably tens of repros by now that use intimate knowledge of e.g. the kernel page allocator and known post-boot state of e.g. a firmware image flashed on millions of devices to drastically cut down the search space
  - zelon88 7y ago
    What is it that programmers do? They automate complex tasks that take humans considerable effort. If a university can accomplish this task with their funding and no urgent incentive, what is the nation state actor doing with their enormous budget?
Tuna-Fish 7y ago
> 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) 2^12 = 4096, or the x86 page size in bytes.
- cesarb 7y ago
  And as for why the page size is relevant for the L1 cache: Intel (and AMD, and most other modern CPUs) use a VIPT (Virtual Indexed Physical Tagged) L1 cache, where the virtual address (before the page table translation) is used to index the cache (this is faster since it can be done in parallel with the TLB lookup to get the physical address). To prevent the confusing situation where the same physical address has more than one index in the cache, only the bits of the address which do not change between the virtual address and the physical address can be used; these are the bits which correspond to the offset within the page. (As an aside, this also limits the size of the L1 cache, which is why it hasn't grown much despite the L2 and L3 cache growing a lot; an 8-way set-associative VIPT cache with a 4KiB page size is limited to 32KiB, absent tricks like page coloring. Perhaps this will change if 64-bit ARM servers become popular, since they can only address the largest amount of memory when using a 64KiB page size, and this would make enterprise distributions default to that page size.)
  - sitkack 7y ago
    Does this mean we could see 16x larger L1?
    - ghettoimp 7y ago
      All of hardware is tradeoffs. A huge L1 would be slower to access. You might end up slowing down all memory accesses by a cycle (or more) just for accessing the large cache. You also have to find some place to put the thing in your floorplan, and route everything else around it. This may result in timing challenges in other parts of the chip, which might require additional delay to resolve. A huge L1 would take up more space. This would increase area, reduce yield, and increase cost. Since in a multi-core chip each core has its own L1, you will have to pay this cost multiple times. Also, L2 caches are typically inclusive, so you would potentially need a much larger L2 to be able to accommodate all the extra information in these L1s. These tradeoffs have to be studied with simulated experiments to make the right call. For programs with huge working set, maybe the added latency pays for itself because you have have fewer cache misses. For programs with good locality, maybe you end up losing performance. Maybe you save power by reducing misses, or maybe you waste more power because the cache is using more power. Maybe it's an insignificant area increase, or maybe it completely blows up your budget.
FisDugthop 7y ago
By your own numbers, this could translate to a 30-second AES key exfiltration in the cloud. This isn't a non-issue, even if you personally aren't affected.
- jnordwick 7y ago
  you have to find the address first, which is a lot of rummaging around. you aren't just handed it. that is going to quite a bit, especially the program build any security measures in (eg, allocate at a random address). good luck with that.
  - sitkack 7y ago
    Spread the key over a whole page with fec, implement the key recovery using non saved registers. Would be nice to avoid pre-emption and avoid leaking regs to ram. Perhaps last step could use avx to run a permutation.
  - DoctorOetker 7y ago
    it's easy to say vulnerabilities don't matter... when responsible disclosure results in fixes for those specific relevant systems for which actual executable Proof of Concepts were designed. The authors have the skill and knowhow to do this for new systems, and the surrounding knowhow and skills are not gained by merely reading the whitepaper that focusses on the exact nature of the side-channel. Similarily a paper from the field of say physics, will not hold your hand by having a huge appendix filled with the physics courses, exercises, ... the authors enjoyed as a student...
strstr 7y ago
How do you disable TSX? I don't see a control register flag or an MSR.
- GranPC 7y ago
  MSR IA32_TSX_CTRL, introduced with a microcode update a while back.
  - strstr 7y ago
    Wow, it's not even in the SDM. Only docs I can find are: https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort https://software.intel.com/security-software-guidance/insigh... Glad it's possible to do this in virt now: used to be impossible to disable TSX (you could avoid advertising it via cpuid, but you couldn't actually prevent usage of the instructions).
guug 7y ago
The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I expect more companies to follow suit.
- ehvatum 7y ago
  At the level where large, security-centric organizations make decisions, these instances argue for getting AMD in the door like nothing else that I can recall. So, it's a good time for AMD to have such performant hardware and a process advantage. If it stays this way for a decade, I'll be able to put in a PO for AMD hardware...
  - greyhair 7y ago
    The problem is, these leaky cache issues come from 'performant' hardware. It is the pipeline optimization that leads to the side channel. There are cache architectures (such as pseudo random replacement) that are much more difficult to perform side channel attacks on, but have slightly lower performance. Intel's problem has been its relentless pursuit of per clock performance, and that has led to some of these side channel attacks. Cache coherency on multi-core is hard. My guess is that if the market share of Intel and AMD were swapped, you would see similar cache attacks on AMD.
- ngneer 7y ago
  When the market rewards secure design, you can make that complaint. Since the market does not reward secure design, expect investments in security to be commensurate. You cannot have it both ways.
  - guug 7y ago
    Not a complaint but merely stating the obvious.
  - 7y ago
tomThom 7y ago
"all nutty as usual" Nice that you get away with it. I assume you're being paid?
chaboud 7y ago
"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)" That looks conspicuously like the load/store port address aliasing size (look up "4K Aliasing"), which can be used to stall data availability while the conflict is resolved. I'll read up on this particular one, but there's a growing family of vulnerabilities with 12-bit address aliasing in their toolbox.
- labawi 7y ago
  Reads data (indirectly) from cache - you can select cache slot. It is on you to make sure something interesting is in the cache, but if you can make your target execute, 12-bits is fairly good selectivity.
ec109685 7y ago
The paper talks about how in a VM environment, this attack allows reading the hypervisor’s memory, and that public clouds put in mitigations based on the early disclosure to them. That feels like a big 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
    Okay, we have differing definitions of what a rootkit is it seems.
    - foota 7y ago
      They mean in the implementation of a rootkit.
jnordwick 7y ago
we have yet to even find Specter in a kit, this will never see the light of day, especially since it is so easy to avoid (turn TSX off). You also, don't get to extract constantly. You only get a shot when the data is in the LFB, so the program needs to be actively reading or writing it to keep it moving back and forth from L1 and L2, at least that is the way I read the paper.
userbinator 7y ago
113 bytes is extracting an AES key from memory in about a minute. How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demonstrate something flashy like "we read a key/password/secret/something important from memory in a few minutes" while conveniently ignoring to mention the countless hours spent aligning everything just right so they could show off the one "magic trick". In a lot of the cases there's barely even any control over where it reads. Every time something like this comes up, I feel compelled to post some bytes from somewhere random in the memory of a random process on my machine to show just how much I care; here you go: E8 7F 00 00 00 A1 64 30 40 00 89 45 D8 8D 45 D8 C4 20 00 00-CE 20 00 00-D8 20 00 00-E2 20 00 00 F8 20 00 00-00 21 00 00-0E 21 00 00-16 21 00 00 26 21 00 00-36 21 00 00-42 21 00 00-56 21 00 00 66 21 00 00-76 21 00 00-84 21 00 00-96 21 00 00 AA 21 00 00-00 00 00 00-FF FF FF FF-B4 16 40 00 C8 16 40 00-7C 20 00 00-00 00 00 00-00 00 00 00 EC 20 00 00-00 20 00 00-00 00 00 00-00 00 00 00 Of course if you are being targeted then the concern may go up, but I still think that attackers would have lower-hanging-fruit than this, seeing as setting up one of these reads to get one secret would itself require such intimate knowledge of your machine's configuration and state that they probably already know what they want.
- slovenlyrobot 7y ago
  > How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? I don't mean to understate the difficulty of the task, but I've also seen probably tens of repros by now that use intimate knowledge of e.g. the kernel page allocator and known post-boot state of e.g. a firmware image flashed on millions of devices to drastically cut down the search space
- zelon88 7y ago
  What is it that programmers do? They automate complex tasks that take humans considerable effort. If a university can accomplish this task with their funding and no urgent incentive, what is the nation state actor doing with their enormous budget?

Tuna-Fish 7y ago

> 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) 2^12 = 4096, or the x86 page size in bytes.

cesarb 7y ago
And as for why the page size is relevant for the L1 cache: Intel (and AMD, and most other modern CPUs) use a VIPT (Virtual Indexed Physical Tagged) L1 cache, where the virtual address (before the page table translation) is used to index the cache (this is faster since it can be done in parallel with the TLB lookup to get the physical address). To prevent the confusing situation where the same physical address has more than one index in the cache, only the bits of the address which do not change between the virtual address and the physical address can be used; these are the bits which correspond to the offset within the page. (As an aside, this also limits the size of the L1 cache, which is why it hasn't grown much despite the L2 and L3 cache growing a lot; an 8-way set-associative VIPT cache with a 4KiB page size is limited to 32KiB, absent tricks like page coloring. Perhaps this will change if 64-bit ARM servers become popular, since they can only address the largest amount of memory when using a 64KiB page size, and this would make enterprise distributions default to that page size.)
- sitkack 7y ago
  Does this mean we could see 16x larger L1?
  - ghettoimp 7y ago
    All of hardware is tradeoffs. A huge L1 would be slower to access. You might end up slowing down all memory accesses by a cycle (or more) just for accessing the large cache. You also have to find some place to put the thing in your floorplan, and route everything else around it. This may result in timing challenges in other parts of the chip, which might require additional delay to resolve. A huge L1 would take up more space. This would increase area, reduce yield, and increase cost. Since in a multi-core chip each core has its own L1, you will have to pay this cost multiple times. Also, L2 caches are typically inclusive, so you would potentially need a much larger L2 to be able to accommodate all the extra information in these L1s. These tradeoffs have to be studied with simulated experiments to make the right call. For programs with huge working set, maybe the added latency pays for itself because you have have fewer cache misses. For programs with good locality, maybe you end up losing performance. Maybe you save power by reducing misses, or maybe you waste more power because the cache is using more power. Maybe it's an insignificant area increase, or maybe it completely blows up your budget.

FisDugthop 7y ago

By your own numbers, this could translate to a 30-second AES key exfiltration in the cloud. This isn't a non-issue, even if you personally aren't affected.

jnordwick 7y ago
you have to find the address first, which is a lot of rummaging around. you aren't just handed it. that is going to quite a bit, especially the program build any security measures in (eg, allocate at a random address). good luck with that.
- sitkack 7y ago
  Spread the key over a whole page with fec, implement the key recovery using non saved registers. Would be nice to avoid pre-emption and avoid leaking regs to ram. Perhaps last step could use avx to run a permutation.
- DoctorOetker 7y ago
  it's easy to say vulnerabilities don't matter... when responsible disclosure results in fixes for those specific relevant systems for which actual executable Proof of Concepts were designed. The authors have the skill and knowhow to do this for new systems, and the surrounding knowhow and skills are not gained by merely reading the whitepaper that focusses on the exact nature of the side-channel. Similarily a paper from the field of say physics, will not hold your hand by having a huge appendix filled with the physics courses, exercises, ... the authors enjoyed as a student...

strstr 7y ago

How do you disable TSX? I don't see a control register flag or an MSR.

GranPC 7y ago
MSR IA32_TSX_CTRL, introduced with a microcode update a while back.
- strstr 7y ago
  Wow, it's not even in the SDM. Only docs I can find are: https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort https://software.intel.com/security-software-guidance/insigh... Glad it's possible to do this in virt now: used to be impossible to disable TSX (you could avoid advertising it via cpuid, but you couldn't actually prevent usage of the instructions).

guug 7y ago

The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I expect more companies to follow suit.

ehvatum 7y ago
At the level where large, security-centric organizations make decisions, these instances argue for getting AMD in the door like nothing else that I can recall. So, it's a good time for AMD to have such performant hardware and a process advantage. If it stays this way for a decade, I'll be able to put in a PO for AMD hardware...
- greyhair 7y ago
  The problem is, these leaky cache issues come from 'performant' hardware. It is the pipeline optimization that leads to the side channel. There are cache architectures (such as pseudo random replacement) that are much more difficult to perform side channel attacks on, but have slightly lower performance. Intel's problem has been its relentless pursuit of per clock performance, and that has led to some of these side channel attacks. Cache coherency on multi-core is hard. My guess is that if the market share of Intel and AMD were swapped, you would see similar cache attacks on AMD.
ngneer 7y ago
When the market rewards secure design, you can make that complaint. Since the market does not reward secure design, expect investments in security to be commensurate. You cannot have it both ways.
- guug 7y ago
  Not a complaint but merely stating the obvious.
- 7y ago

tomThom 7y ago

"all nutty as usual" Nice that you get away with it. I assume you're being paid?

chaboud 7y ago

"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)" That looks conspicuously like the load/store port address aliasing size (look up "4K Aliasing"), which can be used to stall data availability while the conflict is resolved. I'll read up on this particular one, but there's a growing family of vulnerabilities with 12-bit address aliasing in their toolbox.

labawi 7y ago
Reads data (indirectly) from cache - you can select cache slot. It is on you to make sure something interesting is in the cache, but if you can make your target execute, 12-bits is fairly good selectivity.

ec109685 7y ago

The paper talks about how in a VM environment, this attack allows reading the hypervisor’s memory, and that public clouds put in mitigations based on the early disclosure to them. That feels like a big issue.