One of the reason I don't consider the timing attacks that important is that there are often easier ways to bypass ASLR.
Meltdown Proof-of-Concept
91–100 of 187 posts
Re: Meltdown Proof-of-Concept
#92Earlier quoted context omitted.
No, creating a block of machine code bytes to execute would be a privileged operation. All code would run through a privileged CPU-specific compiler first, and there'd be no way to run raw machine code bytes otherwise. If there are bugs that can be exposed through various machine code patterns, the compiler can centralize the restrictions of what may be executed, enforce runtime checks, or prevent certain instruction…
and what if I wrote a compiler that doesn't heed any of your security concerns? It would still compile to machine code and continue to be able to exploit things Spectre/Meltdown style? Or am I off here?
You'd only be able to run it on your system. At least, without other means of breaching the low level secured configuration of someone else's machine, because that's where the One True Compiler for that system lives.
Re: Meltdown Proof-of-Concept
#93MacOS is yet to have a patch for 10.12.6 (Sierra) to resolve this.
It is patched on Sierra, this was part of the 2017-002[0] security update on the 6th of December.
Re: Meltdown Proof-of-Concept
#94Earlier quoted context omitted.
Not 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
FWIW, that PoC (reading user memory only) still works on 10.13.2 even after the patch is applied.
The 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
Re: Meltdown Proof-of-Concept
#95One of the reason I don't consider the timing attacks that important is that there are often easier ways to bypass ASLR.
Are there easier ways to read kernel memory?
Re: Meltdown Proof-of-Concept
#96Earlier quoted context omitted.
so run everything in a VM?
No, creating a block of machine code bytes to execute would be a privileged operation. All code would run through a privileged CPU-specific compiler first, and there'd be no way to run raw machine code bytes otherwise. If there are bugs that can be exposed through various machine code patterns, the compiler can centralize the restrictions of what may be executed, enforce runtime checks, or prevent certain instruction…
cool .. I think I get it. It's like compiler/instruction based DRM ... CPU specific permission to run code. Maybe they can leverage existing TPM chips to do this...
I just don't want to see performance being decimated as a trade off for security, if at all possible.
Re: Meltdown Proof-of-Concept
#97Earlier quoted context omitted.
Well, since some of the BSD folks publicly stated that they’d ignore any embargo, that seems like a pretty predictable consequence. And in this case I understand that it took a while to develop workable mitigations. Immediate disclosure might have caused great harm.
Tarring all of the BSDs with the same brush is wrong, both in general and here specifically. There's also the matter of both Matthew Dillon and Theo de Raadt discussing this topic months or even years before Google Project Zero made its discovery. * https://news.ycombinator.com/item?id=16086047 * https://news.ycombinator.com/item?id=16074531 * https://news.ycombinator.com/item?id=16075744 Moreover, the OpenBSD people…
> Tarring all of the BSDs with the same brush is wrong, both in general and here specifically.
Is that actually being done? The FreeBSD team got notified (late), the DragonFlyBSD, OpenBSD, NetBSD teams did not get notified. Matt, of course, seems to have a patch already.
Re: Meltdown Proof-of-Concept
#98Earlier quoted context omitted.
How does this work for two instructions in the pipeline at the same time that refer to the same cache line? If the second instruction executes the read phase before the first is retired/committed to cache, you would be hit by two memory fetch latencies, significantly hurting performance. 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 t…
Firstly, thanks for the question. As mentioned, not a CPU designer or trying to teach Intel what to do. More like relying on the hive mind to see if I have the right idea. A second instruction in the pipeline would read from the above mentioned L0 cache (let us call it load buffer), much like it would for tentative memory stores from the store buffer. Also, two memory fetches in parallel are not twice as long as a me…
I don't think you can allow two speculatively executing instructions to read from the same L0 cache.
For example say the memory address you want to look for being cached is either 0x100 or 0x200 (not realistic addresses but it works for example) based on some kernel memory bit. Then run instructions in userspace that try to fetch 0x100 (with flushes in between). If you notice one that completes quickly, then it must have used the value 0x100 cached in L0 cache by the kernel? (and also run over 0x200 to try and check when it's cached in L0)
Re: Meltdown Proof-of-Concept
#99Linux 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
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.
Re: Meltdown Proof-of-Concept
#100Earlier quoted context omitted.
so run everything in a VM?
No, creating a block of machine code bytes to execute would be a privileged operation. All code would run through a privileged CPU-specific compiler first, and there'd be no way to run raw machine code bytes otherwise. If there are bugs that can be exposed through various machine code patterns, the compiler can centralize the restrictions of what may be executed, enforce runtime checks, or prevent certain instruction…
> no way to run raw machine code bytes otherwise [...] restrictions of what may be executed, enforce runtime checks, or prevent certain instructions from being used at all [...] everything optimized for your environment better, allow much better compatibility across systems and prevent entire classes of privilege escalation issues.
So... basically re-inventing Java? :)
"Raw machine code bytes" aren't distributed but occur through the privileged JVM and its just-in-time compiler, the byte-code verifier enforces restrictions on what data-access patterns and where instructions can be used, the JVM for a particular OS has optimizations for that environment, and sandboxing (while imperfect) blocks some classes of privilege escalation issues.
Don't get me wrong, I'm not saying Java is perfect or that the underlying goal isn't good, I'm just happily amused by this sense of "everything old is new again."