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

ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

cyberus-technology.de

Post reply on HN
Print view View original

61–70 of 337 posts

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#61

Post by jancsika »

gmueckl wrote: post #35
Tharkun wrote: post #26

Earlier quoted context omitted.

Many years ago, OpenBSD's Theo De Raadt made a sneer at virtualization, saying something the lines of "they can't even build a secure system, let alone a secure virtualized system". I can't remember who he was referring to specifically, but we've certainly been seeing a lot of similar vulnerabilities.

Would be cool to see a source for that one. Theo de Raadt is a hardliner whom I don't always agree with, but I'd like to know how visionary he actually was in this case (quite a bit by the looks of it).

I'm not a security person but I wanna practice trying to sum up his points:

1. There's no way in hell that a bunch of VMs running on one physical server is more secure than a bunch of different physical servers each running an OS. If there were architectural hooks for those VMs to provide additional security beyond what the host OS provides, then an OS like OpenBSD would already be making use of it.

2. Running a bunch of VMs on a single physical machine is certainly cheaper.

3. People who are in favor of the cost-cutting are claiming that there's a security benefit to sell more stuff.

Am I right?

If so, how does that stance jibe with the research that Qubes is based on?

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#62

Post by dang »

S_A_P wrote: post #21

This sentence killed me: "Daniel Gruss, one of the researchers who discovered the latest round of chip flaws, said it works “just like” it PCs and can read data off the processor. That’s potentially a major problem in cloud environments where different customers’ virtual machines run on the same server hardware." What are they saying here?

This is from the Techcrunch article on the story: https://techcrunch.com/2019/05/14/zombieload-flaw-intel-proc...

We merged that HN thread (https://news.ycombinator.com/item?id=19911465) into this one, via this other one (https://news.ycombinator.com/item?id=19911715).

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#64

Post by robmccoll »

polskibus wrote: post #60

Can this attack allow the attacker to escape public cloud isolation methods and break into the control plane or other VMs?

That depends on what you mean by "break into". If you mean sample data (read) from the control plane or other VMs, then yes; however, the attacker may have difficulty targeting which data is read. The attacker would not be able to write to that memory or gain any sort of execution privilege using this method alone.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#65

Post by altfredd »

wmf wrote: post #13
ksec wrote: post #10

Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months. And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor…

I think it is definitely worth introspecting about the history. It has been known for over 20 years that sharing pretty much anything creates side channels but nobody knew how to reliably exploit them and it was assumed that side channels might never be exploitable. In recent years there has been massive progress in practical data extraction using side channels.

It have always been known how to exploit them. But doing so used to be slower and there have been fewer opportunities for attacks. OS kernels used to have Big Locks (AFAIK, OpenBSD still does), that significantly deterred programs from messing with kernel code and CPU caches.

Things have changed a lot since then: OS kernels became faster by eliminating a lot of unnecessary (?) cross-process overhead; browser makers made a number of potentially problematic decisions ("let's allow Javascript to create CPU threads — what could possibly go wrong?"); Linux kernel developers made few potentially problematic decisions ("let's allow unprivileged processes to invoke arbitrary BPF bytecode — that worked for Java, so what could possibly go wrong?")

A lot of small security lapses added up until it became viable to use CPU flaws to actually target ordinary users. To add insult to injury, certain corporations started spreading myth, that well-known insecure practices — such as knowingly running local software from questionable authors — are "safe enough" for general population. Topic web page even talks about running untrusted Android software, as if Android had some kind of impenetrable security boundary around untrusted apps.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#66

Post by dboreham »

gmueckl wrote: post #14

These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigat…

There are bare metal "cloud" providers such as Packet.net where you get the click n deploy convenience of the cloud but a physical machine. They have quite small machines in the inventory that are close to price competitive with VMs. Even Amazon has this bare metal capability FWIW, but afaik only for big expensive machines.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#67

Post by chatmasta »

ljlolel wrote: post #19
gmueckl wrote: post #14

These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigat…

it increases cloud revenues because of slow downs in CPU, and people can't move off cloud because they're locked in and can't hire datacenter engineers anyway

This is an important point that I noticed around the time of Spectre/Meltdown as well. The mitigation for those bugs caused an average of 30% CPU slowdown, meaning it took 30% more CPU cycles to perform the same work as it did prior to the mitigation. If a cloud provider rolls that out to every server, then every customer's bill for CPU usage should increase by roughly 30%.

Am I totally misunderstanding this? Someone please correct me if I'm wrong.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#68

Post by outworlder »

lawnchair_larry wrote: post #51
ksec wrote: post #10

Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months. And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor…

This is a common pattern for new bug classes. Nobody thought to look at this, and when they did, the rabbit hole went deep. We likely haven’t seen the bottom. AMD are not better. They’re probably worse. They’ll be looked at when the Intel tree stops bearing fruit. But finding an Intel bug is higher impact, so that’s what researchers want to look at.

> AMD are not better. They’re probably worse.

This argument makes zero sense and fails real world inspection. You see, researchers did publish the fact that it affected AMD on Spectre.

For this vulnerability, they were unable to reproduce the bug on AMD (their words). Which means that they tried.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#69

Post by toomuchtodo »

ficklepickle wrote: post #53
jcoffland wrote: post #36

Earlier quoted context omitted.

It should read: > ...said it works “just like” in PCs The number of mistakes in the Techcrunch article is atrocious.

I found two and emailed the author. It's my sad little hobby. He replied promptly and they all should be fixed now. In fact, he found a third that I missed. Keep in mind, this article was posted at 3am pacific, 6am eastern. Assuming the author is in North America, he was probably under a deadline and rather tired. I have found similar typos from prominent writers. Sometimes they email me back, which I appreciate. I f…

Thank you for your service!

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#70

Post by fwip »

jancsika wrote: post #61
gmueckl wrote: post #35

Earlier quoted context omitted.

Would be cool to see a source for that one. Theo de Raadt is a hardliner whom I don't always agree with, but I'd like to know how visionary he actually was in this case (quite a bit by the looks of it).

I'm not a security person but I wanna practice trying to sum up his points: 1. There's no way in hell that a bunch of VMs running on one physical server is more secure than a bunch of different physical servers each running an OS. If there were architectural hooks for those VMs to provide additional security beyond what the host OS provides, then an OS like OpenBSD would already be making use of it. 2. Running a bunc…

I think the argument VM-sellers make is that it's more secure than running a bunch of colocated code on the same machine without VMs, not that it's more secure than distinct physical systems.
Post reply on HN