16 ms·
Meltdown Proof-of-Concept
- kodablah 9y agoThis 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/ 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 9y agoThis is the closest thing to a javascript implementation I have seen: http://xlab.tencent.com/special/spectre/js/check.js http://xlab.tencent.com/special/spectre/js/check.js from: http://xlab.tencent.com/special/spectre/spectre_check.html http://xlab.tencent.com/special/spectre/spectre_check.html
- kodablah 9y agoNice. Reviewing the code, it is as the PDF said where they are just constantly incrementing a val in the shared buffer to get a fairly precise timer. But it seems to be using the timing to determine across 256 indices (99 tries to check) to check cache hits. So just removing this timer is not enough, it just increases the surface area of bytes you have to read and sift through to see if you have other mem? Anyone have a writeup on this?
- JonathonW 9y agoIsn't the high-precision timer required to detect a cache hit or miss-- as in, the side channel being exploited here is in the timing of a cache hit or miss; there's no data leaked directly into Javascript? That's not to say that removing SharedArrayBuffer (and high-precision performance timers, which were removed a couple years back to mitigate some other timing-related vulnerabilities) is enough to completely eliminate Spectre; there might be other methods that can time accurately enough to reveal information. (I might be completely wrong here, but this is my current understanding of the situation, at least.)
- mwambua 9y agoNice tool. Sadly, it reports that my browser (Chromium 63.0.3239.132 with strict site isolation (chrome://flags/#enable-site-per-process) enabled) is vulnerable to Spectre. Do you know if there are any other steps that I can take to secure myself aside from using Firefox?
- btb 9y agoI'm running the same version of Chrome(with site isolation enabled), its reporting "Your browser is NOT VULNERABLE to Spectre" for me. Also in incognito mode with extensions disabled.
- mwambua 9y agoThanks! It reports the same thing for me too now. I had to enable Top document isolation (chrome://flags/#enable-top-document-isolation) as well.
- gadgetoid 9y agoFound this earlier today via GitHub search: https://github.com/cgvwzq/spectre/blob/master/spectre.js https://github.com/cgvwzq/spectre/blob/master/spectre.js
- dingo_bat 9y agoInteresting that Firefox on my phone is shown vulnerable but Samsung browser is not.
- runesoerensen 9y agoThe 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=1272#c3 https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
- ehPReth 9y agoI 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 https://news.ycombinator.com/item?id=16108434
- adjkant 9y agoI think for a bug this big it is pretty understandable. So far, it seems clear the actions of all involved were in a good spirit of responsible disclosure.
- ehPReth 9y agoHmm, wasn't there that Microsoft Windows(?) bug that they derestricted before the patch was out? Memory escapes me at the moment. I thought it somewhat cemented/promoted their adherence to 90 days regardless of patch availability.
- deleted 9y ago[deleted]
- runesoerensen 9y agoPerhaps you're thinking of this bug report https://bugs.chromium.org/p/project-zero/issues/detail?id=118&redir=1 https://bugs.chromium.org/p/project-zero/issues/detail?id=11... Project Zero evaluated and relaxed their disclosure policy after that incident as described here https://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html https://googleprojectzero.blogspot.com/2015/02/feedback-and-...
- revelation 9y agoThe secret program confirms what others have seen, it's not so much "read any physical memory" as "read memory in cache"
- K0nserv 9y ago> "read any physical memory" as "read memory in cache" 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 https://news.ycombinator.com/item?id=16108574 or read the paper yourself https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf
- koolba 9y ago> You can force any memory into the cache so yes it's is read any physical memory. 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?
- K0nserv 9y agoThe exploit is based on reading values that you shouldn't be allowed to access in speculative execution and then using the returned values to create persistent changes in the cache(they persist even after the CPU detects your illegal access). Those persistent changes are then read via a side channel attack. So you read any address you want speculatively and then use the result to prime the cache in such a way that you can determine what the value you read speculatively was. This works because modern operating systems map kernel space addresses into normal processes and to make syscalls faster. I'd recommend reading the paper[0], it's fascinating stuff. https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf
- ctrlrsf 9y agoIt doesn’t force memory into cache directly. It determines values of bytes in memory by using the byte as a multiplier to an offset in memory. To determine byte value you can check all the offset combinations to see which was cached. Details in the meltdown paper.
- john_teller02 9y agoThese two bugs (Meltdown and Spectr) are really very speculative things. It is like when human beings became aware of astroid orbits they thought that earth is in danger of being hit by one. Now that is indeed a theoritical possibility but what are the chances? These two bugs have been existent for 20 years and there is no known exploits of them. In the GitHub demos also they mention that the demos will work only if "For this demo, you either need the direct physical map offset (e.g. from demo #2) or you have to disable KASLR by specifying nokaslr in your kernel command line." - So you basically start with a broken system to exploit these bugs.
- hannasanarion 9y agoIf you don't know the difference between the existence of an earthbound asteroid and the existence of people who write computer viruses, I don't know what to tell you.
- odonnellryan 9y agoWhat's the name for this logical fallacy? You see this shit all the time.
- mark-wagner 9y agoProbably false analogy.
- anarazel 9y ago"Bullshitting"?
- tedunangst 9y agoI like false equivocation.
- Skunkleton 9y agoIts like circular logic on steroids. Parent is using the word "speculative" to discredit the vulnerabilities that use speculative execution.
- VikingCoder 9y agoCan the videos be put on YouTube for convenience?
- che_shirecat 9y ago#1 - realtime password input - https://www.youtube.com/watch?v=yTpXqyRYcBM https://www.youtube.com/watch?v=yTpXqyRYcBM #2 - physical memory leak - https://www.youtube.com/watch?v=kn0FopiF16o 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
- garblegarble 9y ago>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
- che_shirecat 9y agoI completely agree with the sentiment, however github currently does not support embedded video in markdown [1] Animated gifs do work when embedded, but need to be <= 10mb [2] [1] https://stackoverflow.com/questions/4279611/how-to-embed-a-video-into-github-readme-md https://stackoverflow.com/questions/4279611/how-to-embed-a-v... [2] https://stackoverflow.com/a/46701929 https://stackoverflow.com/a/46701929
- garblegarble 9y agoOh wow, that's crazy - especially 8 years since they said they'd look at it! Thanks for the info
- pedro_hab 9y agoI've seen these in youtube b4, but they were taken down. I'd careful with the title to avoid it.
- trendia 9y agoLinux 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 9y agoI 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.
- trendia 9y agoIt took about an hour for it to find the offset for me. 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).
- noobermin 9y agoBasically, the first test (kaslr.c) did not even work for me, and it scanned all addresses and wrapped around and started again. You probably know this (saw you're the person I replied to initially), but for others reading this to check that it's on, "dmesg | grep isolation" should be able to tell you whether the page table isolation is on after you enable it in the kernel. Given the other tests require the offset, I think I'm safe? I'm going to run it again just to be sure.
- Valmar 9y ago
- anonymousDan 9y agoLooks like Intel SGX is at least vulnerable to Spectre attacks too: https://github.com/lsds/spectre-attack-sgx https://github.com/lsds/spectre-attack-sgx
- Acen 9y agoMacOS is yet to have a patch for 10.12.6 (Sierra) to resolve this.
- lewapkon 9y agoYou mean 10.12.6
- Acen 9y agoAh yes, thanks.
- devy 9y agoDid you get the PoC built on macOS? I can't get it built on El Capitan.
- Acen 9y agoNot any of the PoC. There are repositories around the internet building and working successfully though. E.g. Spectre exploit example https://github.com/ixtal23/spectreScope https://github.com/ixtal23/spectreScope
- sehugg 9y agoFWIW, that PoC (reading user memory only) still works on 10.13.2 even after the patch is applied.
- K0nserv 9y agoThe KAISER[0] fix which is what has been patched by OSes for Meltdown only resolves full physical memory and kernel memory access. You can still use Meltdown techniques to read arbitrary memory in your process, but this seems expected. 0: https://en.wikipedia.org/wiki/Kernel_page-table_isolation https://en.wikipedia.org/wiki/Kernel_page-table_isolation
- K0nserv 9y ago
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- krylon 9y agoI 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 9y agoSpectre 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.
- srcmap 9y agoFrom 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 9y agoIt 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 9y agoImportant 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.
- palotasb 9y agoI was under the impression that they generally license the IP cores (or at least some IP blocks) to implement the ISA and downstream vendors don't implement those differently.
- tptacek 9y agolibkdump 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.
- martin1975 9y agoI'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 :)
- white-flame 9y agoTo 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.)
- martin1975 9y agothe first approach sounds kind of expensive to be done at the cpu level. I like your second one better. thank you!
- deleted 9y ago[deleted]
- white-flame 9y agoActually, my preferred solution would be to eliminate the notion of distributing machine code binaries entirely, but that's a bit beyond the scope of these discussions. ;-)
- pbhjpbhj 9y agoFirst 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-hitting-the-companys-stock-big-time-while-rival-amd-is-soaring/ 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 9y agoas 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 9y agoI 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 9y agoI installed the recent kernel release from Ubuntu, but the tests still working fine.
- yuhong 9y agoOne of the reason I don't consider the timing attacks that important is that there are often easier ways to bypass ASLR.
- tedunangst 9y agoAre there easier ways to read kernel memory?
- yuhong 9y agoThe point is what reading kernel memory would be useful for.
- tedunangst 9y agoOne wonders why /dev/mem was ever read restricted to start.
- yuhong 9y agoReading /dev/mem is far easier/faster and typically provides more data than this attack would.
- hauscraft 9y agoA solution tailored to your business needs https://www.cityfinances.lv/ https://www.cityfinances.lv/
- thebeardedone 9y agoMoritz 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 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!)
- rstuart4133 9y agoDoes 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 9y agoNever mind: https://bugs.chromium.org/p/project-zero/issues/detail?id=1272#c2 https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
- samsonradu 9y agoHigh-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 https://meltdownattack.com/meltdown.pdf
- ajanuary 9y agoCaveat: I am also a high level programmer. 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.
- samsonradu 9y ago> You fetch the secret data. You then fetch a different memory addressed based on the contents of the secret data ... 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.
- ajanuary 9y agoRight, which makes it a bit of a tricky attack to pull off. But if you know what you're doing you can do some operation that requires memory address x and be reasonably sure it will end up in the CPU cache. If you then do an operation on memory address x, and it happens really quickly, and you do an operation on memory address x+128, and it happens a bit slower, you can assume that x was in the cache and x+128 wasn't.
- Uplink 9y agoNot 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.