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

More Intel speculative execution vulnerabilities

mdsattacks.com

Post reply on HN
Print view View original

181–190 of 262 posts

Re: More Intel speculative execution vulnerabilities

#181

Post by Twirrim »

wolf550e wrote: post #166
rrss wrote: post #137

Earlier quoted context omitted.

AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2. EDIT: I found the list I made a few months back. no guarantees, but i think it is mostly accurate. Meltdown: Intel, IBM, some ARM Spectre v1: Intel, ARM, IBM, AMD Spectre v2: Intel, ARM, IBM, AMD Spectre v3a: Intel, ARM Spectre v4: Intel, ARM, IBM, AMD L1TF: Intel, IBM Meltdown-PK: Intel Spe…

L1TF was an incredibly stupid bug in Intel's L1 cache implementation. I very much doubt IBM's POWER chips had the same issue. Do you have any source for this?

Quoting from https://www.ibm.com/blogs/psirt/potential-impact-processors-...

"On August 15, 2018, security vulnerabilities codenamed Foreshadow/L1TF (CVE-2018-3620, CVE-2018-3646 and CVE-2018-3615) were announced. Two of the vulnerabilities (CVE-2018-3620 and CVE-2018-3646) could potentially impact Power Systems. The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown vulnerability (CVE-2017-5754) also address the L1TF/Foreshadow vulnerability, except for Power 9 Systems running with KVM Hypervisor. OS patch for Power 9 KVM Systems will be made available soon. The Firmware and OS patches for all other Power Systems are available in this blog below.

The third L1TF/Foreshadow vulnerability (CVE-2018-3615) relates to SGX implementation and does not impact the Power Systems."

Re: More Intel speculative execution vulnerabilities

#182

Post by diffeomorphism »

yifanl wrote: post #136
coldtea wrote: post #99

Earlier quoted context omitted.

Incompetence as in "they're incompetent engineers", and if so, compared to what baseline? Or incompetence in as "they weren't capable of doing it"? The latter is very probable. The former could underestimate the difficulty of such fixes...

The two statements are identical, competence is always within a given context.

No, the second is "incapable" and suggests that even a "great" engineer could not have done it. The first one says that a "competent" engineer could have.

Big difference.

Re: More Intel speculative execution vulnerabilities

#183

Post by yifanl »

diffeomorphism wrote: post #182
yifanl wrote: post #136

Earlier quoted context omitted.

The two statements are identical, competence is always within a given context.

No, the second is "incapable" and suggests that even a "great" engineer could not have done it. The first one says that a "competent" engineer could have. Big difference.

A great engineer can still be incompetent in the face of a difficult (or poorly specced) task.

Re: More Intel speculative execution vulnerabilities

#184

Post by brojonat »

largbae wrote: post #168
nradov wrote: post #128

Earlier quoted context omitted.

This is one reason why the current high stock market valuations for large, profitable tech companies are crazy. Eventually the corporate culture rots from the inside and they're overtaken by a disruptive competitor. Unfortunately there's no practical way for retail investors to take a short position on those stocks for 30 years in the future; regular options only go out about 3 years.

True, but if you can identify both the winner and the loser, say AMD and/or TSMC vs INTC, you could sell puts/spreads on the loser and sell calls/spreads on the winner in similar at-risk dollar amounts. If the market itself booms or busts through your strikes, gains on one side will cancel the losses on the other. While you're right, you make double money by winning on both sides. But you lose double if you're bettin…

My friend, whether you're trading naked or spreads doesn't matter on timescales of corporate rot are ~30 years; the contracts available to retail traders are like ~2 years out.

Re: More Intel speculative execution vulnerabilities

#185

Post by scandinavian »

saurik wrote: post #178
scandinavian wrote: post #164

Earlier quoted context omitted.

You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs. You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the to…

The website covers a handful of things, and the RIDL exploits don't require special instructions. > We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.

> We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.

