Meltdown Proof-of-Concept

[martin1975]

I'm curious if someone can point me to any source that discusses how the next generation of CPUs that Intel, AMD, ARM might be working on is actually going to address this & the Spectre issue architecturally.. It's great that we have a potentially performance killing fix but the real "fix" or rather, solution, is to alter the architecture. Since I'm not an EE/CE dude... is anyone aware of where such discussions on the WWW might be taking place?

by the way, that PoC was intense. Makes you wonder if the NSA knew about it all along :)

[krylon]

> 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.

[arkadiyt]

> Makes you wonder if the NSA knew about it all along :)

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...

[white-flame]

To my understanding, the memory subsystem is fetching a byte in parallel with access permission checks. If the byte is discarded due to mis-speculation, then the result of the permission check is ignored, but the cache is still in an updated state.

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.)

[thisoneforwork]

Not a CPU designer, but my guess is that they will move the cache management logic from the MMU to the µOP scheduler, which will commit to cache on retirement of the speculatively executed instruction. They would then need to introduce some sort of L0 cache, accessible only at the microarchitectural level, bound to a speculative flow, and flushed at retirement.

[JdeBP]

Intel's paper outlines a roadmap for future work.

* https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... (https://news.ycombinator.com/item?id=16079910)

[woliveirajr]

I'm curious on how Transmeta chips [0] would have suffered/be unaffected by such exploits. Being a CPU that runs cpu microcodes, probably the patch would be easier, it necessary at all.

[0] https://en.wikipedia.org/wiki/Transmeta

[chacham15]

There was a HN article a while ago that discussed making use of an existing cpu isa extension to solve the problem in a performant manner: PCID. More here: http://archive.is/ma8Iw

[cm2187]

By the way, I understand the fixes are being rolled out now. Do we have a more precise idea of the performance hit on windows and linux?

[runesoerensen]

The Project Zero bug report (with PoCs/timeline) was also made public a few minutes ago https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

[dx034]

So this specifically states AMD as well. Can someone explain in how far AMD is now affected? I thought they're not affected by the most severe bug?

[ehPReth]

I wonder what happened to "This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public." Executive meddling?

Edit: Probably the 'extreme circumstances' bit mentioned in https://news.ycombinator.com/item?id=16108434

[kodablah]

This was the GitHub repo mentioned in the meltdown.pdf that was 404'ing until now. We have native Spectre replication code too. What still seems to be elusive is the JS-based Spectre impl (probably waiting at least for Chrome 64, though I confirmed via https://jsfiddle.net/5n6poqjd/ that Chrome seems to have disabled SharedArrayBuffer even before they said they would which wasn't the case a few days ago).

[diyseguy]

This is the closest thing to a javascript implementation I have seen: http://xlab.tencent.com/special/spectre/js/check.js

from: http://xlab.tencent.com/special/spectre/spectre_check.html

[thebeardedone]

Moritz Lipp's twitter is actually interesting to follow. He is reconstructing images which do not fit into cache. Quite amazing.

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!)

[trendia]

Linux 4.15 and the appropriate modules protect against the attack.

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-pkg

[noobermin]

I have CONFIG_PAGE_TABLE_ISOLATION on. I roll my own kernel and all that.

Trying 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.

[Valmar]

Page Table Isolation has been backported to 4.14.12, so no need to test with the rc.

[tptacek]

libkdump is really clean code and worth a read, nicely wrapping the inline assembly you need to do the flush+reload and keeping the algorithms in pretty simple C. It's worth taking a few minutes to read through it.

This code is from TU Graz; I assume this is from Daniel Gruss's team, who participated in the original research.

[samsonradu]

High-level programmer here. Can someone explain please (already read the ELI5 in previous threads) how does the attacker extract the actual data from the processor L1 cache after tricking the branch prediction and have the CPU read from an unauthorized memory location?

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.

[1] https://meltdownattack.com/meltdown.pdf

[alien_at_work]

Mostly high-level programmer. I may be wrong or be thinking of another recent attack but my understand was this: the attacker allocates 256 seperate pages, ensures they're not in memory and then runs code like this:

    if(false_but_predictive_execution_cant_tell)
    {
      int i = (int)*protected_kernel_memory_byte;
      load_page(i, my_pages);
    }

Then it becomes a matter of checking speed of reading from those pages. Which ever one is too fast to be loaded when read must be the value read from protected memory.

[krylon]

I have run the first test on several machines, with mixed results, but on my workhorses (ThinkPad x220, Zenbook UX305) the exploit seems to work.

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. :-?

[cookiecaper]

Spectre should work on most modern computers. There are no kernel patches in stable to prevent Spectre right now. Only Meltdown is mitigated by KPTI. The new Intel microcode and the kernel code to control it will propagate out in the next couple of weeks.

[anonymousDan]

Looks like Intel SGX is at least vulnerable to Spectre attacks too: https://github.com/lsds/spectre-attack-sgx

[pbhjpbhj]

First I read about this, so I thought "who's shorting Intel now I wonder", turns out it's the CEO [kinda]:

>"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 ...]

[stefs]

as far as conspiracy theories go (i read that some days ago on reddit), he's wont be persecuted because he cooperates with the NSA. refuse to cooperate with them and join Nacchio and Qwest.

[aeleos]

I am running a razer blade 2017 with ubuntu 16.04 and so far all of the PoCs have worked. I currently have my kaslr offset and I am now testing the reliability. So far it doesn't seem very good with a 0.00% success rate at 60 reads. It did take a while to find my kaslr offset with multiple passes through the entire randomization space so I need to stress my CPU more in order to improve the success rate of having successful branch speculations.

[jeshwanth]

I installed the recent kernel release from Ubuntu, but the tests still working fine.

[Uplink]

Not sure what this means, but while I'm mining Monero on the CPU with xmr-stak the PoC is thwarted.

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.

[srcmap]

From the papers, these two bugs are also exploitable from ARM.

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=yTpXqyRYcBM

[tptacek]

It depends. From what I'm reading: generally, with apparently one possible exception, Meltdown doesn't work on ARM. Generally, both variants of Spectre do.

[gok]

Important to differentiate between ARM the company, the instruction set architecture(s) and the specific implementation of those ISAs. The licensable nature of ARM means there very likely are (possibly undiscovered) implementations of the ARM ISAs floating around which are susceptible to Meltdown.

[Acen]

MacOS is yet to have a patch for 10.12.6 (Sierra) to resolve this.

[K0nserv]

It is patched on Sierra, this was part of the 2017-002[0] security update on the 6th of December.

0: https://support.apple.com/en-gb/HT208331

[devy]

Did you get the PoC built on macOS? I can't get it built on El Capitan.

[lewapkon]

You mean 10.12.6

[rstuart4133]

Does anyone have a link to Linux PoC code for Meltdown that uses speculative branch execution?

I'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?

[rstuart4133]

Never mind: https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

[VikingCoder]

Can the videos be put on YouTube for convenience?

[che_shirecat]

#1 - realtime password input - https://www.youtube.com/watch?v=yTpXqyRYcBM

#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

[pedro_hab]

I've seen these in youtube b4, but they were taken down. I'd careful with the title to avoid it.

[yuhong]

One of the reason I don't consider the timing attacks that important is that there are often easier ways to bypass ASLR.