Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

291–300 of 639 posts

Re: Reading privileged memory with a side-channel

#291

Earlier quoted context omitted.

https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... Failed attempt in July which is being attributed as earliest work via https://twitter.com/lavados/status/948700783259811847

Jann Horn's results & report pre-date the blog post though. The topic was "ripe", so to speak, so multiple parties investigated it at roughly the same time.

AIUI, Anders Fogh has collaborated with people at TU Graz on various occasions previously: I'd assume they already knew about his work prior to the blog post.

Re: Reading privileged memory with a side-channel

#293
post #165

Earlier quoted context omitted.

I read it as it was an independent discovery by project zero and by academia researchers.

Independent discovery don't happen overnight. Intel must have been aware of these vulnerabilities for some time. edit: I'm sure everyone involved acted responsibly. I'm just curious as how far apart these independent discoveries were made. The bug has been around forever, but it must have been discovered relatively recently since it's not fixed in hardware yet. I've always been baffled by the concept of simultaneous…

Google project zero blog says: We reported this issue to Intel, AMD and ARM on 2017-06-01

Re: Reading privileged memory with a side-channel

#294

Earlier quoted context omitted.

Project Zero is very well known for things exactly like this. Partially, it's because they are incredibly talented, but there are also talented people in academia and in other security consultancies. The biggest difference with Project Zero is that their primary [0] goal is altruistic: find vulnerabilities, and let people who can fix them know (vs publishing papers, securing paying clients, auctioning zero-days, etc)…

Hm that's tricky. These awesome findings didn't exactly provide net value for google, not even on the not so short term (next 10 years?). They've created a large problem for Google! :-)

Discovering a vulnerability is not creating it. A vulnerability exists even if it was not publicly disclosed. There were probably other people already exploiting it.

Re: Reading privileged memory with a side-channel

#295
post #241

Earlier quoted context omitted.

To make it a bit clearer how this works: the Variant 2 exploit poisons the branch target buffer to cause the processor's speculative execution in kernel space to jump to an entirely attacker-controlled destination when it hits a branch that matches the information the attacker has placed into the BTB. The actual retired instructions don't go this way of course - the processor detects the misprediction and goes back t…

But somehow you have to get that kernel address in the first place in order to alias it in the BTB. How do you get that without root?

You boot up your own copy of Ubuntu LTS-whatever and read the address of it as root.

KASLR is not enabled everywhere, and where it is, there are other attacks to defeat it, which are mentioned in the paper.

Re: Reading privileged memory with a side-channel

#296
post #172

So, basically CPUs will read instructions inside a branch even if the branch is eventually going to evaluate to false. Does the CPU do this to optimize branch instructions? The results of instructions that are executed ahead of time are stored in a cache. How exactly does this exploit read from the cache? I understand it uses timing somehow but I'm not quite sure exactly how that works. (I mostly do software.)

It's a timing attack against the cache. The speculative execution might need to do a read, which means something would need to be evicted from the cache. This makes a subsequent read against that evicted adres slower. This way you can detect things based on speculative execution. I don't know how they go from that to reading memory though.

You arrange things so that the speculated execution loads from an address you provide (this is the target address you want to read), then uses the result of that load to calculate the address of another load (this one, into a location that aliases in the cache with an address you can load directly yourself).

You can then use cache timing to see which address was read in the second load, which means you can see part of the value that was read in the first load. Rinse, repeat.

The variants mostly amount to differences in how you arrange the first part (speculated execution loading from an address you get to provide).

Re: Reading privileged memory with a side-channel

#297
post #284

Earlier 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/

Just looking around, general available figures for public internet (as opposed to tor) suggest that anywhere between 0.1% to 1.0% of users have JS disabled. These numbers have also been consistently going down over time. That's a fairly small number to dictate how a system should be designed.

Re: Reading privileged memory with a side-channel

#298
post #4
post #2

"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them." Curious. All other reports I've read state that AMD CPUs are not vulnerable.

Sounds like maybe SOME ARM and SOME AMD are implicated, especially since the Android ARM CPUs appear to be fine...

The ARM white paper goes into detail https://developer.arm.com/-/media/Files/pdf/Cache_Speculatio...

Re: Reading privileged memory with a side-channel

#300
post #142

Earlier quoted context omitted.

I just sold all my altcoins for BTC on Binance as soon as I saw this and transferred them to gdax. Hopefully I can sell them for USD on gdax and transfer to a real bank before they get hacked.

Why would you do that? If you are concerned for the security of your coins, you should have moved them to a wallet you own that is not hosted on an exchange. The bank you transfer your dollars to is just as likely to get hit by the exact same vurnerability. In addition you have to pay a fee to move your coins, then to wire the dollars to your bank account. Moving from crypto to fiat is also liable to taxation. If the…

> Moving from crypto to fiat is also liable to taxation

Trading between cryptoassets as GP suggests he has done already makes them subject to taxation. The fiat step isn’t needed.

Post reply on HN