[HN Gopher] Retbleed: New speculative execution attack sends Int...
___________________________________________________________________
Retbleed: New speculative execution attack sends Intel and AMD
scrambling
Author : ndesaulniers
Score : 215 points
Date : 2022-07-12 16:07 UTC (6 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| runlevel1 wrote:
| Are we at the point where it's irresponsible to run on shared
| tenant infrastructure?
|
| There seems to be no end to these attacks. Just brief periods of
| remission.
| yomkippur wrote:
| I'm convinced that cybersecurity is impossible. Any entity with
| the resources and command over talent and determination is
| capable of defeating any counter measures in the long run.
|
| It's like trying to fill up a bucket but by the time you find the
| hole and patch it, another one appears constantly, leading to
| exhaustion.
|
| Perhaps with AI we can drastically lower the cost of this
| exhaustive effort but so can the other side, employing AI to
| increase the cost.
|
| It would be like a never ending tug of war that just ends up
| taking up more and more resources, sort of like the nuclear arms
| race of the 60s which was only curtailed by both sides agreeing
| to commonly beneficial compromises.
| ethbr0 wrote:
| Cybersecurity and quick software/hardware development are
| impossible.
|
| There are plenty of _much_ more secure systems.
|
| They just iterate _much_ more slowly, and are consequently
| _much_ lower-performance or less-featured.
|
| For an extreme example, see what IoT's recent "all features,
| quickly" craze has done to their security posture.
| [deleted]
| bredren wrote:
| Here's the moneyshot:
|
| > Retbleed can leak kernel memory from Intel CPUs at about 219
| bytes per second and with 98 percent accuracy. The exploit can
| extract kernel memory from AMD CPUs with a bandwidth of 3.9 kB
| per second.
|
| > The researchers said that it's capable of locating and leaking
| a Linux computer's root password hash from physical memory in
| about 28 minutes when running the Intel CPUs and in about 6
| minutes for AMD CPUs.
| yomkippur wrote:
| so basically passwords are useless on these CPUs? What can we
| do? Use playstation 2 hardware to run linux?
| jacooper wrote:
| These are password hashes, not the password it self.
| photon-torpedo wrote:
| The root password _hash_ is not sufficient to log in as root,
| but knowing the hash enables an attacker to run an offline
| brute-force attack to crack the password. Depending on the
| password complexity, this may or may not be feasible.
|
| That said, this attack may be able to extract other
| information from system memory that would enable de-facto
| root access, it depends a lot on what's running on the
| machine.
|
| > What can we do?
|
| Install the patches and enjoy the reduced performance. Or run
| Linux on ARM, and hope that noone will find similar exploits
| in the ARM architecure.
| yomkippur wrote:
| So how complex does the password need to be?
|
| What if you have a 32 character password with mostly
| symbols, punctuations and non sensical strings mixed
| together?
|
| It seems like as quantumn computing gets better it would be
| a matter of time for them to crack any password going
| forward.
|
| Do we need an entire passage of the bible transformed into
| a password? I just assume it would be a lot more difficult
| to find the chimpanzee on the typewriter that can write a
| page from the bible purely by trial and error. That would
| take light years is my thinking but I could be wrong.
| nomel wrote:
| For an Nvidia 3090, you you can do around [1]:
|
| MD5: 65 trillion guesses/second
|
| SHA-512: 2 trillion guesses/second
|
| Blowfish: 100k guesses/second
|
| My root password is fairly short, since I type it all the
| time. I would be screwed if anyone had interest. I don't
| think relatively short root passwords are all that
| uncommon.
|
| 1. https://gist.github.com/Chick3nman/e4fcee00cb6d82874da
| ce7210...
| pishpash wrote:
| Use physical tokens. Passwords is not the future.
| Yuioup wrote:
| OpenBSD disables hyperthreading by default.
|
| There's that, I guess...
| causi wrote:
| I wonder if eventually we'll have to have a "secure mode"
| operational setting where all speculation is disabled along with
| other extreme security measures any time a computer needs to
| handle credentials.
| yababa_y wrote:
| dedicating a single core to the task and interfacing with
| existing secure enclave / smart card like protocols would get
| you pretty far.
| inetknght wrote:
| Cores can share cache. Cache leaks from speculation are a
| thing. So dedicating a single core might not be strong enough
| countermeasure.
|
| There's of course little other recourse _without_ a secure
| processor. I will be very saddened when a secure processor
| becomes required standard hardware because it will, no doubt,
| contain only phantom blobs that hinder ownership and promote
| corporate bullshit.
| rasz wrote:
| You can speculate all you want, just dont Fking share the state
| between cores/threads/processes.
| throwawaylinux wrote:
| No, you can't. Many speculation vulnerabilities have been
| single-threaded.
| marshray wrote:
| My understanding is that flushing all cache and other state
| on every thread/process context switch has a big performance
| impact.
| zozbot234 wrote:
| You don't need to flush predictor state on _every_ task
| switch, only when entering a less private context from a
| more private one. Systems with a feature known as multiple-
| level security (or "multiple levels of security") can be
| designed to track these privacy/information requirements
| automatically.
| marshray wrote:
| I'm not familiar with this concept of a "less private
| context" in computing.
|
| Could you please link me to something I can read about
| it?
| rasz wrote:
| No need to flush cache if we could have all the caches
| tagged per process.
| marshray wrote:
| But then shared libraries would have to be duplicated in
| the I-cache.
| pishpash wrote:
| Space-privacy tradeoff, sounds fair.
| 1over137 wrote:
| >"secure mode" operational setting where all speculation is
| disabled
|
| We have that, it's called OpenBSD. :)
| systems_glitch wrote:
| On SPARC64 or POWER.
| itvision wrote:
| Yeah, in this mode the CPU will just work 10 times slower.
| jl6 wrote:
| Today's episode of Modernity Is Built On Sand...
|
| I'm not clear why Windows is unaffected. Does Windows already use
| the recommended mitigations, and if so does it already suffer
| from the performance penalty?
| hatenberg wrote:
| windows uses a different mitigation, nor retpoline so it's not
| affected.
| kwertyoowiyop wrote:
| This is what happens when we stray beyond the true path: 6502.
| spogbiper wrote:
| the 6809 was better
| NegativeLatency wrote:
| IDK might be some danger lurking in all those extra
| instructions :)
| crest wrote:
| Just patch your compiler/macro assembler to insert HCF
| instruction before any conditional control flow
| instructions.
| uniqueuid wrote:
| Oh no, not again.
|
| If there are enough of these attacks that don't involve ARM (I
| know some do), then I see a bright future for ARM servers.
|
| [edit]: Curious to see if Zen3 is also affected - if not, that
| would be great news.
| adrian_b wrote:
| The researchers have tried their method against AMD Zen 3,
| Intel Alder Lake and Coffee Lake Refresh (a.k.a. 9th Generation
| Core) and it did not work against those.
|
| Intel Coffee Lake (a.k.a. 8th Generation Core) or older and AMD
| Zen 2 or older are vulnerable.
| btdmaster wrote:
| Where does it say that older (Intel 5th generation and
| earlier) versions are affected?
| adrian_b wrote:
| They have not tested CPUs older than AMD Zen 1, but based
| on the similar branch predictors they suppose that
| Bulldozer derivatives and Jaguar/Puma might also be
| vulnerable.
|
| Similarly, on Intel they have not tested CPUs older than
| Kaby Lake, but due to the similar branch predictors they
| suppose that Skylake, Broadwell and Haswell might also be
| vulnerable.
|
| Older CPUs than that might not have indirect branch
| predictors or the indirect branch predictors might be too
| simple, so this attack method might not be applicable.
| btdmaster wrote:
| I'm probably doing it wrong, but I'm getting SIGILL on
| Haswell for ret_bti and break_kaslr from the demo:
| https://github.com/comsec-group/retbleed
|
| Though it seems like the code is not portable (?) between
| CPU microarchitectures.
| adrian_b wrote:
| Since the attack method depends heavily on details of the
| indirect branch predictor obtained through reverse
| engineering, it is very likely that the code must be
| adapted to each different microarchitecture.
|
| The demo code probably also works in Skylake, which is
| almost identical to Kaby Lake, but for Haswell and
| Broadwell it probably must be modified, even if it is
| expected that this should be possible.
| ndesaulniers wrote:
| Check the list from the Linux kernel patches:
|
| ``` + VULNBL_INTEL_STEPPINGS(SKYLAKE_L, X86_STEPPING_ANY, SRBDS
| | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(SKYLAKE_X,
| X86_STEPPING_ANY, MMIO | RETBLEED), +
| VULNBL_INTEL_STEPPINGS(SKYLAKE, X86_STEPPING_ANY, SRBDS | MMIO
| | RETBLEED), + VULNBL_INTEL_STEPPINGS(KABYLAKE_L,
| X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), +
| VULNBL_INTEL_STEPPINGS(KABYLAKE, X86_STEPPING_ANY, SRBDS | MMIO
| | RETBLEED), + VULNBL_INTEL_STEPPINGS(CANNONLAKE_L,
| X86_STEPPING_ANY, RETBLEED), +
| VULNBL_INTEL_STEPPINGS(ICELAKE_L, X86_STEPPING_ANY, MMIO |
| MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE,
| X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), +
| VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0),
| MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L,
| X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), +
| VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPING_ANY, MMIO |
| MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(ROCKETLAKE,
| X86_STEPPING_ANY, MMIO | RETBLEED),
|
| + + VULNBL_AMD(0x15, RETBLEED), + VULNBL_AMD(0x16, RETBLEED), +
| VULNBL_AMD(0x17, RETBLEED), + VULNBL_HYGON(0x18, RETBLEED), ```
|
| (I believe that zen3 is not affected)
|
| Via:
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
| trdtaylor1 wrote:
| Doesn't appear to be, additionally Windows deployments are not
| affected.
|
| Per Intel - "Note that Windows systems are not affected given
| that these systems use Indirect Branch Restricted Speculation
| (IBRS) by default which is also the mitigation being made
| available to Linux users."
| olliej wrote:
| It appears to be an attack specifically on the retpoline
| approach the Linux used to prevent the original specter
| attacks. Given it appears that Linux is the only OS that took
| that approach they're the only one vulnerable? (The article
| explicitly calls out Linus ignoring warnings about this
| possibility)
| gpderetta wrote:
| Linux claimed it was not practical. Is this attack actually
| practical? Are 200-3kb/s sufficient for a realistic attack?
| holycrapwhodat wrote:
| > Are 200-3kb/s sufficient for a realistic attack?
|
| Yes.
| marshray wrote:
| So how many seconds would it take to leak your password
| at that rate?
| olliej wrote:
| Per the article 5-7 minutes for the root hash on the
| effected AMD systems?
|
| I'm guessing that's also not doing any kind of actual
| targeted traversal because if you can just do a heap walk
| you don't need anywhere near that amount of data.
| pishpash wrote:
| First dialup connections were 1200bps. Earlier adhoc
| connections were lower.
| staticassertion wrote:
| Someone should create an index of "Linus said this attack
| was impractical/ unimportant". I can think of a number of
| great examples off the top of my head.
| rayiner wrote:
| In general, these attacks leverage the microarchitectural
| details of processors that implement speculative execution
| (which is nearly any modern processor). ARM processors can
| differ in their microarchitecture, so this particular exploit
| may or may not apply to them. It's not necessarily an "ARM"
| versus "x86" thing. (This specific exploit applies to a
| mitigation, retpoline, implemented in Linux. It appears that at
| least some ARM processors are vulnerable to the speculation
| attacks that make retpolines necessary in the first place: http
| s://www.phoronix.com/scan.php?page=news_item&px=Google-L...)
| pishpash wrote:
| Doesn't change the practical effect of being slightly safer
| than the neighbor.
| alasr wrote:
| From the FAQ of ETH Zurich's "Computer Security Group" website:
|
| > Are only Linux systems affected?
|
| > We've built the proof of concept code for Linux. But, because
| the fundamental issue is at the hardware level, Microsoft and
| Apple computers with the affected hardware have this issue too.
|
| --
|
| [1] https://comsec.ethz.ch/research/microarch/retbleed/
| tester756 wrote:
| >"Note that Windows systems are not affected given that these
| systems use Indirect Branch Restricted Speculation (IBRS) by
| default which is also the mitigation being made available to
| Linux users. Intel is not aware of this issue being exploited
| outside of a controlled lab environment."
|
| hmm?
|
| so, how is it?
| DethNinja wrote:
| How this exploit would affect the average ssh based system? Would
| it enable a privilege escalation path for password-less SSH key
| based accounts?
|
| Also, I thought it was common sense that sensitive data on RAM
| should be scrambled after use. There are many TLS implementations
| that scramble data on RAM after use, I thought Linux would've
| already implemented a similar system.
| flatiron wrote:
| You need to be able to run code on a machine. So server that
| you cannot log into isn't vulnerable. This is for malware
| running as an executable or possible JavaScript through the
| browser (maybe web assembly too)
| pantalaimon wrote:
| Browsers don't expose the high accuracy time sources anymore
| that are needed for this attack.
| rayiner wrote:
| When will people realize that the problem is running untrusted
| code on the same CPU as code that needs to keep secrets?
| staticassertion wrote:
| Is that the problem?
|
| 1. Most hosts have some secrets. For example, client
| credentials. That's hard to avoid unless you just don't do auth
| at all.
|
| 2. Most hosts let users ssh to them.
|
| 3. What you've described is the cloud provider/ PaaS model.
|
| 4. It's not that easy to just "keep untrusted code" out. Like,
| what if an attacker exploits an exposed service and then wants
| to privesc?
| bombcar wrote:
| The problem is cloud, basically, where you're defined by
| running various VMs on the same CPU.
|
| Single-user systems can be affected by these, but they can be
| affected by more direct attacks.
| merb wrote:
| on clouds the only problem is HT. on vm providers it's cpu
| overcommitment (clouds rarely do that)
| [deleted]
| superkuh wrote:
| Back in the 2000s pretty much everyone knew not to run un-
| trusted code ("don't open that email attachment"). But then
| javascript happened and the utility was so profound everyone
| decided to forget.
| ginko wrote:
| Can't you mitigate just the Javascript VM? JS is a slow
| scripting language anyways. Seems like a waste to slow down
| the entire system.
| selfhoster11 wrote:
| Even if it's far from obvious to an average person that
| JavaScript is a pwn vector, I think you're more correct than
| not. You need enough isolation to run untrusted code. If JS
| code can still exploit CPU bugs, then clearly more isolation
| is needed one way or another.
| marshray wrote:
| People have been running code having different security
| levels on the same hardware since the early time-sharing
| systems (1960's).
| mirashii wrote:
| I think you're looking at the past with rose-colored glasses.
|
| ActiveX allowed the execution of unsandboxed x86 code from
| controls embedded in webpages and was enabled by default in
| Internet Explorer, the dominant browser of the time.
|
| Javascript caught on because it's at least interpreted and
| sandboxed, a huge step up from what ActiveX was.
| tedunangst wrote:
| I only have so many CPUs, and I visit more websites than that.
| jvanderbot wrote:
| This actually doesn't make sense. Any trusted code can
| absolutely run on a trusted processor, and the usual
| timesharing methods will handle your stackoverflow tabs.
| tedunangst wrote:
| So you use the same password for SO and HN?
| jvanderbot wrote:
| I have no idea what that means relative to this
| conversation. Either I'm out of my depth or we're talking
| past each other. Either way, no big deal.
| tedunangst wrote:
| If you use different passwords, you must believe they are
| in different trust zones, and the usual time sharing
| methods won't work, in light of this and many other
| attacks. You will need separate CPUs as suggested by
| rayiner.
| idle_zealot wrote:
| You can run trusted code on one processor and untrusted
| on another. The untrusted processor must not perform
| speculative execution. It'd be slow but should solve the
| presented conundrum.
| dzaima wrote:
| Unfortunately, being slow is just not acceptable in a
| decent portion of scenarios. Web developers won't start
| writing 5x faster sites, and cloud providers won't like
| needing 5x more hardware to serve the same amount of
| virtual CPU performance. (5x being my random guess of the
| performance decrease from losing speculative execution &
| co; it'd likely be even worse, especially combined with
| the fact that manufacturers would have to design a
| completely new chip)
| czinck wrote:
| Their point is untrusted code can still have private info
| (I don't want a random website to be able to steal my
| private key or my info like credit cards or password in
| other tabs), so you need a new core for each website,
| which is obviously impractical.
| trasz wrote:
| They aren't in different trust zones, because there's
| nothing to trust in either of those. The reason for using
| different passwords is to minimize the losses when they
| leak.
| lsbehe wrote:
| Consider disabling javascript on websites by default and only
| allowing it on those that you trust. e.g. uBlock origin has
| that built in. You'd be surprised how much still works
| perfectly fine and of cause, which sites break for no good
| reason.
| hgazx wrote:
| I want an extension that disables JavaScript by default and
| then allows me to enable and disable JavaScript for the
| current site that I'm visiting (and all of its
| dependencies; I don't want to deal with enabling it also
| for its cdns etc) with only one click and then remembers my
| setting. Does that exist?
| boring_twenties wrote:
| NoScript used to do it in 1 click. Now that it's a Web
| Extension, it takes two.
| simcop2387 wrote:
| Umatrix from the author of ublock origin can do this. Not
| with a single click (it'll take two, one to enable and
| one to tell it to remember) but it's very close.
|
| https://addons.mozilla.org/en-US/firefox/addon/umatrix/
| [deleted]
| monocasa wrote:
| It's a way deeper problem than untrusted code, as NetSpectre
| [0] showed.
|
| The issue is with untrusted speculative instruction streams
| which can be influenced by untrusted code _and /or_ untrusted
| data. NetSpectre was a remote kernel read primitive entirely
| from malformed network packets, no untrusted code needed, and
| no data other than network packets coming in over the wire.
|
| [0] https://gruss.cc/files/netspectre.pdf
| naniwaduni wrote:
| Really, the problems all started from secrets existing in the
| same universe as untrusted actors.
| tptacek wrote:
| This is about as trenchant an analysis as "when will people
| realize that the problem is computers?". The constraint we work
| with when securing systems is that we don't get to rearchitect
| the entire world; that's what makes systems security hard.
| rayiner wrote:
| As a security guy, you're stuck with the world as it is. But
| as a mere user, I can certainly complain about the direction
| computing has gone.
| saagarjha wrote:
| Systems security people can complain too, but just like
| they can't change things neither can you :(
| ndesaulniers wrote:
| > when will people realize that the problem is computers?
|
| That's how I feel though some days, tbh.
| daniel-cussen wrote:
| At least don't share the same core. There's gotta be some
| limit.
| msbarnett wrote:
| Is that even enough? Hyperthreading let some of the earlier
| spectre exploits work _faster_ , but as long as there's
| some shared cached between two cores (L2 or L3), that's
| enough for timing variations to leak what's in that cache
| afaik. Maybe it's enough for this attack (unsure), but I
| don't think it solves speculative side-channel leaks in
| general.
| scottlamb wrote:
| IIUC on Linux you can enable
| CONFIG_SCHED_CORE/PR_SCHED_CORE to realize that idea. [1]
| Some caveats may apply...
|
| edit: to be clear, I just learned about retbleed five
| minutes ago, so I'm definitely not promising core
| scheduling mitigates it. I do think core scheduling is a
| good idea in general.
|
| [1] https://www.kernel.org/doc/html/latest/admin-guide/hw-
| vuln/c...
| wglb wrote:
| I am unclear on how this relates to untrusted code.
|
| Regardless of your programming language, the low-level machine
| code is vulnerable. At some point, passwords and other
| sensitive data is in the memory, and by using these exploits,
| they can be exposed.
|
| Alternatively, let's be sure that the attackers are not running
| untrusted code.
| jjnoakes wrote:
| > I am unclear on how this relates to untrusted code.
|
| If you only run code you trust, then (assuming your trust was
| placed in it properly) it won't steal anything from you.
| [deleted]
| usr1106 wrote:
| Maybe a stupid question...
|
| For user machines running JavaScript in the browser is the most
| common case of running untrusted code. Since 2018 when Spectre
| became public, has a single JavaScript program become public that
| exploits Spectre (whatever variant)? Unpatched user machines
| exist proably all the time.
|
| For the cloud where your neigbors might run whatever (bad) they
| come up with is this just a simple Linux vulnerability? (Or HW
| vulnerability Linux did not work-around well enough) Wouldn't you
| alway need to attack the hypervisor? Of course, that might be
| Linux, too. Has there been any piece of software published that
| just reads your neighbors memory? Of course major cloud providers
| patch at disclusure, but I'm sure there are smaller ones where it
| can take a long time.
|
| If yes, how could I miss that? If no, Linus hasn't been that
| wrong that the attacks are not feasible. Unless one assumes the
| NSA has been running them since 2018.
| userbinator wrote:
| Yes, JS demos existed, but the usefulness of the data you can
| extract was limited. Making sense of the extracted data has
| always been the difficult part, as even if you manage to find a
| key and can recognise it as such, you still need to know what
| it's securing and also have access to do anything more.
| zdragnar wrote:
| Google had a decent writeup and proof of concept for leaking
| via JavaScript:
|
| https://security.googleblog.com/2021/03/a-spectre-proof-of-c...
|
| As for clouds, "retpoline" is (was?) a common measure taken
| against spectre v2, as seen in this fairly old post:
|
| https://cloud.google.com/blog/topics/inside-google-cloud/ans...
|
| What retbleed means for this is anyone's guess, but I'd hazard
| a thought that it's not great.
| [deleted]
| cosmiccatnap wrote:
| I think speculation... Is just not in the cards for most use
| cases.
|
| Yes you can isolate cores and you can encrypt the data and use
| enclaves and all that with much effort and complexity and
| overhead might eventually fix the 90th percentile but in the end
| the core issue is simply the nature of speculation as a strategy
| to improve cpu performance.
| stu2b50 wrote:
| IMO it's the reverse. Not having speculation absolutely
| cripples processor performance. For most use cases, it's
| clearly better to have the performance but accept the risk of
| these vulnerabilities.
|
| In the cases for which this is not true we need to selectively
| lock down speculative execution.
| userbinator wrote:
| _The researchers said that it's capable of locating and leaking a
| Linux computer's root password hash from physical memory in about
| 28 minutes when running the Intel CPUs and in about 6 minutes for
| AMD CPUs._
|
| Presumably under very ideal conditions? I've been indifferent to
| all these sidechannel attacks since the original Spectre/Meltdown
| and continue to maintain my opinion that this is really not of
| any significance to a single-user PC.
| layer8 wrote:
| It seems likely that if no mitigations were made available,
| actual attacks would eventually surface. That aside, other
| attack vectors are currently still much easier to target. The
| interesting thing about side-channel attacks, compared to other
| attack vectors, is that they can't be addressed without
| impacting performance.
| itvision wrote:
| Nothing has surfaced for the past four years that all these
| vulnerabilities were revealed. Not a single piece of malware
| uses any of https://en.wikipedia.org/wiki/Transient_execution
| _CPU_vulner...
| whizzter wrote:
| That we know of! Since timing attacks like this probably
| needs a bit of machine specific tuning it's probably not
| that much of an interest to regular mass-market attackers.
|
| But for APT groups that might need a wedge on particular
| machines it might be worthwhile, remember the length NSO
| group went with Pegasus.
| inetknght wrote:
| > _I 've been indifferent to all these sidechannel attacks
| since the original Spectre/Meltdown and continue to maintain my
| opinion that this is really not of any significance to a
| single-user PC. _
|
| The original attacks worked in javascript that could be
| delivered by a browser to your single-user PC. Being able to
| steal secrets -- passwords, bank account information, ephemeral
| encryption keys to other sites -- is absolutely very
| significant to single-user computers.
|
| Dismissing it without consideration for mitigations is
| malicious IMO.
| throw93232 wrote:
| It seems disabling JIT on JS VM and only using slow
| interpreted mode is a good choice.
| hawk_ wrote:
| is it possible to disable JIT on chrome or Firefox?
| codedokode wrote:
| Also in this case memory consumption will be lower because
| JIT'ed code takes space. I think that it is a good idea.
| azinman2 wrote:
| Has anyone produced meaningful benchmarks on real world
| websites? If I go to arstechnica, or NYTimes, or gmail --
| what will the difference be between JIT and non-JIT for
| page load and common operations?
| icedchai wrote:
| There was never a real world exploit that did anything like
| that. They were all POCs that read data from themselves under
| ideal conditions.
| bravetraveler wrote:
| Say that were true - you knew all of the valued zero-days,
| attacks, etc - and determined nothing happened _yet_
|
| The plan for the future is... what? Pray that nobody ever
| makes it practical?
|
| I'm not saying anyone should lose sleep, that's silly - but
| disregarding a vector because there haven't been
| demonstrations in the wild is also silly.
|
| The first, and then likely a collection, will be discovered
| and traded on black markets. Eventually it'll leak, and
| _then_ we 'll know about it.
| icedchai wrote:
| I feel that exfiltrating memory at a few hundred
| bytes/sec makes it extremely impractical. You'll be
| looking for a needle in a haystack. There are easier,
| faster attacks available. I won't lose sleep over it.
| saagarjha wrote:
| That's because mitigations were rolled out very quickly.
| icedchai wrote:
| True, though I find it hard to believe there are still no
| real world exploits.
| saagarjha wrote:
| There might be! But I haven't heard of anything publicly
| yet.
| rasz wrote:
| >The original attacks worked in javascript that could be
| delivered by a browser to your single-user PC
|
| no they didnt, otherwise there would be a demo page you could
| use right now to check if you are susceptible
| nteon wrote:
| Yes they did. Here is one such demo: https://leaky.page/
| rasz wrote:
| I have never patched even once 2018 install of win10
| running chrome on intel Haswell, this demo fails to do
| anything.
| tuckerman wrote:
| Out of curiosity is it also using a circa-2018 chrome
| install? There have been mitigations pushed to Chrome and
| V8.
| rasz wrote:
| June build Chrome/102.xxx. I just tried 96.xx and
|
| [!] error: could not infer memory layout [ _] retrying.
| (2 retries left) [!] error: could not infer memory layout
| [_ ] retrying. (1 retries left) [!] error: could not
| infer memory layout [!] no retries left
|
| Btw some parts (maybe whole thing??) uses WebAssembly and
| not just js.
| [deleted]
| inetknght wrote:
| Browsers have since added their own mitigations. Chrome
| has certainly come up with their own set of mitigations
| [0].
|
| Nonetheless, a lot of hardware still remains unpatched
| and vulnerable. Do you install games? Do you install mods
| to your games? Do you fully trust every game author and
| mod author? Pro tip: you shouldn't; games can do it even
| easier. Don't do your business or finances on your gaming
| PC.
|
| [0]: https://developer.chrome.com/blog/meltdown-spectre/
| pantalaimon wrote:
| Games don't run in a sandbox, they can already access all
| user data as is.
| ClumsyPilot wrote:
| some games have anti-cheat softeare that runs in admin
| mode 24/7
| bravetraveler wrote:
| Like, super mega admin mode -- many run in the kernel
| nowadays!
| TheDong wrote:
| That specific PoC page relied on performance.now()
| https://github.com/google/security-research-
| pocs/blob/d10780...
|
| Chrome has limited "performance.now" to have a relatively
| low resolution: https://chromium-
| review.googlesource.com/c/chromium/src/+/85...
|
| Also, "2018 install of win10", you might have already
| been patched during install. The chrome patch was Jan
| 2018.
|
| Microsoft also rolled out their first specture/meltdown
| mitigations at the OS level in January 2018.
| rasz wrote:
| In March 2021 Google released proof of concept for
| something patched since 4 years?
| password4321 wrote:
| The associated March 2021 blog post mentioned
| implementing multiple PoCs abusing different timers; the
| one chosen was verified "on Chrome 88 on an Intel Skylake
| CPU", which was released January 2021.
|
| A cursory search did not find what further mitigations
| have been implemented since 2021.
| rasz wrote:
| So in the end it turns out there doesnt exist "a demo
| page you could use right now to check if you are
| susceptible" after all because browsers removed attack
| surface (precise timers).
| TheDong wrote:
| > So in the end it turns out there doesnt exist "a demo
| page you could use right now to check if you are
| susceptible" after all because browsers removed attack
| surface
|
| The original claim you made was "[the original attacks]
| didn't [work in javascript], otherwise there would be a
| demo page".
|
| We have shown you such a page. You are not susceptible to
| that original attack anymore. Congrats. Isn't that all
| you were asking for? How have we not proven exactly that
| exists?
|
| We haven't shown you that you are still presently
| susceptible to anything of course, but that's not what
| you were claiming.
|
| And it's of course impossible to prove that you are not
| susceptible to any bug whatsoever, though I don't think
| many people would be surprised if there were still
| sources of accurate timing left in the browser
| rasz wrote:
| The linked page is not js, its js deferring actual attack
| to wasm. It doesnt work on 2018 system despite the demo
| being released in 2021.
| causi wrote:
| Indeed. I'm not going to hamstring my computer to guard against
| something that not only requires poor security practices on
| behalf of the user but is next to nonexistent in the wild.
| hsbauauvhabzb wrote:
| It's cheaper to not use them, for now. As attack cost of easier
| attacks increases, so will adversary sophistication
| foresto wrote:
| > my opinion that this is really not of any significance to a
| single-user PC.
|
| Some single users care if web pages, OS containers, and virtual
| machines can access data that is (supposed to be) forbidden to
| them.
| api wrote:
| It's of most significance to cloud hosts and other shared
| hosting providers where there might be targets of sufficient
| value to motivate someone to spend a lot of time and effort
| cracking stuff.
| staticassertion wrote:
| > Presumably under very ideal conditions?
|
| Maybe? You could also assume that the attack will get faster in
| the future.
|
| Sidechannel attacks like this are situationally impactful. Most
| desktop users don't have to care about security much at all on
| Linux. Further, they probably don't have to care about _any_
| privescs. But some people have threat models that change that.
| wyldfire wrote:
| > The researchers said that it's capable of locating and leaking
| a Linux computer's root password hash from physical memory in
| about 28 minutes when running the Intel CPUs and in about 6
| minutes for AMD CPUs.
|
| Given this attack vector, it makes some sense for relatively
| static secrets like these to be moved into something like the
| Secure Enclave where the CPU can perform signature verification
| but never store the secret itself in memory or cache. I know
| other ARM-based SoCs have these too. So presumably Intel and AMD
| offer something like this in their latest-generation CPUs?
| kramerger wrote:
| Maybe...
|
| AMD has the Secure Processor (an ARM), but it has other duties
| right now, such as system and VM memory encryption.
| saagarjha wrote:
| Putting something in an enclave doesn't magically make it
| impervious to side-channel attacks.
| nomel wrote:
| > doesn't magically
|
| Yet, "by design" is a much more achievable possibility, since
| physical space, slow interconnects, and "dumb" logic can be
| put between the data.
| nibbleshifter wrote:
| > will add as much as 28 percent more overhead to operations.
|
| Yikes. I don't think I'll be enabling that mitigation on my
| workstation.
| bicolao wrote:
| Windows is not affected because it uses IBRS instead, which is
| less performant than retpoline. So the question is, is IRBS
| overhead less or more than 28% now?
| mise_en_place wrote:
| It begs the question, was speculative execution a good idea
| in the first place?
| pcwalton wrote:
| I highly suspect that a comprehensive accounting would show
| that any basic hardware optimization like speculative
| execution has saved the total worldwide computing industry
| hundreds of millions of dollars, if not more. At large
| scale, optimizations add up to enormous value.
| pishpash wrote:
| Compared to what alternative?
| throw93232 wrote:
| Get refund for your CPU. Clearly broken design, most likely not
| fixable by microcode update.
| usr1106 wrote:
| Most workstations run below 10% most of the time. I doubt you
| will even notice.
|
| Where would one expect the worst noticable impact? Number-
| crunching does not need that many syscalls, so no. Database
| maybe? It needs syscalls, but is it still CPU-bound? Networking
| applications?
| nibbleshifter wrote:
| I run a lot of local VM's on my workstations.
|
| I tried offload this workload to the cloud a few times, but
| that's just not as fast (and cheap) as local VM's.
|
| Also requires internet, which I regularly don't have for
| periods of time.
|
| I noticed a huge perf impact on my machines after the spectre
| mitigations rolled out and had to kill those in the kernel
| command line.
| pantalaimon wrote:
| That's silly, just because system is idle most of the time
| doesn't mean performance doesn't matter when you need it.
| smegsicle wrote:
| it says [dupe] but where's the good one?
| ndesaulniers wrote:
| Sorry, Dang fixed it up and told me to stop posting so many
| different links as new submissions. So I'll add a good list
| here:
|
| * https://comsec.ethz.ch/research/microarch/retbleed/
|
| * https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf
|
| * https://www.youtube.com/watch?v=dmSPvJxPm80
|
| * https://arstechnica.com/information-
| technology/2022/07/intel...
|
| * https://www.theregister.com/2022/07/12/amd_intel_retbleed/
|
| * https://www.phoronix.com/scan.php?page=news_item&px=RETBLEED
|
| * https://regmedia.co.uk/2022/07/12/handout_retbleed_amd.pdf
|
| *
| https://www.intel.com/content/www/us/en/developer/articles/t...
|
| *
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
|
| * https://www.intel.com/content/www/us/en/security-
| center/advi...
|
| * https://www.intel.com/content/www/us/en/security-
| center/advi...
| ndesaulniers wrote:
| Also: https://usercontent.irccloud-
| cdn.com/file/SslYH25a/mifune_vs...
| usr1106 wrote:
| I believe according the HN rules original sources should be
| preferred over journalistic coverage.
|
| But given the fact that probably a minority here will greatly
| benefit from the academic paper or the patches, I'd say the
| Arstechnica article is an excellent compromise.
|
| Edit: The article is well-written IMHO, but I nearly did
| classify "sends scrambling" in the title as clickbait not
| worth opening.
| pvg wrote:
| _preferred over journalistic coverage._
|
| That's not in HN's rules - original sources are preferred
| but often good reporting is the best source especially when
| the thing being reported has multiple sources. The goal is
| really quality rather originalness.
| usr1106 wrote:
| Ah, I remembered the wording wrong. It says:
|
| > Please submit the original source. If a post reports on
| something found on another site, submit the latter.
|
| Yours seems to be an interpretation, too.
| pvg wrote:
| It's an interpretation you can find a lot of support for
| in the dangscripture.
___________________________________________________________________
(page generated 2022-07-12 23:00 UTC)