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

Downfall Attacks

downfall.page

Post reply on HN
Print view View original

251–260 of 349 posts

Re: Downfall Attacks

#251

Post by petergeoghegan »

alerighi wrote: post #140
jjav wrote: post #112

Earlier quoted context omitted.

> This is an unreasonable position. Vulnerabilities can be fixed That's a highly optimistic position, to the point of being almost wishful thinking. The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now. Other similar ones to be published years into the future are also there…

The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug. We should move forward. Apple did a great job wi…

> The real problem here is the x86 architecture

Even if we could say for sure that x86 has been disproportionately affected by speculative execution bugs (which already seems dubious), that could easily be due to a kind of selection bias. Presumably security researchers as a group more or less focus on the most popular and relevant ISAs/microarchitectures.

Re: Downfall Attacks

#252

Post by CanaryLayout »

calibas wrote: post #74
mike_hearn wrote: post #32

The Intel paper link is dead, this seems to be the right one: https://www.intel.com/content/www/us/en/developer/articles/t... General caveats: are there many clouds that still run workloads from different users on the same physical core? I thought most had changed their schedulers years ago so you can't get cross-domain leaks between hyperthreads anymore. Claiming that it affects all users on the internet seems like…

> Claiming that it affects all users on the internet seems like a massive over-exaggeration, as he hasn't demonstrated any kind of browser based exploit and even if such a thing did exist He's saying it likely affects "everyone on the Internet" because most servers are vulnerable.

If you throw in the same vulnerability that AMD has with the list from Intel I think it pretty much covers every server available for rent at Quadra.

Re: Downfall Attacks

#253

Post by liamkearney »

bruce343434 wrote: post #38

Is there an overview page of all these processor data leak bugs the last 10 years? It feels like there has been an enormous surge in them.

As seen in the attack demo video the kernel advises of some. You can ‘cat /proc/cpuinfo’ and look for them there.

Re: Downfall Attacks

#254

Post by ComodoHacker »

peddling-brink wrote: post #236
yyyk wrote: post #196

Earlier quoted context omitted.

The chipmakers don't have an incentive to look too hard for speculation security issues beyond a bit of PR. If they succeed, they lose money and marketshare, while their 'insecure' opponents gain and at most patches later. And in fairness, a lot of these bugs are rather theoretical. Until buyers take these bugs much more seriously, this isn't going to change.

Clouds take these vulns seriously, and have a lot to lose, and have deep wallets. I'd be surprised if this topic didn't come up when large purchases are discussed. Not that there are many alternatives..

And this flaw was found by researcher working for a cloud vendor. I wouldn't be surprised if they already have some special long-term agreements.

Re: Downfall Attacks

#255

Post by johncolanduoni »

dwrodri wrote: post #73
GartzenDeHaes wrote: post #62

How could an attacker gain the level of knowledge necessary to accomplish this without compromising the target process?

I've only done a quick read through the link, but I think the model they imply is that a malicious user could rent a Cloud VM in AWS/Azure/GCP/etc and then sniff the contents of SIMD registers, similar to the Zenbleed attack which was also disclosed recently[1]. This is a big deal because optimized implementations of strcpy, strlen, and memcpy in glibc all use SIMD registers, and glibc is everywhere. 1: https://lock.…

AFAIK none of the cloud vendors run multiple customer's VMs at the same time on the same core; even the "shared-core" virtual machines don't share timeslices (AWS goes into detail about this here[1]).

[1]: https://docs.aws.amazon.com/whitepapers/latest/security-desi...

Re: Downfall Attacks

#256

Post by DarkNova6 »

ngneer wrote: post #84

I do not doubt the severity of the flaw, but most practical attacks end up being far more mundane. Consider SolarWinds, for example. No dazzling tricks needed, whatever gets the job done.

Has there even be a documented practical attack in the wild?

Re: Downfall Attacks

#257

Post by masswerk »

eternityforest wrote: post #221
throwaway892238 wrote: post #58

Earlier quoted context omitted.

Agreed. Browsers are now nothing but an application platform of APIs ( https://developer.mozilla.org/en-US/docs/Web/API ). For some reason they still retain the vestigial HTML, CSS and JS, but really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API. Then we can finally ship apps to users without the shackles of how a browser wants to interpret and render some markup. The…

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build…

> I'd rather we go the other way, and build the browser into the OS

This didn't work out that great with MSIE.

Re: Downfall Attacks

#258

Post by DarkNova6 »

dwrodri wrote: post #206
GartzenDeHaes wrote: post #104

Earlier quoted context omitted.

How do they know what data is in the registers? In the linked article, the person running the attack code knows what is running on the target. The target is also conveniently waiting for the attack code to run without doing anything other than referencing the target data.

I'm gonna get put on a list for typing this out but I'll clarify: 1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month? 2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT…

hmmm. Does this not assume that a cpu is shared among exactly 2 tenants over a long period of time?

And can‘t the cloud provider simply block access to the cpu api? Like they don’t allow you to create your own threads?

Just trying to understand this.

Re: Downfall Attacks

#259

Post by eternityforest »

throwaway892238 wrote: post #226
eternityforest wrote: post #221

Earlier quoted context omitted.

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build…

If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads…

There are probably more website visits than that. People download games and bank apps and things like that, stuff they expect to use frequently, want fast access or offline ability, of they need hardware access.

There are still tons of things that don't need an app. Things that are inherently online and not accessed frequently work fine as sites.

The web doesn't limit what you can do that much, it limits how you can do it, which I think is a good thing. Less to break (Android API levels have the same effect) with fewer original lines of code. Less focus on clever and interesting code and more focus on UI and features (Although they try their best to reinvent the same js framework 1000 times).

A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions. The trend has been pretty strongly towards making the web very close to native apps, with all kinds of APIs.

Native apps fill a use case very well, that the web does not. That doesn't make the web obsolete.

Re: Downfall Attacks

#260

Post by eternityforest »

r3trohack3r wrote: post #232
throwaway892238 wrote: post #226

Earlier quoted context omitted.

If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree. Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads…

> Native mobile apps thrive despite this magical web browser working everywhere There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients. Many folks are surprised to see just how far you can push a browser app and how small the gap between web and bro…

We really need to standardize "just wrapping a browser view". Why are we shipping a whole browser when we could be shipping a zip file of HTML with some metadata, and maybe a few tiny native helper utilities?
Post reply on HN