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

491–500 of 639 posts

Re: Reading privileged memory with a side-channel

#491

Post by rurban »

oh-kumudo wrote: post #242
rurban wrote: post #204

Earlier quoted context omitted.

Not against Spectre, which can extract any memory via javascript or user applications. Eg your secret keys or passwords

Spectre is a much more serious bug I feel, but it requires the VM to run the malicious code snippet inside itself and with the right context, not from other guest VM, that is how I understand this. The kinda bug that would totally destroy cloud as a business is the one that other guest VM can read your memory...which doesn't seem like to be the case, for now...

Spectre is mostly about JavaScript extracting keys and passwords from the browser process. Install their ChromeZero extension for a start.

Meltdown on the other hand can do everything. But only on Intel.

Re: Reading privileged memory with a side-channel

#492

Post by Havoc »

jasonlfunk wrote: post #490

As a side topic, are we really in a place that even vulnerabilities need branding and websites?

Well these are essentially research papers - and people invested lots of time & it'll have an impact on their career.

So yeah making it nice & pretty seems appropriate just like a CV

Re: Reading privileged memory with a side-channel

#493

Post by Havoc »

caf wrote: post #282
partiallypro wrote: post #16

So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said: "The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." So either AMD is lying or Goog…

AMD is saying that: !(susceptible_v1 && susceptible_v2 && susceptible_v3) They are not saying that: !susceptible_v1 && !susceptible_v2 && !susceptible_v3 (the latter would be rendered in English as: "AMD is not susceptible to any of the the three variants" )

You've successfully made it less clear.

There is a nice table on AMD's website though:

https://www.amd.com/en/corporate/speculative-execution

Re: Reading privileged memory with a side-channel

#494

Post by Havoc »

alkonaut wrote: post #469

I wonder if the whole thing with enormously complex CPUs requiring deep pipelines which in turn requires complex speculation etc was a design mistake? Is there an alternative history where mainstream CPUs are equally fast with a dumber/simpler design?

The speed gains are very real so I wouldn't call it a mistake.

Side-effects could obviously been mitigated better, but hindsight 20/20.

Re: Reading privileged memory with a side-channel

#495

Post by gchadwick »

jchw wrote: post #283
dannyw wrote: post #237

Earlier quoted context omitted.

The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.

> ...severely round performance.now(). This sucks, and is a side-effect that I didn't even think about. I guess it's probably pretty effective, but it will make benchmarking a lot harder, since you'll probably now have to do a lot more runs.

If it was a big issue you can always introduce a 'benchmark mode' switch that allows you to put resolution back into the counter when you want to run a benchmark. Display a 'WARNING BROWSER INSECURE IN THIS MODE' banner for good measure.

Re: Reading privileged memory with a side-channel

#496

Post by contrarian_ »

londons_explore wrote: post #354
dgomesbr wrote: post #299

Great, embargo was in and google went ahead disclosing and saying hear we're here disclosing this (because they've patched)

3 or 4 people had bits of demo code up on twitter earlier today. I implemented it myself simply based on the clues in the press release from AMD explaining why they weren't vulnerable. I don't even have a computer security background.

So the vulnerability likely isn't something nobody thought of, it's just that nobody seriously expected the CPU vendors to make the mistake of speculating across multiple loads and actually leaving observable modifications in the caches.

Note that even speculating across multiple loads could lead to observable side-effects by measuring memory bandwidth to differentiate between loads of accessible and silent page fault addresses. [1]

An interesting question is whether the CPU would also speculate on loads from mapped PCI device regions, as that could be also detectable in many different ways.

[1] https://eprint.iacr.org/2016/613.pdf

> Both hardware thread systems (SMT and TMT) expose contention within the execution core. In SMT, the threads effectively compete in real time for access to functional units, the L1 cache, and speculation resources (such as the BTB). This is similar to the real-time sharing that occurs between separate cores, but includes all levels of the architecture. [...] SMT has been exploited in known attacks (Sections 4.2.1 and 4.3.1)

Re: Reading privileged memory with a side-channel

#497

Post by iand »

_qbxp wrote: post #375

Can someone more knowledgeable than me in regards to this vulnerability tell me: 1. How to best protect my local personal data from being subject to this? 2. Whether I should seriously consider pulling all my cryptocurrency off of any exchanges?

2. Don't ever store large values of cryptocurrency on an exchange. Keep them offline in paper or hardware wallets.

Re: Reading privileged memory with a side-channel

#498

Post by koverstreet »

j_coder wrote: post #198

Isn't possible for the kernel to patch all clflush instructions when the software is loaded to keep a circular list of all evicted addresses that would be evicted again on the interrupt that happens when the protected address is read? This way the the timing attack would not be possible.

self modifying code (which exists) would take a massive performance hit. any time a page is marked +X, the kernel would have to mark it -W, and then on page fault the kernel would have to check if userspace was changing something to a clflush instruction.

oh, and x86 has variable length instructions - the same byte stream can decode as different instructions depending on where you start - so i doubt it's possible at all on x86 without a massive performance hit (you'd have to keep track of every jump instruction in the entire address space...)

Re: Reading privileged memory with a side-channel

#499

Post by tamriel »

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).

The person checking out the book is a program, so they aren't the brightest.

They check out the book called "how to go to facebook.com". Then they check out "how to type a password". Then they check out "Typing '1234' for Dummies".

I bet you'll never figure out how to get into their facebook account.

Re: Reading privileged memory with a side-channel

#500

Post by [deleted] »

richardwhiuk wrote: post #477
alkonaut wrote: post #469

I wonder if the whole thing with enormously complex CPUs requiring deep pipelines which in turn requires complex speculation etc was a design mistake? Is there an alternative history where mainstream CPUs are equally fast with a dumber/simpler design?

Not that we currently know about. RISC instead of CISC is better here as it shortens the pipeline, but even RISC processors do speculative predictions due to the cost of waiting till a branch is fully decided.

[deleted]
Post reply on HN