41–50 of 137 posts
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.
>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 c…
Earlier quoted context omitted.
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 eventual…
It is dangerous to treat the security domain as app-to-app instead of whole-machine given the scope of vulnerability. If your TSX workload runs on dedicated machines and/or you're ok with the reduction in kernel defenses, sure, enable it. But the default should be "off." Scaling workloads does not require transactional memory and certainly doesn't require a vulnerable implementation of it. HTM might be the easiest wa…
TSX brings hardware supported optimistic locking and breaks the latency imposed by MESI and related protocols in use today. Of course its great if you can get away with no synchronization at all - but then you might as well just use a GPU. TSX helps with those non-trivially parallelized problems that are still best performed on a CPU.
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.
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.
>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 c…
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…
>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.
Earlier quoted context omitted.
It is dangerous to treat the security domain as app-to-app instead of whole-machine given the scope of vulnerability. If your TSX workload runs on dedicated machines and/or you're ok with the reduction in kernel defenses, sure, enable it. But the default should be "off." Scaling workloads does not require transactional memory and certainly doesn't require a vulnerable implementation of it. HTM might be the easiest wa…
The problem TSX is attempting to address is bus traffic from those exact lock instructions you mention. These work OK for the relatively small core counts of today but won't scale to hundreds of cores. TSX brings hardware supported optimistic locking and breaks the latency imposed by MESI and related protocols in use today. Of course its great if you can get away with no synchronization at all - but then you might as…
Obviously many workloads require some coordination, but often something as trivial as allocating one of a given resource per CPU is sufficient to avoid most contention even on 100s of CPU core machines. Profile; improve. The same is required with HTM.
Regardless of your thoughts on HTM and scaling technology, TSX is broken from a security standpoint, which is the primary subject of the fine article. HTM != TSX.
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.
> 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.
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.
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 no…
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".
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.
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.
What you see here is yet another attack on a relatively unused Intel-only x86 extension.
The bigger problem is that Unixes and Windows are pretty bad at sandboxing syscalls by default.
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 no…
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.