They leak in flight data, using a detached spidermonkey engine, patched to make performance.now() return rdtscp at a rate of 1B/s while the victim application is spamming a load string instruction as fast as possible.

This does not allow:

>any ad network can access any and all memory on your desktop

This allows any ad-network to access random bits on the cache line. If the timing mitigation didn't already fix this, it seems impossible to me to get anything useful from it, the precision and bitrate is just too low (which is why the exploit just spams load instructions in a while 1 loop).

>and the RIDL exploits don't require special instructions.

Weird, in the new addendum it says it uses TSX, and in the PoC it uses XBEGIN. Must be a mistake.

Re: More Intel speculative execution vulnerabilities

#186

Post by the_duke »

tylerhou wrote: post #180
the_duke wrote: post #175

Earlier quoted context omitted.

> assuming you aren’t running other peoples’ VMs That's the problem right there: the vast majority of workloads in the cloud runs on shared hosts. AWS/GC dedicated host pricing is not actually that crazy of a markup (around 50% last time I investigated), but that's still very noticeable at scale, and billing granularity is by the hour.

I agree public cloud needs mitigations to be secure. But a significant number of workloads (~50%?) run on-prem or in private clouds. Those generally host "more trusted" code.

True, but only if you trust all your services equally, or restrict each host to a single one.

Otherwise you lose a security boundary.

Re: More Intel speculative execution vulnerabilities

#187

Post by kevin_thibedeau »

AJ007 wrote: post #87
Mirioron wrote: post #66

Earlier quoted context omitted.

I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.

In this case, the FBI and SEC may need to investigate precisely what is going on. If Intel is doing partial fixes it knows of other things that aren’t being disclosed there could be criminal activity occurring. Additionally, this had big implications for cloud providers. If additional liabilities of data leaks are foisted on companies, insurance companies and corporate counsel may just say no more using amazon, googl…

> here could be criminal activity occurring.

More likely some agencies don't want their exploits to stop working.

Re: More Intel speculative execution vulnerabilities

#188

Post by paulddraper »

GrayShade wrote: post #81
paulddraper wrote: post #32

Earlier quoted context omitted.

To exploit these vulnerabilities, you already need (unprivileged, sandboxed) RCE. These vulnerabilities "only" steal information; however that information could of course be leveraged into privilege escalation or anything else.

> To exploit these vulnerabilities, you already need (unprivileged, sandboxed) RCE. Such as running JavaScript code served by an ad network.

Correct.

Point being, running arbitary (unprivileged, sandboxed) code is a prerequisite; an attacker can already max your CPU, mine crypto, etc.

Re: More Intel speculative execution vulnerabilities

#189

Post by paulddraper »

wolf550e wrote: post #55
paulddraper wrote: post #29

Earlier quoted context omitted.

AFAIK Spectre variant 1 only applies to a single address space; i.e. per process. Processes are really "meant" to be the units of security (user, files, network, memory limit, etc.); it's reasonable to need different processes for security partitions.

There used to be a time when people thought relying on if statements for security was enough and proposing an OS [1] where everything is in a single process was plausible. Same for JS JITs. Now we know better. 1 - https://en.wikipedia.org/wiki/Singularity_(operating_system)

> used to be

https://en.wikipedia.org/wiki/Unikernel

Re: More Intel speculative execution vulnerabilities

#190

Post by alkonaut »

HelloNurse wrote: post #116
alkonaut wrote: post #45

Earlier quoted context omitted.

How is the attacker outside, assuming it's a process running on the emulator (I.e. the attacker surface here in the emulator example would be only the NES game, so he has to work with NES cpu opcodes, NES memory locations etc)?

The attacker is not a process running on the emulator, not even if you assume it is. Security is about the worst case, not about hit or miss partial solutions.

I’m talking about a hypothetical future where there are mitigations in place such as running each app sandboxed in an emulator. Obviously if a malicious process can sidestep any such mitigation and run any way it wants, then presumably it can read the memory of any process too? Why would an app even need to rely on vulnerabilities then?
Post reply on HN