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

301–310 of 337 posts

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

#301

Post by blablabla123 »

Fej wrote: post #76

What is the recommended course of action? Stop buying Intel products, and devices which contain them? What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable! It's only a matter of time until something…

I think it depends very much how you use your computer and also how much comfort you need. Therefore the answer is very individual. If you want to go totally hardcore secure, you might consider OpenBSD on some obscure architecture like RISC-V or Power - the Talos II workstations are really powerful. (Power was AFAIK originally vulnerable to Spectre or Meltdown, but there are mitigations and it's 100% open source) Probably it's smart to use 2FA on separate hardware (Smartphone, Yubikey or Smartcard for instance) and make it a habit to delete data and apps that you don't need. Oh and also installing only software from trusted sources - whatever that means for you - and an adblocker might also help to prevent malicious JS code. Also for many people iPads serve all needs they have and by default all the native apps have been reviewed.

Probably it's smart to not see a computer not like a walled garden but more like a sieve.

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

#302

Post by neop1x »

bigmattystyles wrote: post #153

Why doesn't this type of news cause INTC to tank - they're up today. I know the market is up today, but (and it's probably my innate overreaction) I would think this sort of news would cause its stock to suffer.

Because it depends on customer behavior. Intel has a strong name and people know their CPUs are fast. We see various IT security problems almost daily and most people don't care... It would probably require some massive exploits, data leaks, identity thefts in cloud providers and following lawsuits againts Intel to see some significant stock price change. :)

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

#303

Post by clarry »

api wrote: post #253
userbinator wrote: post #235

Earlier quoted context omitted.

The easiest prevention is to stop running untrusted code, or don't start doing so if you're not already. The "elephant in the room" with all these attacks starting from Spectre/Meltdown is that an attacker has to run code on your machine to be able to exploit them at all. To the average user, the biggest risk of all these side-channels is JS running in the browser, and that is quite effectively prevented by careful w…

I think that's a cop out. A system should be secure enough to isolate untrusted code.

> A system should be secure enough to isolate untrusted code.

In a dream world. It's become obvious that our general-purpose systems are far too complex to be proven secure, and trying to run untrusted code on such a foundation is going to turn up vulnerability after vulnerability after vulnerability. It is madness.

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

#304

Post by srfilipek »

jupp0r wrote: post #98
justryry wrote: post #85

Do cloud providers commonly float cores between VMs? I could see instances like the AWS T family (burstable) sharing, but I had always assumed that most instance types don't over-provision CPU. If that's the case, my CPUs are likely pinned to my VM. I could still have evil userland apps spying on my own VM, but I would not expect this to allow other VMs to spy on mine.

Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable (although exploits are much harder when attackers have to cross privilege boundaries).

> Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable

Not to these vulnerabilities. These are attacking memory that is "in flight" within a processor.

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

#305

Post by clarry »

The best defense against all these CPU vulns is to stop running malicious code. And that means getting off of shared VMs (and similar) where someone could run malicious code in your stead. Stop running any script your browser gets handed. Isolation was always a great idea, poor man's isolation (VMs, processes, ...) is only useful for isolation against non-malicios accidental interference. You want physical isolation between applications and services.

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

#307

Post by jolopy »

nine_k wrote: post #9

In short: * Core and Xeon CPUs affected, others apparently not. * HT on or off, any kind of virtualization, and even SGX are penetrable. * Not OS-specific, apparently. * Sample code provided. https://www.cyberus-technology.de/posts/2019-05-14-zombieloa...

many Pentiums, Celerons and Atoms are also affected.

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

#308

Post by nine_k »

dfrage wrote: post #137
nine_k wrote: post #16

Earlier quoted context omitted.

Running many instances of various untrusted code on the same server is "new": it came with the cloud infrastructure. Running many instances of various untrusted code on the same client machine is "new": it came with web apps, and with mobile apps. Before several years ago, it was sort of a non-issue, because to exploit such a vulnerability one would need to write a virus or a trojan, and with this approach, there are…

https://en.wikipedia.org/wiki/Time-sharing Time sharing was very big in the 1970s, and non-OS/VM methods of sharing mainframes for batch processing were also big at times I'm less sure of. Inviting complete randoms to routinely run untrusted code in your own security domain, as we do with browsers, that's "new". And thus the popularity of NoScript and uMatrix.

Indeed! Though time-sharing was more like a terminal server, or shared hosting, while OS/VM was more like a modern VM host.

It's interesting though why cross-process data exfiltration based on speculative execution was not tried with any success in the shared hosting environment of 1990s and early 2000s. I suppose it has something to do with the use of non-JIT-ted interpreted languages, like PHP, Perl, or SQL, on such hosting; you could not run an arbitrary native executable like you do in the cloud.

Another factor is that though speculative execution was first implemented in 1950s [1], it was either mainframes or RISC machines, and neither was used by the Intel-dominated shared-hosting environments.

[1]: https://en.wikipedia.org/wiki/Branch_predictor#History

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

#309

Post by kazagistar »

dfrage wrote: post #260
api wrote: post #253

Earlier quoted context omitted.

I think that's a cop out. A system should be secure enough to isolate untrusted code.

A friend and coworker of mine had a saying "Speed Kills" about trying too hard to make things fast while keeping the system robust. You most certainly can make more secure systems, as the merely superscalar and less intense CPUs are, but they're significantly slower. All depends on your threat model; to take one extreme, if you're crunching numbers with your own optimized numeric code, the issue of untrusted code of…

With any cloud computing, they very well could be.

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

#310

Post by dfrage »

kazagistar wrote: post #309
dfrage wrote: post #260

Earlier quoted context omitted.

A friend and coworker of mine had a saying "Speed Kills" about trying too hard to make things fast while keeping the system robust. You most certainly can make more secure systems, as the merely superscalar and less intense CPUs are, but they're significantly slower. All depends on your threat model; to take one extreme, if you're crunching numbers with your own optimized numeric code, the issue of untrusted code of…

With any cloud computing, they very well could be.

Good point, I was thinking in the context of owning your own (super)computer or mainframe and having control over what ran on it. In the cloud, which to us implies running in a VM with other tenants vs. for example dedicated machine(s) with other services bundled in, anything goes.
Post reply on HN