Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

501–510 of 639 posts

Re: Reading privileged memory with a side-channel

#501

Post by caf »

tankenmate wrote: post #484
caf wrote: post #315

Earlier quoted context omitted.

They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor. See the section "Reading host memory from a KVM guest / Locatin…

But if you use AMD ASID it blocks this as memory mappings for VM guests are in a completely separate address space. What I was wondering was for local OS user mode to local OS root / kernel mode access; i.e. user to kernel privilege escalation.

It isn't obvious at all how a separate address space would block that method.

What would block it is flushing the branch predictor state when switching privilege levels and/or address spaces.

Re: Reading privileged memory with a side-channel

#502

Post by [deleted] »

pacavaca wrote: post #483
endymi0n wrote: post #433

Hard to find a good spot for this, but: Thanks to anyone involved! From grasping the magnitude of this vulnerability to coordinating it with all major OS vendors, including Open Source ones that do all of their stuff more or less „in the open“, it was almost a miracle that the flaw was leaked „only“ a few days before the embargo - and we‘ll all have patches to protect our infrastructure just in time. Interestingly, i…

Consider how many other of such "gray" patches could already be in the kernel ;)

[deleted]

Re: Reading privileged memory with a side-channel

#503

Post by Avamander »

user5994461 wrote: post #441
Certhas wrote: post #207

Earlier quoted context omitted.

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?

They say they can reliably read memory around 120kB/s with one vulnerability and 1kB/s with the other. It just works, all the time. Some of the PoC takes a few minutes to initialize. I'd say difficulty level is easy.

Difficulty to exploit is easy once you have the exploit running. Writing a new exploit is really hard, otherwise we wouldn't be starting 2018 with these news.

Re: Reading privileged memory with a side-channel

#504

Post by contrarian_ »

bonzini wrote: post #459
jhallenworld wrote: post #248

Earlier quoted context omitted.

I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until ret…

> I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.

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.

Re: Reading privileged memory with a side-channel

#505

Post by tanilama »

snowwrestler wrote: post #422
tanilama wrote: post #402

Earlier quoted context omitted.

> Spectre Spectre doesn't really care if it is cloud or bare metal. They are equally vulnerable unless disconnected from internet.

To get you with Spectre, the attacker must be able to run code on your CPU. This affects browsers with Javascript enabled because your Javascript engine runs foreign code on the CPU. The bad guy puts nasty code in a page, you visit the page, the code executes on your machine--boom. And it affects public cloud web servers because multiple cloud servers (virtual machines) run on one CPU. So some attacker might be able…

Spectre doesn't let u do cross VM memory reading, Meltdown does, AFAIK. If you want to read other VMs memory, u need to RUN in those VMs yourself and within the right process.

So cloud instance and bare metal ones are equally vulnerable under Spectre: as long as they can transfer their malicious code to your VMs and runs it. Can't really see how bare metal servers mitigate this problem.

Re: Reading privileged memory with a side-channel

#506

Post by ForHackernews »

Godel_unicode wrote: post #408
jacksmith21006 wrote: post #122

Earlier quoted context omitted.

How about based on how many of the serious issues are found by Google. It has been one after another.

They're definitely world class, but they're also loud about it. Consider that other teams perhaps have a different model. For instance, Microsoft's internal team surely finds lots of clever bugs that never get talked about in Microsoft products.

I assume the NSA finds and quietly stockpiles some very clever vulnerabilities, too.

Re: Reading privileged memory with a side-channel

#507

Post by contrarian_ »

labster wrote: post #339
Certhas wrote: post #207

Earlier quoted context omitted.

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?

I don't know much about this particular flaw, but I imagine it'll be pretty hard until someone releases an exploit kit, and then pretty easy after that.

It's an arms race, there will always be new ways of exploiting this flaw in unexpected ways unless speculation is disabled entirely on existing CPUs.

Re: Reading privileged memory with a side-channel

#508

Post by contrarian_ »

FranOntanaya wrote: post #356
Certhas wrote: post #207

Earlier quoted context omitted.

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?

It doesn't look that hard, and in any case, we will suffer the mitigation consequences either way.

Worse, no mitigation will ever be complete against Spectre, unless flat out disabling speculation across memory loads.

Re: Reading privileged memory with a side-channel

#509

Post by gldalmaso »

userbinator wrote: post #163
zitterbewegung wrote: post #154

So how much legal liability are they exposed to due to this security flaw? Since this affects legacy systems that may not be able to be upgraded it seems like this issue will be around for a very long time.

Since this affects legacy systems that may not be able to be upgraded it seems like this issue will be around for a very long time. It also only affects "legacy systems" which routinely run nontrusted code. If it's something like e.g. a server in a bank, chances are everything running on it has already been accounted for. This isn't like e.g. Heartbleed where you could just connect to any open server and read its mem…

However, since it seems like there is not much anyone can do to identify what is being leaked and what process did it, this does increase the risk that someone might exploit this internally and get away with it.

Re: Reading privileged memory with a side-channel

#510

Post by myrmi »

prab97 wrote: post #480
hyperion2010 wrote: post #430

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

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 content of that book is 'b', I'd like to take out book Y+1, and so on".

The librarian is still waiting for the search to complete to see if you can take out book X, but doesn't have anything better to do, so looks inside it, sees that the letter is 'b', and goes and gets book Y+1 so she can hand it over to you.

Now, the original check to see if you can take the first book out completes, and the librarian says "I'm sorry, I can't let you have book X, and I can't give you the book I fetched that you are allowed to take out, otherwise you'd know the content of the forbidden book."

Now, you request book 'Y', which you are allowed. The librarian goes away for a few minutes, and returns with book 'Y', and hands it over to you. You request book 'Y+1', and she hands it over immediately. You request book 'Y+2', and she goes away for a few minutes again, and hands it over.

You now know that Y+1 was (probably) the book she fetched when you made the forbidden request, and therefore that the letter inside the forbidden book was 'b'.

Post reply on HN