by the way, that PoC was intense. Makes you wonder if the NSA knew about it all along :)
Colin Percival found a very similar issue with Intel's implementation of SMT on the Pentium 4 in 2005: http://www.daemonology.net/papers/htt.pdf
So the general idea of using timing attacks against the cache to leak memory has been known for at least that long.
In 2016, two researchers from the University of Graz gave a talk at the 33C3, where they showed that they had managed to use that technique to establish a covert channel between VMs running on the same physical host. They even managed to run ssh over than channel. https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wron...
In light of that, I would be surprised if the NSA had not known about this.
Unlike "vanilla" cache-timing attacks:
* Meltdown and Spectre involve transient instructions, instructions that from the perspective of the ISA never actually run.
* Spectre v1 undermines the entire concept of a bounds check; pre-Spectre, virtually every program that runs on a computer is riddled with buffer overreads. It's about as big a revelation as Lopatic's HPUX stack overflow was in 1995. There might not be a clean fix! Load fences after ever bounds check?
* Spectre v2 goes even further than that, and allows attackers to literally pick the locations target programs will execute from. Try to get your head around that: we pay tens of thousands of dollars for vulnerabilities that allow us to return to arbitrary program locations, and Spectre's branch target injection technique lets us use the hardware to, in some sense, do that to any program. And look at the fix to that: retpolines? Compilers can't directly emit indirect jumps anymore?
It's good that we're all recognizing how big a problem cache timing is. It was for sure not taken as seriously as it should have been outside of a subset of cryptographers. But Meltdown and Spectre are not simply cache timing vulnerabilities; they're a re-imagining of what you can do to a modern ISA by targeting the microarchitecture.
Call me a tinfoil hat conspiracist but the only rational explanation I can find of IBM POWER and z CPUs still vulnerable to Spectre is the NSA forcing IBM not to fix it. I read somewhere that the z196 had three magnitudes more validation routines than the Intel Core at that time. It's extremely hard to believe they haven't caught this.
Former head of TAO Rob Joyce said "NSA did not know about the flaw, has not exploited it and certainly the U.S. government would never put a major company like Intel in a position of risk like this to try to hold open a vulnerability." [1]
Who knows if that's true or not, though. Certainly the U.S. government has done exactly that many times in the past (like with heartbleed).
[1]: https://www.washingtonpost.com/business/technology/huge-secu...
The claim that "the U.S. government would never put a major company like Intel in a position of risk" is obviously bullshit. TAO's job necessarily involves exposing companies both in the US and overseas to that kind of risk on a daily basis.
> U.S. government would never put a major company like Intel in a position of risk like this to try to hold open a vulnerability." [1]
They subverted the Dual_EC_DRBG standardization process. Had they not been caught and the algorithm ended up on more devices they would be hurting not just major companies but whole industries.
Also for reference: https://en.wikipedia.org/wiki/Bullrun_(decryption_program)
Note that it talks about "the flaw", whereas Intel claims it isn't a "flaw". So could be another instance of overly specific denial. "We didn't exploit this flaw, because it isn't a flaw. We exploited the processor operating as designed".
</tinfoil>
The US government sure. The NSA? They sure would as this statement shows.
I believe one solution would be to put permission checks before the memory access, which would add serialized latency to all memory access. Another would be to have the speculative execution system flush cache lines that were loaded but ultimately ignored, which would be complex but probably not be as much of a speed hit.
(edit: yeah, a simple "flush" is insufficient, it would have to be closer to an isolated transaction with rollback of the access's effects on the cache system.)
I don't see why that would have to add latency to all (or any) memory access. The addresses generated by programs (except in real mode, when everything has access to everything anyway so we don't care about these issues then) are virtual addresses, so they have to be translated to get the actual memory address.
The permission information for a page is stored in the same place as the physical address translation information for that page. The processor fetches it at the same time it fethes the physical base address of the page.
They should also have the current permission level of the program readily available. That should be enough to let them do something about Meltdown without any performance impact. They could do something as simple as if the page is a supervisor page and the CPU is not in supervisor mode don't actually read the memory. Just substitute fixed data.
Note that AMD is reportedly not affected by Meltdown. From what I've read that is because they in fact do the protection check before trying to access the memory, even during speculation, and they don't suffer any performance loss from that.
Note that since Meltdown is only an issue when the kernel memory read is on the path that does NOT become the real path (because if it becomes the real path, then the program is going to get a fault anyway for an illegal memory access), the replacing of the memory accesses with fixed data cannot harm any legitimate program.
Spectre is going to be the hard one for the CPU people to fix, I think. I think they may have to offer hardware memory protection features that can be used in user mode code to protect parts of that code from other parts of that code, so that things that want to run untrusted code in a sandbox in their own processes can do so in a separate address space that is protected similar to the way kernel space is protected from user space.
It may be more complicated than that, though, because Spectre also does some freaky things that take advantage of branch prediction information not being isolated between processors. I haven't read enough to understand the implications of that. I don't know if that can be defeated just be better memory protection enforcement.
I guess compilers could pad that out with noops to postpone the read until the previous commit is done if they know the design of the pipeline they are targetting. But generically optimized code would take a terrible hit from this.
* https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910)
Edit: Probably the 'extreme circumstances' bit mentioned in https://news.ycombinator.com/item?id=16108434
> Project Member Comment 4 by hawkes@google.com, Aug 7
> Labels: Deadline-Grace
It looks like Ben Hawkes would know the reason why, but I think the speculation that this grace period was done due to the scope and severity of this finding is likely correct.
from: http://xlab.tencent.com/special/spectre/spectre_check.html
https://twitter.com/mlqxyz/status/950378419073712129
(I personally do not have a twitter account but was looking for the paper and stumbled upon it, glad I did!)
To test, set CONFIG_PAGE_TABLE_ISOLATION=y. That is:
sudo apt-get build-dep linux
sudo apt-get install gcc-6-plugin-dev libelf-dev libncurses5-dev
cd /usr/src
wget https://git.kernel.org/torvalds/t/linux-4.15-rc7.tar.gz
tar -xvf linux-4.15-rc7.tar.gz
cd linux-4.15-rc7
cp /boot/config-`uname -r` .config
make CONFIG_PAGE_TABLE_ISOLATION=y deb-pkgTrying the kaslr program right now, it's not figuring out the direct map offset and it's probably already been a minute or two. So it works?
EDIT: After 40 minutes, it has attempted all addresses and did not find the direct map offset.
I think that the page isolation slows it down, even if it doesn't completely eliminate it.
The second test had something like a 0.05% success rate on my PC, and took over an hour to get a few dozen values read.
After trying this with the new kernel, I started up an AWS instance and ran the tests there. The first test (KASLR) succeeded within a few seconds, and the second test had a 100% success rate (read 1575 values in a few seconds).
This code is from TU Graz; I assume this is from Daniel Gruss's team, who participated in the original research.
I understood the "secret" data stays in the caches for a very short time until the branch prediction is rolled back, which makes this a timing attack but don't get how you actually read it.
EDIT
So perhaps someone can ELI5 me "4.2 Building a Covert Channel" [1] from the Meltdown paper which is what I didn't understand.
if(false_but_predictive_execution_cant_tell)
{
int i = (int)*protected_kernel_memory_byte;
load_page(i, my_pages);
}
My understanding is that the problem is that the data in the cache _isn't_ rolled back.
You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data e.g. fetch((secret_bit * 128) + offset) [1] so if secret_bit is 0 it's fetched the memory at offset into the cache, if secret_bit is 1 it's fetched the memory at offset+128 into the cache.
After the speculative work is rolled back, the data that it fetched into the cache still remains. You then time how long it takes to fetch offset and offset+128. If offset comes back quickly, secret_bit was 0. If offset+128 comes back quickly, secret_bit was 1.
_That_ is where the timing attack part comes in: "timing attack" refers to using measurements of how long something took to glean information, not that you need to do it quickly.
[1] In reality you do it on the byte level and use &, but I wanted to keep it to guessing a single bit to make it simpler.
I was under the impression that there is no interface to read data from the CPU caches and that the cache is managed by the CPU itself only.
The covert channel consists of a "sender" and a "receiver". The receiver can't extract contents of L1 cache, but it can detect which pages were in cache by timing differences. So the sender encodes the secret data by fetching particular addresses calculated so that the receiver can afterwards recover the secret by verifying which page(s) were in cache.
In Meltdown attack, the sender consists of instructions controlled by you - e.g. x=memory_you_shouldn't_access; y=array[1000x] - and after an Intel processor notices that you shouldn't access that memory and rolls back the instructions (invalidating y and x), the 1000x location was already pulled to cache, and you can check - is array[1000] cached? is array[2000] cached? is array[142000] cached? to determine x.
In Spectre attack, the sender consists of code in the vulnerable application that happens to contain similar instructions. Spectre attack means that if your application anywhere contains code like if (parameter is in bounds) {x=array1[parameter]} (...possibly some other code...) y=array2[x], then any attacker that (a) runs on the same CPU and (b) can manipulate the parameter somehow can trick this code to process the path "protected" by 'if' and reveal random memory out of bounds of that array1. The difference from ordinary buffer overflow bugs is that code like that is normal, common and (in general) not a bug, since the instructions "don't get executed", and the vulnerability persists even if you validate all input.
I thought the recent kernel-/firmware-/ucode-patches should have prevented that.
EDIT: The other demos fail, though, as they should. sigh
EDIT: For some reason, demo #2 (breaking kaslr) works on my Ryzen machine, but not on the others. :-?
>"reports this morning that Intel chief executive Brian Krzanich made $25 million from selling Intel stock in late November, when he knew about the bugs, but before they were made public" (https://qz.com/1171391/the-intel-intc-meltdown-bug-is-hittin...)
I assume he's supposed to now be prosecuted, that sounds like insider dealing? [I'd like to say "will be prosecuted" but ...]
First, the "Direct physical map offset" comes back wrong in Demo #2. Second, if I use the correct offset, the reliability is around 0.5% in Demo #3 - but not consistently... after a few tries it did come back with >99%
Basically, screw up your caches continuously.
Does it mean a hacked IOS/Android app can also (in theory) sniff the password enter in system dialog as demo in the video?
Realtime password input - https://www.youtube.com/watch?v=yTpXqyRYcBMI've only seen two implementations: one based just doing the access to kernel memory, catching the SIGSEGV, and then probing the cache. Obviously that could be closed by the kernel flushing the cache prior handing control back t user space after SIGSEGV. Doing that would have no impact on normal programs.
The second is by exploiting a bug in Intel's transactional memory implementation. But I assume Intel could turn that feature off as they have done so in the past. Since bugger all programs use it doing so wouldn't have much impact.
Which means the approach being take now is done purely to kill the speculative branch method (ie, Spectre pointed at the kernel). The authors say it should work, but also say they could not make it work. I haven't been able to find working any PoC for my Linux machines.
So my question is: is there any out there?
#2 - physical memory leak - https://www.youtube.com/watch?v=kn0FopiF16o
the videos aren't very long, someone should compress it to <10mb as an animated gif and do a pull request to put it in the README
There's no need to use an awful format like gif, just embed an efficiently compressed video file with the <video> tag
You can force values from any memory to affect the cache in a predictable manner which enables you to read all physical memory. See https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf
We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
Not only is L1D tiny, but stuff like prefetch doesn't touch it. So how exactly do you force any memory into L1D cache unless, like in all the examples we have seen, the victim program is pretty much accessing it in a busy loop?
Is there a direct method for that or do you mean that you can repeatedly try reading memory addresses until the address that you want to access is actually in the cache prior to your access?
as in, demo #2 is a working exploit to get this map
They don't exactly leave behind a lot of telltale signs.
This is also the kind of bug that is so broad (read access to everything on almost any machine you can execute code on) that a large subset of those equipped to discover it would have kept their mouths shut.
> So you basically start with a broken system to exploit these bugs.
A lot of systems were broken in the time before KASLR came along
For a start - this is hardly a remote possibility when we already have proof of concepts like the linked repo.
Secondly - your analogy makes no sense. The only way to make it make sense is add that we also know there is an entire spacefaring group of mercenaries whose entire hobby and/or job is deliberately throwing asteroids in Earths general direction.
Maybe there is, but they are hilariously incompetent?
Note they do say
> This demo uses Meltdown to leak the (secret) randomization of the direct physical map. This demo requires root privileges to speed up the process. The paper describes a variant which does not require root privileges.
but I don't know how much allowing it to sudo speeds up the process.