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

251–260 of 262 posts

Re: More Intel speculative execution vulnerabilities

#251

Post by renox »

paulddraper wrote: post #29
wolf550e wrote: post #9

Earlier quoted context omitted.

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.

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.

Web browsers didn't (still don't AFAIK) use one process per website visited..

Re: More Intel speculative execution vulnerabilities

#252

Post by HelloNurse »

alkonaut wrote: post #190
HelloNurse wrote: post #116

Earlier quoted context omitted.

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?

If this is your scenario, the attacker runs in its own emulator. A fairly thick pair of gloves, but not enough to prevent exploiting speculative execution vulnerabilities and reaching outside the emulator to poke into other processes.

As another comment points out, attacks from Javascript code that escape the browser sandbox have been demonstrated, which is exactly your sandboxing scenario minus the easy part of targeting what an emulator is emulating.

Re: More Intel speculative execution vulnerabilities

#253

Post by voidmain »

hansendc wrote: post #230
voidmain wrote: post #111

Can we please have an architectural MSR to disable TSX?

The good news: There's a new MSR which lets you do this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future.…

...speculation attacks, and outright bugs in TSX, and the fact that even when everything is working it's a timing mechanism that VMX can't intercept. I really hope it becomes architectural (and gains a bit for HLE)!

Re: More Intel speculative execution vulnerabilities

#254

Post by MiroF »

scandinavian wrote: post #129
MiroF wrote: post #126

Earlier quoted context omitted.

> There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). sure dude, sure

Chrome: CVE-2019-13720, CVE-2019-5786 Firefox: CVE-2019-11707/CVE-2019-11708 Your turn. Link the speculative execution 0days.

Here's an example of post-mitigation reading of protected memory using Javascript and Spectre https://alephsecurity.com/2018/06/26/spectre-browser-query-c...

I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.

Re: More Intel speculative execution vulnerabilities

#255

Post by alkonaut »

HelloNurse wrote: post #252
alkonaut wrote: post #190

Earlier quoted context omitted.

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?

If this is your scenario, the attacker runs in its own emulator. A fairly thick pair of gloves, but not enough to prevent exploiting speculative execution vulnerabilities and reaching outside the emulator to poke into other processes. As another comment points out, attacks from Javascript code that escape the browser sandbox have been demonstrated, which is exactly your sandboxing scenario minus the easy part of targ…

> attacks from Javascript code that escape the browser sandbox have been demonstrated

As far as I understand you still need to be able to have some kind of timing information or cpu state available in the sandboxed program, which is possible if the emulator/sandbox runs close enough to the metal (Such as a js program in a modern browsee, because they need to be fast). Remove ALL timing info and it should be possible to make it impossible to exploit speculative execution. It might run 1000x or 10000x slower than a modern JS engine however.

Re: More Intel speculative execution vulnerabilities

#256

Post by repolfx »

hansendc wrote: post #230
voidmain wrote: post #111

Can we please have an architectural MSR to disable TSX?

The good news: There's a new MSR which lets you do this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The less good news: as far as I can tell, Intel did not commit to how architectural this will be going forward. Considering the role TSX has played in speculation-based attacks, it appears to me to be a generic mitigation that would be great to accompany TSX wherever it is available in the future.…

Ah, but TSX is also used to block attacks (on SGX enclaves). So just disabling it entirely seems over simple.

Re: More Intel speculative execution vulnerabilities

#257

Post by jdsully »

kllrnohj wrote: post #237
jdsully wrote: post #212

Earlier quoted context omitted.

They get that IPC on a better process. Shorter gate delays let you pack more into each cycle. IPC can't be divorced from process when comparing architectures.

IPC is from design not from transistor density. Clock speed is what can't be divorced from process. IPC can be. More transistors could enable new designs not previously feasible, but we've loooong since past that point (hence why most new transistors are just being dumped into L3 cache)

Part of the driver of IPC is how many layers of logic you can fit between each pipeline register. We’re not talking density we’re talking logic gate delay.

Each process has different delay, setup, and hold times. On one process I might be able to fit 15 layers of logic before I have to add a pipeline stage. On another I might be able to fit 20 at the same frequency. Pipeline stages are also not free with each adding additional overhead.

This determines how advanced I can make things like my branch predictor or cache pre-fetcher while still meeting timing requirements. For example I might want a larger lookback buffer but I can’t use a larger memory - not because of how much area it takes but because it simply takes too long to do the look up now.

Re: More Intel speculative execution vulnerabilities

#258

Post by scandinavian »

MiroF wrote: post #254
scandinavian wrote: post #129

Earlier quoted context omitted.

Chrome: CVE-2019-13720, CVE-2019-5786 Firefox: CVE-2019-11707/CVE-2019-11708 Your turn. Link the speculative execution 0days.

Here's an example of post-mitigation reading of protected memory using Javascript and Spectre https://alephsecurity.com/2018/06/26/spectre-browser-query-c... I think it's just silly that you would rely on browser mitigations like disabling high precision timers when that's obviously just a hack.

As is said in the PoC, it does not bypass index masking and site-isolation. They read data already available to the code they are executing. They did show that the timer resolution mitigation is not 100% effective, which is well known and why it is not the only mitigation.

That's not a speculative execution browser 0day, as it doesn't work in updated browsers and it never has (or I guess it works if you want to leak data you could just console.log). Could you post an actual 0day instead?

Re: More Intel speculative execution vulnerabilities

#259

Post by wolf550e »

renox wrote: post #251
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.

Web browsers didn't (still don't AFAIK) use one process per website visited..

They do: https://developers.google.com/web/updates/2018/07/site-isola...

Re: More Intel speculative execution vulnerabilities

#260

Post by MaxBarraclough »

segfaultbuserr wrote: post #245
MaxBarraclough wrote: post #236

Earlier quoted context omitted.

> Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything At the risk of sounding pedantic, that's not 'full disclosure', that's 'responsible disclosure' - https://en.wikipedia.org/wiki/Responsible_disclosure

Is it? I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero is responsible disclosure because the information is released after the problem is patched. I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".

> I think "Responsible Disclosure" involves cooperation with the vendor before releasing any information, e.g. Project Zero

Good point.

> I label all disclosure of unpatched vulnerability without cooperation with the vendor as "Full Disclosure".

If you aren't disclosing everything you have, it's not full disclosure, it's some other disclosure model.

I think we're just arguing semantics though, as I fully agree with your earlier paragraph, that hardware vulnerabilities are trickier than software vulnerabilities regarding disclosure, and that Project Zero is doing roughly the right thing.

Post reply on HN