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

331–340 of 349 posts

Re: Downfall Attacks

#331

Post by saagarjha »

tracker1 wrote: post #168
bsder wrote: post #138

Earlier quoted context omitted.

The problem is that nobody wants to admit that the old, stodgy mainframe guys were right 30 years ago and that sharing anything always results in an exfiltration surface. Nobody wants to be the first to take proper steps because they have to either: 1) Partition hardware properly so that users are genuinely isolated. This costs silicon area that nobody wants to pay for. 2) Stop all the speculative bullshit. This thro…

I'd add that the status quo has done pretty well, and many of these exploits are fixed. It's also worth noting that a lot of the exploits in question may be known, but the people working on them couldn't theorize a practical exploit. How many web browser sandbox breaches have there been over the years? Far less than the CPU exploits in the past several years. The latter can have a much bigger impact though. The bigge…

Web browser sandboxes are broken all the time using conventional bugs.

Re: Downfall Attacks

#332

Post by kragen »

buildbot wrote: post #326
kragen wrote: post #320

Earlier quoted context omitted.

dan bernstein had pointed out the risk that speculative execution would lead to side-channel attacks years before, but there's a common pattern where security people point out a risk and then vendors dismiss it as impractical until it's demonstrated in practice

In computer engineering grad school, I mentioned to my PI that there was an upcoming hardware security flaw that I had heard about from … sources… and he quickly guessed it was speculative execution related without knowing anything more. I think people knew it was possibly dangerous, but the performance gains from speculative execution were huge enough nobody in Intel/AMD red-teamed the design basically.

probably incentives are not well-aligned

i mean meltdown didn't exactly crater intel's sales

Re: Downfall Attacks

#333

Post by TrapLord_Rhodo »

tracker1 wrote: post #171
watermelon0 wrote: post #106

Earlier quoted context omitted.

Not just burstable instances. AWS Fargate, container as a service, allows specifying 0.25 or 0.5 CPU, and I would be surprised if those weren't shared. Same probably? also applies to AWS Lambda.

My guess is there's likely less value in trying to target those kinds of environments... Just poking random data out of lambda or low end vps neighbors is a needle in a haystack the size of the moon in terms of finding anything useful. It's more likely useful as part of a group of exploits to hit an individual, targeted system.

>Just poking random data out of lambda or low end vps neighbors is a needle in a haystack the size of the moon in terms of finding anything useful.

LLM's might change that. getting a firehouse of data and asking it to classify controls against NIST 53- rev5 produces interesting results.

Re: Downfall Attacks

#334

Post by saagarjha »

snvzz wrote: post #166
xyst wrote: post #160

So it seems like speculative execution cannot be disabled. What’s the mitigation here? Nothing and wait for patch or significant redesign?

>What’s the mitigation here? Replace the buggy CISC CPU. Ideally with a less complex thus highly likely less buggy RISC one.

This vulnerability has nothing to do with the instruction set.

Re: Downfall Attacks

#335

Post by saagarjha »

thewataccount wrote: post #29

Does anyone know what type of workloads this effects the performance of the most? Is this specialty-type of workloads or are general webserver/database/coding/compiling/gaming/desktop usages effected?

Workloads that make heavy use of gather instructions. Typically scientific/HPC?

Re: Downfall Attacks

#336

Post by saagarjha »

alerighi wrote: post #145
SoftTalker wrote: post #25

Earlier quoted context omitted.

I'm not sure what evidence there is to think that Apple's chips are any better. And that's not really a dig at Apple; these are just very complicated devices and especially with the optimizations that CPUs need to make to run today's software with acceptable performance, it can become very hard to foresee all possible attacks and vulnerabilities.

x86 architecture is now proven to be a minefield. It has too many instructions, being a CISC instruction set (something that was obsolete in the 90s but was keept for backward compatibility with older software). This means that to make efficient CPU the manufacturer has to do a ton of optimizations. These optimizations have resulted in most of the bugs we have seen. Contrary ARM or other RISC instruction set are more…

All high-performance processors have very complex optimizations. This has nothing to do with x86. The vulnerabilities found in other processors are similar in design and about as difficult to exploit.

Re: Downfall Attacks

#337

Post by willy_k »

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.

Depends. This type of vulnerability is probably fairly valuable to state actors, for example.

Re: Downfall Attacks

#338

Post by zamadatix »

zamadatix wrote: post #311
BeeOnRope wrote: post #185

Earlier quoted context omitted.

I dabble in this space (hardware reverse-engineering) and write software for a living and in my opinion the gaps are huge. I should disclose have been paid by a chip-maker for a blog post that I wrote which "disclosed" an optimization which could be uses for a side channel attack (though I did not even suggest that aspect) and which was subsequently patched away via a microcode update. The whole process was very surp…

Do you have a link for the blog post? I'd love to read more about that. Since we disagree in how big the gap is, and neither of us is going to get a satisfactory answer out of a chip maker any time soon, perhaps a different argument: there are plenty or microcode updates all the time, doing more than fix just security bugs. There are also security bugs like M1racles which have nothing to do with performance incentive…

Another example: https://news.ycombinator.com/item?id=37063459 but it gets 1/6 the visibility.

Re: Downfall Attacks

#339

Post by thumbuddy »

api wrote: post #152
infinityio wrote: post #123

Earlier quoted context omitted.

This could be a case of survivorship bias - we don't know how many spectre-like bugs did get patched, because they never made it to the public

We also don't know how many are still out there unreported and part of the secret zero-day caches of various intelligence agencies.

There's probably thousands if not more. The way I always imagined this working was. agency and company work together to leave gaps in our hardware and software under the ruse of "it must be secure enough for our use." Agencies get a preemptive six months or so to find enough zero days to do what they want. The engineers at the company screaming about the issues are ignored.

Eventually a foreign adversary or domestic hacker finds one that can cause a lot of harm. As soon as they find one a DOD funded student simultaneously discovers it. Alternatively, if documents leak showing how these exploits could happen, same scenario.

Not to say all bugs are known, but I'd imagine a fair deal of them certainly are.

Re: Downfall Attacks

#340

Post by wryanzimmerman »

throwaway892238 wrote: post #58
marssaxman wrote: post #35

Earlier quoted context omitted.

> For JavaScript it’s a bit harder. "We should probably just stop doing it" works for me.

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…

But “regular old apps” don’t do all the same things.

The whole point of properly developing web apps is that html/css indicates a certain level of semantic understanding which allows for different interpretation in different contexts.

If you build a web app well, you build it to be a good experience on a computer for a power user with a huge screen and a keyboard for shortcuts, good for a user on a tiny touch screen, good for a blind person who doesn’t use a screen, and good for robots to parse and index. It should even be good for someone on an iPad with a mouse or a pencil which interprets the whole concept of the mouse differently from the desktop user’s mouse.

The agreed-upon semantics of HTML and the separation of visual styling into CSS is what allows you to take a step beyond just building an app and add a layer of “say what you mean” such that human and non-human users can re-interpret it into their own devices, use cases, and specific needs.

Web frontends are at their best when you don’t expect to perfectly control the end user experience, but try to convey the semantic meaning as perfectly as you can so it can be interpreted into good experiences even in situations where the display is wildly different than originally intended.

Post reply on HN