2 ms·

the new AMD attack effectively breaks KASLR (the "metadata" that the attack reveals is page table layouts) and AMD has announced they're not going to patch it.

by paulmd 7y ago

the new AMD attack effectively breaks KASLR (the "metadata" that the attack reveals is page table layouts) and AMD has announced they're not going to patch it. itself it's not a problem but if you pair it with something else it destroys a major line of defense against that something else. AMD is still architecturally vulnerable to some variants of SPECTRE, they just consider it "hard to exploit", but they do recommend you run KASLR to harden against it. Well, so much for that.

AnthonyMouse 7y ago
Wasn't KASLR (really KPTI, originally a KASLR hardening technique) a mitigation against Meltdown, which AMD isn't vulnerable to, rather than Spectre?
- chousuke 7y ago
  As far as I understand it, KASLR is a general hardening technique to shuffle the kernel address space so that it's harder for attackers to use vulnerabilities successfully to attack the kernel. I don't think it's specifically for Meltdown.
  - AnthonyMouse 7y ago
    ASLR is a general technique to try to prevent memory corruption vulnerabilities from being turned into code execution when the attacker can determine the location of already-existing code in memory and use the memory corruption to cause program flow to jump to it. It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout. KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels: http://www.cs.ucr.edu/~nael/pubs/micro16.pdf http://www.cs.ucr.edu/~nael/pubs/micro16.pdf Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.

by paulmd 7y ago

AnthonyMouse 7y ago

Wasn't KASLR (really KPTI, originally a KASLR hardening technique) a mitigation against Meltdown, which AMD isn't vulnerable to, rather than Spectre?

chousuke 7y ago
As far as I understand it, KASLR is a general hardening technique to shuffle the kernel address space so that it's harder for attackers to use vulnerabilities successfully to attack the kernel. I don't think it's specifically for Meltdown.
- AnthonyMouse 7y ago
  ASLR is a general technique to try to prevent memory corruption vulnerabilities from being turned into code execution when the attacker can determine the location of already-existing code in memory and use the memory corruption to cause program flow to jump to it. It works pretty well against remote code execution because it's hard for an attacker who can't already execute arbitrary code on your machine to determine the address space layout. In principle it can also be used to protect the kernel against user processes, but that's much harder because a process that can already execute arbitrary user code on the same machine can use a variety of side channel attacks like this to determine the kernel address space layout. KPTI was originally proposed to close some of those side channels, but it's kind of expensive. It only got enabled by default (on Intel) because it also mitigates Meltdown, which is a much worse problem. It also doesn't handle all of the side channels: http://www.cs.ucr.edu/~nael/pubs/micro16.pdf http://www.cs.ucr.edu/~nael/pubs/micro16.pdf Meanwhile, if some kernel code is vulnerable to Spectre (i.e. the Spectre mitigations are not implemented properly), it could allow the attacker to read arbitrary kernel memory. That is obviously very bad, but the ability to read arbitrary kernel memory implies that the attacker can already determine the kernel address space layout, so I'm not sure how KASLR would be helpful in mitigating that.