[HN Gopher] Cross-Process Spectre Exploitation
___________________________________________________________________
Cross-Process Spectre Exploitation
Author : todsacerdoti
Score : 45 points
Date : 2024-10-18 17:19 UTC (1 days ago)
(HTM) web link (grsecurity.net)
(TXT) w3m dump (grsecurity.net)
| _tk_ wrote:
| See original paper here:
|
| https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf
| nolist_policy wrote:
| > The overwhelming majority of software authors are unconcerned
| about cross-process Spectre attacks, indicated by the fact that
| none of them enable IBPB. The only exception I've seen is Google
| Chrome.
|
| As expected, Google goes the extra mile again to keep their users
| safe.
| akyuu wrote:
| I believe Chrome is also the only software that enables certain
| mitigations such as ProcessSystemCallDisablePolicy on Windows
| and NO_SMT and TECS on macOS [1]. I wonder if some of these OS
| features have been implemented at Google's request.
|
| However, in the case of Spectre, I think the OS should try to
| prevent exploitation rather than end programs, with a user-
| facing toggle to disable mitigations per-program for
| compatibility reasons.
|
| [1]
| https://www.malwarebytes.com/blog/news/2021/08/macos-11s-hid...
| kelsey98765431 wrote:
| misleading as chrome has recently gone to the trouble of
| removing adblock from their browser at a plumbing level,
| opening users up to malicious advertisements and trackers in
| search of google ad revenue. do not use chrome for the love of
| god.
| wslh wrote:
| Genuinely asking, regarding Spectre (including ARM), does it
| really push the argument towards running sensitive software
| outside the cloud, even when it's resource-wise convenient? Sure,
| owning your hardware gives you control, but the key to mitigating
| Spectre is isolation. If your cloud provider can guarantee that
| your VMs aren't sharing physical resources with other customers
| (or that those resources are strongly isolated), then the Spectre
| risk is arguably comparable to running on your own hardware. Top
| cloud providers have more resources and expertise to dedicate to
| security updates and mitigations than a smaller operation. Maybe
| the real question isn't 'cloud vs. on-premise', but rather 'how
| well-isolated am I from other tenants in any environment?
| JackSlateur wrote:
| Yes, the "cloud vs on-prem" is not really interesting. Because
| one project must be well isolated from other projects,
| regardless of their owners : as such, inside a single compagny,
| we must isolate all projects from each others.
|
| Do not fall into the "I put production on one side and
| preproduction on the other"
|
| Cloud providers allows great isolation, even if many people
| fail to implement this (for instance, by using VPC-peering /
| network hub / shared VPC / whatever).
|
| Indeed, one could implement this "on-prem": vxlan and friends
| are there for you. It does require some skills, tho.
|
| I believe the backbone of infrastructure security lies in two
| pieces: first, the ability to deploy stuff easily, quickly,
| autonomously. Then, the ability to deploy stuff with no cost
| overhead (no "price per project" or whatever).
| titzer wrote:
| From the writeup, it appears that microcode doesn't completely
| flush indirect branch predictions when instructed to do so, which
| leads to known cross-process attack techniques working again.
|
| Frankly I'm not surprised. Beyond the initial scramble to deal
| with the huge open barn door that the first variants represented,
| the temperature on side channel attacks cooled for a bit. Given
| that it's extremely difficult to test _any_ mitigation, due to
| noise, etc, it 's not hard to imagine how this slipped through.
|
| The performance/security tradeoff we constantly face in this area
| seems to be constantly drawn on the side of performance. Most
| people seem to believe that they're mostly running trusted code
| on their computers, and that trusted code shouldn't need security
| mitigations. I challenge that, as native applications,
| particularly on multi-user systems, already have a security model
| that is being violated by cross-process attacks. We shouldn't
| have the situation where some random third-party app has access
| to data in other processes, even if both are running as the same
| user. People working on the Linux kernel no doubt have a spectrum
| of opinions, but it's clear that the very, very conservative
| approach they've taken to mitigation puts performance as the #1
| priority, which is exactly the default that got us into this
| situation.
| davikr wrote:
| I hate losing desktop CPU performance to an issue that would
| never affect me.
| tonetegeatinst wrote:
| Is the old pentium safe? Or the and fx CPUs?
|
| I love how far and and Intel have come, and how you can get a
| massive arm CPU, but these modern hardware security issues seem
| to be a more frequent issue(is this true?) And to stop them one
| takes a decent performance penalty..... Which is way less than
| ideal.
| Paianni wrote:
| I think everything from Pentium Pro (except Bonnell-based
| Atom), AMD K5, Cyrix 6x86 and VIA Nano onwards is vulnerable.
___________________________________________________________________
(page generated 2024-10-19 23:01 UTC)