From https://meltdownattack.com/meltdown.pdf, page 12:
> Thus, the isolation of containers sharing a kernel can be fully broken using Meltdown.
Reading privileged memory with a side-channel
561–570 of 639 posts
Re: Reading privileged memory with a side-channel
#562Earlier quoted context omitted.
I don't believe for a second that nobody came up with this idea before. I believe that nobody until now had the motivation to spend the time actually trying to confirm that it's a problem by developing a PoC. Most people would have given up on the idea simply because CPU vendors are not expected to make such a fundamental mistake.
The mistake is clear from the design - thats why all CPU vendors are vulnerable to variants of the same bugs. Previously side channel attacks like this have been seen by the security community as unreliable things which only work in very specific cases and have to be averaged over millions of runs. This attack shows a side channel which is general purpose, reliable, and fast.
> The mistake is clear from the design
There is no fundamental reason why speculative instructions should be allowed to mutate the cache.
OTOH the contention-based side channel attack on speculation has been public knowledge for over a decade. [1]
[1] Z. Wang and R. B. Lee, "Covert and Side Channels Due to Processor Architecture," 2006 22nd Annual Computer Security Applications Conference (ACSAC'06), Miami Beach, FL, 2006, pp. 473-482. doi: 10.1109/ACSAC.2006.20
Re: Reading privileged memory with a side-channel
#563Earlier quoted context omitted.
No, the Spectre paper discusses cross-process attacks too. First, you use BTB poisoning to coerce the victim process to branch-mispredict to code of your choice (a "gadget"). You can get that code to load memory of your choice, which can be the code of shared libraries (which are usually loaded only once into physical memory for all processes). Then you can do timing attacks using the last-level cache to determine wh…
This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton misses, if you can't control what the victim process accesses, it seems harder to exploit. We're all talking about how Spectre is this magic "get access to any memory from any process". But it looks to me like it's a new class of attack, that still requires spec…
I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch.
Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likely go. Then you trigger the victim process in the way you know will cause a very similar branching operation.
Even though it's operating within an entirely different process, the branch predictor uses what it learnt in the hostile process to predict the branch result in the victim process. It jumps to the address the hostile process taught it, and starts to speculatively execute code there. Eventually, it figures out it guessed wrong, but by then it's too late, and the information has leaked via a side-channel in a way that the hostile process can detect.
So, essentially, you're use the branch predictor's cache to send the memory address. And you're not sending it to the victim process, you're sending it directly to the CPU. The victim process will never even know it's been attacked, because when the branch predictor hides the consequences of its incorrect guess from being detected by conventional means.
Re: Reading privileged memory with a side-channel
#564Earlier quoted context omitted.
Disabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.
That only fixes one variant of Spectre, and only for code running in kernel mode. The "out of bounds" Spectre variant is still feasible. Also: What about hyperthreads? It seems to be many people's assumption that the BTB is shared within a physical core.
The out of bounds variant is fixable in the OS, just add a fence instruction between the check and the load.
For code running in user mode, you flush the branch predictor on each context switch---again, new microcode + patched OS.
Hyperthreads are tricky. Those are not yet fixed by microcode AIUI, and in the future you may want a usermode program to say "I don't want indirect branch prediction because I am afraid of what the other hyperthread might do to me". That would require some new system call (like a new prctl on Linux) or something like that.
Re: Reading privileged memory with a side-channel
#565Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.
I've hacked together a simple simulation of meltdown based on the paper. It runs the pipelined instructions after exception has been raised and then snoops the data via cache flush and reload. Windows only for now.
The _snoop function is pipelined after exception - this function loads the byte from the specified address and forces a cache load based on the value, which is then recovered via cache flush and reload.
If you removed forced exception in the try block and pass in e.g. a possible kernel address, the load itself will trigger an exception and the bytes from that address can be recovered. I haven't been able to find a kernel address that works - I guess kernel address space separation fix makes it very difficult.
Re: Reading privileged memory with a side-channel
#566Earlier quoted context omitted.
I don't understand how this info can be used for getting what was inside the book? If my understanding of your explanation is correct, book name is analogous to memory address. When the victim (legit process) returned the book with name X (called free on the mem block X), the librarian (OS) erased all pages of the book and repurposed it for printing another book before handing it out to the evil dude(snoopy process).
My attempt, assuming that the books only contain one character each: The librarian has a list of books you're not allowed to take out. You request one of those books (book X), but it takes a while for search to run to see whether you're allowed to or not. While you're waiting, you say "actually, I'm not really interested in taking out book X, but if the content of that book is 'a', I'd like to take out book Y. If the…
I understood with your explanation, thanks!
Re: Reading privileged memory with a side-channel
#567Earlier quoted context omitted.
We'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.
You are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web. https://noscript.net/
you are better off with uMatrix which gives the user significantly more control on what loads/executed: https://github.com/gorhill/uMatrix
(it's the more advanced version of uBlock, from the same dev)
Re: Reading privileged memory with a side-channel
#568Earlier quoted context omitted.
This is mitigatable if the attacker process can't send a memory address to the victim process, right? Even if you can poke at the memory for cache prediciton misses, if you can't control what the victim process accesses, it seems harder to exploit. We're all talking about how Spectre is this magic "get access to any memory from any process". But it looks to me like it's a new class of attack, that still requires spec…
I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch. Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likel…
this still seems off to me.
I get that the victim process' branch prediction can be messed with. But if my victim process is:
password = "password"
secret = "magic BTC wallet secret key"
while True:
password_attempt = input()
if constant_time_compare(password, password_attempt):
print(secret)
result = ""
while sys.stdin.peek() not in ['\n', EOF]:
result += sys.stdin.get()
The examples given all include arrays provided by the hostile program, and some indexing into the arrays. I definitely see this being an issue in syscalls, but if that's the scope of this, I wouldn't call Spectre a "hardware bug" any more than other timing attacks would be hardware bugs.
Re: Reading privileged memory with a side-channel
#569Earlier quoted context omitted.
Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.
I suggest some reading first, starting with (but not limited to): * http://blog.darknedgy.net/technology/2016/01/01/0/ ( https://news.ycombinator.com/item?id=10824382 ) * https://news.ycombinator.com/item?id=10483467
I've read them — but the important factor is that Linux with KPTI is now doing a full context switch between userland and kernel, which is the same cost as switching to another userland process to handle the syscall (which is exactly what a naive microkernel would do).
I've always been a proponent of microkernels, and this is another situation that might help with this.
(Personally, I've been affected by the failures of monolithic kernels way too often. When a simple OpenGL or WebGL program manages to hang your GPU driver, parts of the kernel, and all DMA operations in the kernel, and your system becomes unusable, then reasonable isolation would be preferable)
Re: Reading privileged memory with a side-channel
#570Earlier quoted context omitted.
Disclosure: I work on Google Cloud. If you run a multitenant workload on a linux system (say you're a PaaS or even just hosting a bunch of WordPress side by side) you should update your kernel as soon as is reasonable. While VM to VM attacks are patched, I'm sure lots of folks are running untrusted code side by side and need to self patch. This is why our docs point this out for say GKE: we can't be sure you're runni…
No offence intended as I'm sure it's a bit of a madhouse there right now, but is your statement really correct? I read the Spectre paper quite carefully and it appears to be unpatchable. Although the Meltdown paper is the one that conclusively demonstrated user->kernel and vm->vm reads with a PoC, and Spectre "only" demonstrated user->user reads, the Spectre paper clearly shows that any read type should be possible a…
I'm not sure about GCE but in Azure often the largest node size in a particular family (i.e. D15_v2, G5, M128, etc.) is isolated / dedicated to a single customer.