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."
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)
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.
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.
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.
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.
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.
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: https://www.phoronix.com/scan.php?page=news_item&px=Google-L...)
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.
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.
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.
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.
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?
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.
uMatrix permits enabling or disabling JS (and other website features: images, CSS, media, frames, XSS, ...) by domain or subdomain, including default allow/deny permissions should you choose.
You can also temporarily enable or disable specific permissions, and save those changes permanently should you choose.
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.
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.
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.
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.
My point is that if you disable speculation on the insecure core then the websites can share without this class of exploit being a risk factor. There my be other vectors for accessing the data of colocated processes.
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)
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.
They need to be in different trust zones unless your willingness to enter a credit card into any website means you’re willing to allow every other website you may be visiting to observe that input. Ditto viewing bank information etc.
That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.
(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)
I’m not entering credit card info though. And even if I did, it’s not very security-sensitive - in the worst case the bank will give me back my money stolen from the card.
If you truly never enter credit card info on the web, or truly have zero expectation that other tabs shouldn't be able to spy on that credit card info when you do, then frankly you're so outside the range of normal people's expectations and behaviours that I don't think basing security architecture around what you do or don't do makes any sense whatsoever.
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.
But in most environments, you as a user are not in total control of what is running. If you are in the cloud, other users in unrelated virtual machines can steal your junk.
Also, if you are running a web browser with JavaScript turned on, that is effectively another user able to steal your junk.
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.
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.
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.
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.
Of course. I'm just saying, it's a banal point to make, and certainly not one that will produce a useful, interesting, or curious conversation.
15 seconds later
(I'll admit: I didn't even notice until just now that it was you who'd made the parent comment, and I feel maybe a little bad about the tone I took. But I'm still right!)
There's an FTX customer with nodes accessing via API keys that control hundreds of millions of dollars of crypto. That customer has Spectre/Meltdown mitigations off and will probably run with Retbleed mitigations off.
I think people will realize when someone offensively applies this in the civilian space. The money is there waiting for those of you who want a few hundred million USD worth of crypto. The test of the exploit will be in the exploiting.
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.
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.
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?
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.
slower processors with more efficient software? For as far as we've come with hardware, the actual user experience hasn't changed anywhere near as dramatically because faster machines just allowed people to push out slower software, the same way that hard drives moving from MBs to GBs to TBs just meant that games and applications bloated up to fill all available disk space and websites bloated up to consume increased bandwidth as we went from 56k to broadband.
The reason why games are tens or hundreds of gigabytes in size is that modern textures are high-resolution and models are high in detail; if you took away high-capacity storage, then you'd just end up with worse-looking games. The reason why Web sites are big is largely images, videos, JS, and CSS; if you took away broadband, you'd end up with worse-looking and less functional Web sites. It's like the broken window fallacy in economics: the fact that having limitations gives smart developers an opportunity to work cleverly within them doesn't change the fact that limitations leave everybody worse off overall.
> The reason why games are tens or hundreds of gigabytes in size is that modern textures are high-resolution and models are high in detail;
not "the reason", just "a reason". A lot of it is just laziness. Not compressing audio and video or doing a very poor job of it. For example a Fortnite update took the game from 60GB to 30GB without making it look like garbage so how did they do it? Optimization. Why didn't they do it sooner? Because they didn't care.
> The reason why Web sites are big is largely images, videos, JS, and CSS; if you took away broadband, you'd end up with worse-looking and less functional Web sites.
Video and images are again "a" reason (and again often the issue is poor compression) but so are bloated JS frameworks, user tracking, and ads. Even very simple websites can bloat to grow larger than full novels. (there are some good examples of this here: https://idlewords.com/talks/website_obesity.htm). You could cut the ads and the tracking and the JS bloat without any impact on the content delivered or the functionality.
People just don't want to take the effort to lower file sizes which is why people have to turn to things like repackers who can cut the sizes for downloads by more than half. Somehow they manage, and they do it for free no less, but game publishers can't?
We could do much better without sacrificing anything (that users care about) in the finished product. If we had to go back to slower processors people would be forced to care enough to write better code and optimize for speed. At least until some new trick for faster speed was developed at which point very little in our lives would be faster, but the code would be slower again.
Also, it does no good to compare the best software of the past with the average or worst software of the present. We tend to forget the average software of the past, and I would guess that most of us weren't exposed to the worst of it.
Inefficient software has been a problem for practically all of the history of personal computing. I'll illustrate with two anecdotes:
I was in high school when Office 97 came out. I only have a vague memory of this, but I do remember one of my classmates complaining that it was sluggish on whatever computer he had at the time.
The first commercial product that I shipped, in 2002, was a desktop application written in Java (though, as shipped, it only ran on Windows). I didn't do most of the original development; it was developed by an outsourced development shop, and then I had to take over the project. Whether on my underpowered 366 MHz laptop or my boss's much more powerful machine, the app took considerable time to start up, so much so that we put in background music during some of the startup process (the app was a self-contained audio environment for blind people, so that was our equivalent of a splash screen). I never really dug into what caused the slow startup, but in hindsight, I would guess that it was the late-binding nature of Java, particularly the fact that classes had to be loaded individually as they were first used, often from multiple jar files, not to mention loading native code from multiple DLLs. The peanut gallery here may say the app should have been a statically linked native executable, but for all practical purposes, that would have meant C++, and if that had been a hard requirement, the app would never have shipped at all. And while we struggled to sell that particular app, it did have some happy users (indeed, for some of the target users that we did manage to reach, the app was positively life-changing in its impact), so I don't regret that we shipped it in its inefficient state. If the same app were developed today in Electron, with any decent build setup, I'm guessing it would be up and running in a few seconds.
Whether in the 90s, the 2000s, or today, most development teams have never had the resources to produce the highly optimized gems that we fondly remember from the past that we so often pine for. But the software that we do manage to ship is used and even enjoyed anyway. And, to bring this back to the original discussion, advances in hardware enable more under-resourced teams to ship more useful and enjoyable software that would otherwise not exist.
> for all practical purposes, that would have meant C++, and if that had been a hard requirement, the app would never have shipped at all.
This is a really good point. Slow software certainly has its place. Not everything needs to be as optimized as possible. I don't think that the loss of speculative execution would put us back so far in terms of performance that it would hurt slower languages like java or python, but I think it might encourage putting more effort into optimization and probably create more interest in lower level languages. It might even lead to new creative approaches to speeding things up. That said, I'd really rather processors stay fast if they can do it while still being secure.
I see it as a ladder of reducing complexity. There is you, power Joe and regular Joe. You can write a program in Assembly or C with syscalls and char ptrs, but then power Joe cannot. You both can write a program in C# or Java with their runtimes, but then regular Joe cannot. All of you can write electron and pyqt.
If we didn’t climb from KBs/MHz to GBs/GHz, only few vendors could ship their software, and that would suck even more.
For some reason there is no simple compiled language with simple but powerful runtime which could do the same thing electron does in KBs/MHz. It is not unrealistic and I think the problem lies within us, our methodologies and tradition to overcomplicate everything we touch. So anyone who tries to make a ladder has to cut through layers and layers of nonsensical abstractions, sacrificing performance and memory here and there, and only then you get something that business people can use.
It's one of the fundamental techniques that allows high end processors to run fast. If you're happy with a desktop processor that runs at the speed of decades-old processors maybe you don't need it.
Well it is the bread and butter of any consumer CPU after Pentium. If you want to run at the speed of early 90's chips i.e. not even fast enough to play MP3 files without specialized hardware.
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?
I see some are down voting you, but that is an option. If the CPU has a design error then you can return it in many countries. If there is a firmware fix and that fix does not affect performance to a significant degree then it's probably OK.
Products should do what the marketing says they should do.
Products should do what the marketing says they should do.
...which is, that they were never designed to be side-channel-resistant. As early as the 80286 Intel was saying protected mode is not a real security boundary, only a mechanism to avoid accidental errors instead of deliberate maliciousness.
> 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.
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.
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.
What would keep a side-channel attacker from reading your YubiKey PIN from kernel memory, and then racing all your authentication attempts until it manages to win the physical button event?
Nothing maybe. But if a side-channel attack gains access to kernel memory, they can do just about anything, and no login scheme is secure against that.
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.
I assume these are for very short passwords? It dramatically increases in complexity with just a few extra characters, is it possible then to use a password that is 3~4 sentences long to defeat this?
7 characters (1 capital letter, 6 lowercase letters) 527= 1,028,071,702,528
8 characters (4 lowercase letters, 2 special characters, 2 numbers)
688= 457,163,239,653,376
so in about 10 seconds it would be able to discover the latter which is absolutely insane to me. The only way is to increase the letters and special characters.
for instance a 12 character password (8 lowercase letter, 2 special, 2 #) would yield an unwieldly number of possibilities but given you can brute force 65 trillion per second at the lower end, we would be seeing an astronomical figure.
We might also see this brute force capacity dramatically increase thanks to Moore's law and then the sky is truly the limit.
a 32 character password would be broken within our lifetime in just a matter of years.
Or use multiple rounds of hashing to generate and validate the hash. IIRC about 5 years ago MS Office was using 500K rounds of SHA512 by default (as a keygen for decrypting documents), which meant about 8 guesses a second on a good machine. Of course you have to keep updating those specs as computing power increases over time.
Is there anything stronger than blowfish? seems like I would just do that 50,000 rounds of blowfish mixed with SHA512 rounds in between randomly. Good luck trying to brute force an excerpt from the Bible written in Japanese backwords using esoteric usage of special characters to top it off.
I expect this to take at least a few millenias to crack
Every time your password is used, you will experience that hash delay. So, for usability, it would be best to keep it to something not-annoying, and just change your password every once and a while.
>a 32 character password would be broken within our lifetime in just a matter of years
Won't you make much more profit spending those resources on mining bitcoin? And where do you plan to get energy to run that calculation even if you hypothetically had enough performance?
Nitpick: that’s bcrypt, not Blowfish. Blowfish is an encryption algorithm; bcrypt is a password hashing algorithm based on Blowfish, but designed to be significantly slower.
Also, bcrypt comes with a work factor that works on a log scale -- a work factor of 6 is 2^6 (64) rounds, and 6 is considered far too out of date these days. The default in hashcat is (IIRC) a work factor of 5 (2^5, 32 rounds).
If you're using 14 or higher, which is usually the recommendation thrown around these days, that 100k number will look more like single or double digits.
I would suspect it is a case that folks just aren't looking hard enough yet. There is also the massive fragmentation in the ARM space. Something like M1/M2 being a much more consistent target.
It could also just be that they have designed them better but time will tell. A lot of things looked really secure until they suddenly were not.
ARM chips are mainly much simpler. The fight with Spectre-like side-channels is a fight against thermodynamics we cannot win, only mitigate.
Any performance improvement relies on the patterns of data also exposes the data itself. Intel and AMD wanted to make faster returns by analyzing the patterns in the return instructions by putting a branch prediction logic. When they do that it behaves differently depending on the data hence it is "observable" to outside world.
If any ARM manufacturer implements a similar feature, it will be vulnerable. There is only one question: When will it be practically exploitable?
Depends on how long the decrypted password(s) is sitting there for someone to read and how easy it is to locate... at least that'd be my speculation. You'd think a good password manager doesn't hold onto the password for very long, then there's copy/paste buffers (which some password managers also clear), then there's the question of whether there's enough information for the attacker to figure out what the password is for. If this is a JavaScript attack vector (not sure if this is possible at all given the language constraints) it's presumably a lot slower vs. the numbers discussed.
But people after volume break-ins might consider it obscure enough not to bother with. "State actors" are often more comprehensive, because they don't want to get blocked from a designated target by such incidentals.
> Or run Linux on ARM, and hope that noone will find similar exploits in the ARM architecure
It's a micro-architecture exploit, nothing specific to the x86 architecture.
I highly suspect that some ARM implementations are also vulnerable to this exploit.
As long as return instructions can trick the Branch Preduction Unit (BPU) to produce a speculative return address that is not from the Return Stack Buffer (RSB), then return instructions can potentially be exploited to perform Branch-Target-Injection (Spectre V2). (I simplify it because there are other conditions such as the ability to set the injected branch address produced)
How is the root password hashed these days? Does it use some "slow" hash like bcrypt, for example?
About 10 years ago a GPU-assisted tool could grind through several hundred million passwords per second to find the cleartext to a hash. That + dictionary + patterns could un-hash a lot of passwords very fast (md5 back then).
I think the default for a lot of distros is crypt() with id 6, which is SHA-512. The default number of rounds is often 5000. I just checked one of my debian machines, and it appears Debian 11 has switched to something called yescrypt.
Perhaps try to scale back our reliance on running massive great piles of untrusted code we pull from god-knows-where, just because some web page said to?
Certainly that's one approach, but perhaps there's a middle ground, where we can have trusted sources of JS.
Perhaps not, but I do stand by my initial comment, it's crazy we just download and execute stuff from wherever and somehow have expectations of security!
I mean, not exactly, but perhaps a restricted selection of reviewed code could be available from a trusted service rather than just "grab anything from wherever and run it".
Sure, that doesn't cover code in the actual page you download, but perhaps it would be a move in the right direction. And yes, maybe it would make things move more slowly, but honestly maybe that's just something we should take as the price of being more secure.
> perhaps a restricted selection of reviewed code could be available from a trusted service
again though, you've literally just described the Apple app store.
who do you imagine will do this review, they're probably going to want to be paid, right? Maybe we could impose an industry-standard 30% cut of the revenue and give that to the company who does the app review and hosts the authenticated code for download.
what do you imagine will happen if third-party apps are allowed to evade app review? Facebook was literally already caught using its dev credentials to get people to install a spyware version of the service... and if they had ever been allowed to do so officially, they would have instantly blocked the web version and forced you to download the spyware version. So we can't allow people to install third-party app stores to bypass review or else everyone bypasses app review and the app review process is trivially circumvented.
oh, wait, those are the two things people hate about the app store, so your service sucks too. why are you suggesting this "locked-in walled garden" garbage!?!? /s
walled-garden walls aren't for keeping you in, they're for keeping danger out. Everyone has always been able to leave the walled garden whenever they wanted - you can leave at any time you feel the balance of apple services vs google services has shifted. And the price of bypassing app review has always been $99 for a developer credential that lets you build and run your own apps.
> again though, you've literally just described the Apple app store.
I'm more describing debian repos. A non-mandatory trusted source for JS libraries. Perhaps the browser creators would like to fund it.
> walled-garden walls aren't for keeping you in, they're for keeping danger out.
Great, so lets have an optional trusted source, that's available as standard in browsers, but which can be opted out of with a few button presses and a warning. Just as a concession to "I don't want any old web page to be able to execute any old crap without oversight".
> I'm more describing debian repos. A non-mandatory trusted source for JS libraries. Perhaps the browser creators would like to fund it.
No, I imagine browser developers probably would not like to fund the development and review of your codebase. How about you do that yourself?
Serious question, why would you even think that's an option? Why does Mozilla want to pay for doing code review for Facebook?
> Great, so lets have an optional trusted source, that's available as standard in browsers, but which can be opted out of with a few button presses and a warning. Just as a concession to "I don't want any old web page to be able to execute any old crap without oversight".
as stated, if such a "couple of button presses" mechanism exists, the worst offenders will instantly demand that you use it and bypass app review/permissioning for them. Facebook and Netflix and the like have "network effect" to get away with it, if you want to use facebook to talk to your friends/family you will do this, or else you won't use facebook. We could certainly start unwinding some of these monopolies so there is no longer such a network effect - but I'd absolutely want to see that happening before we even talk about loosening app review protocols, not just "loosen app review, step 2: a miracle happens".
User choice already exists - the optional trusted source is you build the app on your PC and deploy it on your phone with developer credentials. But the mere existence of a broad-spectrum mechanism by which publishers can publish un-reviewed code guarantees its usage. Show us that you aren't stealing our movies, or else you don't get to watch movies. It has to be a user-driven thing - and that's exactly what exists.
And again, as I already said - this isn't a hypothetical, Facebook already has been using its developer credentials to get users to install spyware that they couldn't get through the app-review process. They already are exploiting the "user-driven mechanism" beyond the allowable bounds, if you hand them the blanket ability to deploy third-party software that bypasses app review, that's essentially curtains for the concept of app review.
Your magical fantasy world where everyone is a good actor and nobody malicious will ever just demand that users push the button to bypass app review is just that - a naive fantasy. In the real world, widespread sideloading is antithetical to the concept of app review, period the end. Sideloading has to be gated significantly enough that a typical user won't want to go through the hassle - like requiring a $100/yr dev credential to do it.
Let me put this in perhaps a different context: how do you think this will all work out when it's WeChat and Tiktok demanding you give root access to the chinese government? There are a lot of people for whom WeChat is not an option, it's just the "facebook of china" and everybody communicates over WeChat. It's not going to be very nice when you hand WeChat the ability to demand that you root your phone for them, or else you just don't get to talk to your family.
You seem to have gone off the deep end. I'm talking about being able to limit browsers to a known-good JS code repo, just as we often do with operating system package repos at the moment.
> No, I imagine browser developers probably would not like to fund the development and review of your codebase. How about you do that yourself?
I don't write javascript or target browsers, I'm looking for ways to protect myself (and others) from people who do, without just throwing out the entire ecosystem. As such that seems a lot like other efforts that browser-makers take on.
I don't know why you're jumping on to apps, root access to phones, sideloading or any of the other weird topics you seem to want to drag into the discussion.
> how do you think this will all work out when it's WeChat and Tiktok demanding you give root access to the chinese government?
I don't know or care, because that's not within the scope of my suggestion, which is to have a default limit on where browsers pull javascript from.
> I don't know or care, because that's not within the scope of my suggestion, which is to have a default limit on where browsers pull javascript from.
Look, app review is a great model of the idea you're trying to think your way through - your idealized solution would look a lot like signed libraries and browsers would refuse to accept code that didn't come from a signed/trusted repo (the Library Store). This is no different from the App Store - it has been observed that the browser is evolving towards being an OS and the sites/libraries are the applications, and that's exactly what you've described, The App store for the web.
A lot of people find this model to be offensive towards user freedom, and allowing a mechanism to trivially bypass this essentially makes the exercise pointless, because then people just get conditioned to hammer the bypass button 20 times a day. Again, this has already been broadly explored by browsers - people rapidly learn not to pay attention to things like invalid certs if the mechanism to bypass them is obvious/trivial. Sites then learn that they don't have to care, because people will bypass them anyway, and the whole thing is an exercise in futility. Big red banners that say "you are about to sell your firstborn to Zucc, are you really sure???" do nothing, especially the 20th time you see them that day.
In your example: facebook would just tell you that if you want to use facebook, you need to add their repo. Done, no need for offenders to get library review ever, just need to have enough network effect to push the user to do it.
I'm not the only person who sees this similarity either, here's the previous comment in the chain:
> Nanny-state walled gardens like the Apple App Store?
Yep, precisely, you are proposing The Library Store. Mandatory library code vetting, only running code from the trusted Store repository. And it suffers the same weakness: if you allow a trivial bypass mechanism, it will be trivially bypassed, routinely. If you don't allow bypass, people think you're Turbo Stalin and accuse you of "nanny-statism".
Mozilla and the others doing this vetting still need to be paid too... so, is there some revenue they can get a cut of, for vetting code for all these random third-parties?
And if you want all of this to just be enforced best-effort on the honor system... I believe NPM already exists?
The "apt repo" model largely only works because there's no large player with a financial incentive to break it. Probably the closest thing is GPL-incompatible code where things can't get into kernel, and so they publish their own repos to get around it... if in your model the "kernel" is the "library store", your trustworthy source of "reviewed, clean code" and the reason the other stuff is incompatible is because it's shady anti-user code that's bordering on spyware and the apt-repo is resulting in malware getting onto user PCs then yeah, in that case, allowing "apt sideloading" would break the trust model there too. You might think "oh well, the user is boss" but you might have code like Facebook that is extremely peopular that people "have to" run even if it's unapproved for very good reasons, and as soon as you open this alternate mechanism you've instantly undone all your work on the review side. So restricting what developers can do actually results in an improvement in user freedom - GPL vs BSD/MIT in a nutshell.
> You seem to have gone off the deep end.
By the way, this is really uncivil. Yes, I have a very distinctive voice thanks to years and years of arguing on the internet. Think of it as Linusposting, hopefully funnier and less assholish, but bombastic, and it tends to leak through unless I make great effort to compress and filter everything I say. I do my best. You still have a responsibility to engage with the idea...
No need to go back to PS2. You could get an AMD FX-9590, or more realistically an AMD FX-8350 CPU based system. I'm running one right now as my gaming setup.
Presumably you don't know where you need to read. So you need to somehow search for the right signature. Why is the root password hash even in memory in the first place?
At any rate, there's probably some search pattern to try and locate the relevant address across a fairly large address space, you need to take into account the lack of accuracy as well. Once you found the location then you presumably know the right offset and just read it straight out.
> Why is the root password hash even in memory in the first place?
I'm very interested in the answer to that question as well, assuming it's true.
Lots of modern software goes to great lengths to ensure that any sensitive data is zeroed out from memory the second it's no longer needed. This includes efforts like modifying garbage collector behavior and preventing swapping so that this data really doesn't stick around a single moment longer than absolutely necessary.
If a standard Linux system really just keeps password hashes (root or not) in memory after loading them, I hope there's a very, very good reason for that. And I hope it's not "duh, we didn't think anyone would be able to read privileged memory".
Often optimizers will frustrate efforts to zero out sensitive data. It can be arbitrarily hard to make sure it happens. Your source code says "zero it", and the compiler, or even the CPU itself, says "nah, waste of time", and doesn't.
There's always ways to control this stuff adequately by setting the properties of memory ranges and the like. All CPU's have to support some equivalent of "volatile" because that's what memory-mapped hardware expects.
Compilers will often delete code that has volatile stores, if it thinks that would be OK. Not everybody agrees with this policy. But they are not who makes decisions about what compilers do.
There "are always ways", but not everybody always knows what they are, or even knows they need to know them. And, what you think ought to suffice too often does not.
How can a compiler remove a volatile store? There exists hardware where a store has a side effect, regardless of the value itself. For example, writing to a FIFO. That’s the entire point of volatile, no?
Right. In particular, a subsequent write to the same address may overwrite (part of) the cache line representing that bit of memory, pushing it to the back of the LRU line. This might happen over and over again, and that cache line then might not get flushed until the end of process's time slice. Anything out in memory backed by that cache line keeps its old value until the writeback finally happens.
If you want to get the root password hash into memory, just run sudo, or any other root process that reads /etc/shadow. It'll probably get it mapped into the file system cache, but it'll certainly get it mapped into that process's memory - albeit potentially temporarily.
I don't know that sudo takes any measures to protect that memory. You say "lots of modern software" but it's more like "the extreme minority of software" with regards to security effort.
That sounds about right, there's limited avenues for asking the file/page cache to get rid of data. It comes down to lots of suggesting to the FS cache that it's not needed, but it might linger either way.
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?
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.
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.
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.
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.
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.
> 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.
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?
> and found that disabling JIT improves performance more often than not
Well, kind of...
>> We find that disabling the JIT does not always have negative impacts. Our tests that measured improvements in power showed 15% improvement on average and our regressions showed around 11% increase in power consumption. Memory is also a mixed story with negatively impacted tests showing a 2.3% regression, but a larger gain on the tests that showed improvements. Page Load times show the most severe decrease with tests that show regressions averaging around 17%. Startup times, however, have only a positive impact and no regressions.
Most people are going to care about page load times more than anything else by far, and that's the one that quite clearly took a hit without JIT. It's great that no JIT makes Edge open faster, but how many times a day do you have to quit and restart your browser?
Edge's newer "Enhanced Security"[1] toggles are essentially that, disabling JIT and WebAssembly (alongside other features) on sites you don't frequent. "Strict" disables them on all sites.
On the V8 teram we had a POC of forcing mispredicted instruction sequences in the interpreter that leaked data. Reorder buffers are 200-600 instructions these days, and indirect branch predictors needed to speculate through bytecode sequences are good enough that an interpreter is not safe.
[!] 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.
Wasm is trivially accessible from JavaScript, so it's not unreasonable to conflate the two, even if its technically incorrect. Wasm also can't do anything that JS couldn't already do; it's simply more convenient in many cases (and maybe somewhat faster at runtime) to write code in C/C++/Rust/whatever and compile it to Wasm than to write the code in JS. You could (and still can) compile these languages to asm.js instead, in which case the code would actually be JS, albeit a particularly weird dialect.
The site pretty clearly says it works on Chrome 88, on Linux. Chrome 91 reduced the resolution of performance.now significantly, which likely broke this website (https://developer.chrome.com/blog/cross-origin-isolated-hr-t...). You're also trying this out on Windows, which is also not supported by the demo page in its default configuration.
But also: this was a demo page put together by a random security researcher on their own, based on a vulnerability from a year ago. It's not a reflection of what a motivated attacker could do with a sufficiently powerful exploitation primitive (say, this Retbleed attack).
I can't speak to what that error is but Chrome 96 appears to be from Nov '21 at the earliest which would include a large number of these mitigations.
w.r.t. js vs web asm: I could be wrong but I think V8 is the engine involved with webassembly as well so I'm not sure the wa vs js distinction matters here, but even so my main point is that there were significant software mitigations put into place in the browser. I'd expect reproducing this attack today would be difficult.
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.
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.
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).
> 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
uBlock can inject this to every webpage you visit. The distinction is you can disable WebAssembly and >99.99% of the web will run like nothing happened.
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.
> 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.
Do you seriously trust it to be like looking for a needle in a haystack? That haystack becomes much much smaller if you know where to look. An excellent adversary would know a lot about kernel memory and what data to get.
Grab a few bytes for a pointer... grab a few more bytes for another pointer offset from the first... just a few pointers and now you're at the secret storage arena. A few hundred bytes/sec is just a few hundred bytes/sec away from gaining sensitive information.
Haha, speaking of Linus’s carefree attitude towards leaving dangerous things unattended because they are not imminently threatening”, this is an opportune moment to point out that AMD has a series of unpatched vulnerabilities (Take-A-Way and PREFETCH, both by Moritz Lipp of Spectre/Meltdown fame) that leak kernel page table mappings as well, unless you enable KPTI, which AMD continues to push as off-by-default due to performance impact.
So on an AMD system you indeed know exactly where to look to get into kernel memory. The processor will just tell you where to look.
Suppose you know that data of interest is at address X. Now how do you propose actually reading that specific address from e.g. JS running in a browser? IMHO having that much knowledge of the system you're attacking means you're not likely to need the side-channel anyway.
It's just like traditional kernel exploitation. Say you have a classic relative kernel read due to an out of bounds read from a heap object. How do you read secrets that way? Well, you leak the ASLR slide, find a relevant global, and start pointer chasing until you reach the object you want. Doing this with speculative reads is just the same as with a regular kernel bug except that now it's slow. Like, legitimately, there are some off the shelf kernel exploitation kits that let you swap in an implementation for read functions and then they'll work straight away whether or not the read is coming from speculative means or a classic bug.
That assumes you have direct control over which addresses you can read, which is far from true in the scenario of most concern (JS running in the browser). It is at best like listening to the conversation of some people walking by, with a ton of background noise, and hoping you'll hear enough to make sense of it.
I won't either to be honest. These are certainly of the 'stars must align' category [today], I just find them interesting.
The speed comes down to time, again - either more efficient methods could be developed (perhaps in combination with other seemingly not-of-interest vulns) or simply by hardware getting even faster.
It also assumes an attacker never gets lucky, or perhaps knows something neither of us do.
I'm not sure I'd use the death/dying of Moore's Law as a mitigation strategy :P
>I feel that exfiltrating memory at a few hundred bytes/sec makes it extremely impractical.
Not at all - you don't sequentially dump all of kernel space - you probabilistically sample it and make guesses of where to look next based on the fingerprints you already have seen. It takes not long at all to find useful stuff.
Find a block that matches a known library? Ok, that entire section is known. Find a page table? Golden - you quickly walk it and you now know how everything else is laid out. Find any of zillions of known structures? Now you can walk those nicely.
I've written code to do kernel reconstruction over the PCI bus from an external security monitor - it's not hard or slow to reconstruct all of memory efficiently and without having to sample much simply by using tricks like these.
It's just like playing Battleship, except you can do it much more accurately with perfect knowledge of probabilities.
Having access to a PCI bus is a bit different than what we're talking about here. Explain to me how are you going to "quickly" walk a page table or other known data structure if you don't have direct control over what you can read?
Their paper states "RETBLEED can leak arbitrary kernel data from an unprivileged process with all the mitigations up on various Intel and AMD systems." They control the branch target buffer so can point to whatever they want.
High-value zero days like what you're describing would not get wasted on stealing bank information from random working schlubs like us.
I think it is a reasonable approach to personal information security to focus on ensuring that you are robust to families of exploits which have concrete proof of concept in practice, and not wasting calories worrying about stuff that is (for the time being) mostly theoretical.
This advice obviously does not apply if you are protecting valuable corporate IP, or a repository of personal information, or god forbid national security secrets.
Oh, definitely - it wouldn't be used for trivial things like that, at least not for quite a while.
[Edit: hopefully having better mitigations in hardware by then]
My comment didn't follow the thread particularly well, I wasn't so much worried about the everyday person - just that this could be weaponized [against someone/thing]
My worry about this really goes as far as... keep the mitigations enabled. That's it.
A lot of people disable them today because they're aren't dangerous today - if nothing else, offering a countering opinion to change that trend.
The people wanting to make it practical certainly won't use something as crude and slow as Spectre or Meltdown or this. They just own your entire system.
Being able to steal secrets -- passwords, bank account information, ephemeral encryption keys to other sites -- is absolutely very significant to single-user computers.
I can tell you that someone's password is "password". There's still the question of which account uses that. Encryption keys are even less easy to use from that perspective, since they are basically random bytes otherwise. What if I told you the AES write key used to secure the TLS connection for this post is D2 B1 CD 58 26 AF 0B 56 29 AE D6 D3 5D 2D 58 96 93 5D 6D 58 26 BA 5A 5A E4 3D D5 7D 55 5C F9 EF ? Would you be able to do anything with that? You even said the keyword yourself: "ephemeral".
If I was someone who is being specifically targeted I might care, but I'm willing to bet that the vast majority of users are not, and those who are will know who they are (and something like this is probably the least of their worries.)
...which brings me back to the faulty premise of the original PoCs for these timing side-channels: they require gathering so much information about the environment beforehand, and such careful setup, that someone with that level of knowledge most likely doesn't need to use a side-channel anyway.
I agree that most attackers aren't going to use this attack, but only because privesc through standard means is well documented and researched. It wouldn't make sense to weaponize this sort of attack while the existing attacks continue to work.
But otherwise you're putting way too much stock into your examples annoying attackers out of their work. I assure you, exploit developers will sit there and stare at hex dumps and put enough of those primitives together to build the exploit chain they need.
It's purely because security's such a shitshow in other ways that we don't see more attacks leveraging this sort of thing. If someone (like Jann) does enough research, puts it out there, and this becomes something that more hackers are comfortable with, they'll absolutely use this.
> Dismissing it without consideration for mitigations is malicious IMO.
But this is par for the course in certain circles who put performance above security for literally decades, because performance is easy to measure (and therefore optimize!), and security isn't. It's the exact same reason we've been gaslit with FUD about needing to write all system software in unsafe languages.
Now the chickens are coming home to roost. All those corners we cut to save some memory, some time, or some money are back to haunt us--at every level of the stack.
That's why you disable JavaScript: we scrutinize downloaded exe files carefully and have virusscanners running all the time while allowing untrusted JavaScript to reach your CPU. As long as there is no effectieve way to tell trusted and untrusted JavaScript apart, having it enabled is silly.
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.
So stop browsing the web I guess? A webpage can serve you up an ad with JS that attacks not just your other tabs, but your kernel, and steals your passwords?
There's absolutely no excuse for the security boundaries that OSes have promised for decades, the foundation upon most everything we take for granted, should break down at a "mere" few hundred bytes a second.
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.
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.
Ironically, you could also assume the background noise will increase in the future, due to the increasing popularity of running software with built-in spyware aka "telemetry"...
But some people have threat models that change that.
Those people (a minority for sure) know who they are, but we shouldn't be crippling the performance of everyone else just for them.
> 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?
Here's how Apple describes their design of the Secure Enclave. I'd figure that Qualcomm, NXP, AMD, etc have a similar design.
> The Secure Enclave Processor provides the main computing power for the Secure Enclave. To provide the strongest isolation, the Secure Enclave Processor is dedicated solely for Secure Enclave use. This helps prevent side-channel attacks that depend on malicious software sharing the same execution core as the target software under attack.
> The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It’s designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks. The Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities, secure boot, a dedicated random number generator, and its own AES engine.
Intel's Software Guard Extensions were supposed to run at a higher, inaccessible privilege level on consumer CPUs and that turned out to be susceptible to side channel attacks. ARM TrustZone was defeated through cache latency measurements on Android in 2016, though that specific flaw might have been patched since.
Perhaps with an entirely separate chip running its own OS with its own RAM and IO, you could work with secrets, but traditional secure chips have so far been far from a silver bullet.
I think the Intel Management Engine is close enough to the system CPU that it is probably affected by side channel attacks, but perhaps AMD's PSP is removed far enough to nullify the effect.
SGX was patched to solve those issues though. This is one of the issues with the security and side channels space: often there are mitigations powerful enough to stop attacks, but people don't remember them being rolled out. They recall the attack, say "oh well that is broken forever" and never re-visit the issue.
As I mention elsewhere, an enclave is a good construct to use here because you're explicitly signalling to the CPU that the memory space has unusually sensitive secrets and you're willing to lose performance to protect them.
That's true, but the point is that simply relying on security extensions is no guarantee for safety. If it was broken before, the theoretical separation isn't complete enough to guarantee it won't be broken again.
SGX is already being phased out by Intel for consumer/workstation products so I think they've given up on the concept themselves. I don't think they're supporting an alternative on consumer products either. Even if their server/enterprise implementation is secure enough, it won't protect against developers having their SSH keys exfiltrated by a game running in their browser during their downtime.
I think externalising the security mechanism is a good idea, but the current implementations simply aren't good enough to combat this issue.
Well, Intel are introducing new features built on SGX so it's definitely not abandoned. Their encrypted VM feature is built on it for instance.
I used to work quite closely with Intel on SGX related stuff. My understanding is, the issue on the client side is not really that Intel itself don't believe in it. They do. The issue is that it requires extensive kernel support. Microsoft never committed the resources to fully implement SGX or make it useful. What little support they shipped wasn't actually workable, especially as Intel updated SGX to address market feedback. Servers run Linux and there Intel were able to write their own drivers and do the necessary work for it themselves, so were less constrained by what Microsoft wanted to do. It's also an easier pitch in the cloud - there are more ideas for use cases.
W.R.T. SSH keys I don't quite understand the threat model you have in mind there. The point of SGX is that root access to the server where the enclave runs is unimportant. The attacker is assumed to have root throughout.
Their disabling of SGX is now preventing Blurays from being played and educational test stalkerware that tries to detect cheaters from being run on 12th gen Intel. What little support Intel had now seems to have evaporated completely.
Their decision to turn SGX into an enterprise feature seems more like another product segmentation strategy to me, same with ECC RAM support. I don't see the point of dropping support entirely for a feature that's still actively being used by consumer products but maintaining the feature in more expensive chips.
WRT ssh keys: in a perfect world, authentication systems such as FIDO key stores, password managers and SSH agents live on a secure coprocessor, signing key material for applications on the main chip and loading their decryption keys from a secure chip like a TPM. If the code is written well, this would make it impossible for even an attacker with root access to gain access to the key material, you'd need physical probes on the motherboards to steal keys. Even kernel modules shouldn't affect the secrecy of the system once it's been initialized correctly. Without a separate, secure system, an attacker in a sufficiently performant browser writing their own timers can now extract data from the kernel (like, say, a process map) and make their way into SSH agent memory, extracting data at kilobytes per second in some processors, all through side channel attacks. A browser tab running 100% CPU for a while wouldn't even be that strange these days, for all you know it's Microsoft Teams or Slack running in the background.
I see. So you're saying you'd want to run the whole SSH client in an enclave?
Beyond the Windows issue, one reason SGX on the client didn't make it is that to really meet the threat model of a compromised OS/kernel, you need a secure input/output path. Video decoding had that, albeit wrapped behind NDAs, but keyboard input doesn't (as far as I know). So whilst you could protect the SSH connection itself inside an enclave, the actual screen/keyboard IO couldn't be defended. It'd not be useless, but it's not quite the convincing win it can be on the server where IO is all encrypted network packets or file system read/writes.
In my setup, a minimal SSH agent daemon would run in an enclave, only the necessary parts for key operations. The rest of the agent (protocol parsing etc.) would run in normal userspace and communicate over a channel (through the kernel or some other API, I don't know enough about low level system's programming to come up with the right abstraction).
Even if the user mode side of the agent would be hijacked, all it could do is ask the secure part to sign requests; the key itself would never leave the enclave. The same would be true for other authentication protocols, such as FIDO2/U2F daemons. In effect, once you've found out about a malicious program, you wouldn't need to worry about someone else reusing your key afterwards. Just analyse, then kill all the open sessions for that user and you don't even need to roll over your keys if you trust the enclave well enough.
For password managers the main key store would he handles by the enclave and only the necessary passwords would leave the enclave and cross over to system space. This way you can't just keylog the passphrase and upload the key store to a server, you could at most extract a few passwords per minute by having a malicious daemon run in the background. Granted, this is a lot less practical or secure than the other methods.
The biggest challenge for this all is to get some kind of secret into the system that the normal CPU can't see, but the secure enclave can. I theorise that the TPM would be an excellent place to do this in, but an enclave can contain its own secret store for all I care. If the enclave can do encrypted I/O with its super secret key, the files on the file system would be difficult to tamper with and configuration and state could even be stored safely on a non-encrypted disk! Reusing old, valid credentials would work, of course, but for that a secure counter or whatever may be implemented to mitigate that. The enclave would also need to run each program in complete isolation of each other (basically no multi threading or caches to prevent side channel attacks) but your average computer wouldn't be running more than two or three daemons anyway. Another challenge is to prevent modification of the loaded agent code itself but that again could be secured by a hash stored on the TPM after the program first loads. Associate the secret key with the hash of the program and allow a hash-secured program to upgrade the hash and you've got a pretty difficult to break system, I reckon, without necessitating the use of manufacturer provided certificates and keys like Intel likes to require. You would need a code execution bug in isolated program on the enclave.
I don't really see how you could lock down a secure input path unless you use PS/2. USB input devices are complex and need some level of drivers to work right, especially ones that do more than your cheap plastic office keyboard. I believe Intel does have such a system when their iGPU is used, I believe it has to do with its enterprise remote access tools, but I think this would be too much of an attack surface for general purpose use.
You can do that sort of thing with SGX very easily indeed. SGX enclaves can generate key material internally that's accessible only to themselves, sealed under the enclave identity, so no TPM is necessary. Actually SGX obsoletes TPMs for some use cases, they're independent technologies.
The way it'd work is you'd just use the public key emitted by the enclave. Grab a Xeon workstation and you can even do such a thing from your desktop.
If you want, you can even prototype such a thing right now. My guess is I could implement that in about an afternoon's worth of work using Conclave:
The thing is, if all it's doing is avoiding key rotation in case of compromise it's a bit hard to justify. Yes, HSM vendors have built a whole business on that, but in practice I'm not sure people are willing to rely on it. Compromised CAs get revoked, right, root store ops don't say "well luckily the HSM means the compromise was only temporary".
Intel did in the past prototype USB keyboards that could do a D/H key exchange and submit encrypted keystrokes. Likewise, apps can do D/H key exchange to tunnel encrypted bitmaps to the GPU where they get composited onto the screen, that's secure video path. Unfortunately there is a long history of them running out of steam before managing to get this stuff deployed in the real world. Seems to be the general PC problem of too many different vendors too coordinate, and PC vendors mostly care about cost reduction rather than new features. Apple is in a better place to do such tech but their whole model is closed-by-default, so they have a secure enclave like tech but only they are allowed to use it. Intel is still the best bet.
Unfortunately the developer experience without something like Conclave is pretty terrible, still. Disclaimer: I started the Conclave project, though I don't work on it anymore.
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.
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.
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.
It's not something that's currently reified or supported as a feature in mainstream OS's, but multilevel security has been studied for a long time in an academic context.
16-bit arithmetic? Sheer luxury! Every morning we had to wake up at midnight, rewrite all our math routines from scratch, then our manager would kill us all with a machete and dance on our graves! And we liked that just fine.
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.
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)
So can this be fixed by making it more difficult to measure time, either through CPU ticks or multithreaded measurements? Can it be a privileged operation to have high accuracy timing?
IIRC cloudflare workers (a multi-tenant cloud environment) sets a static "current time" for each request and disallow multithreading to prevent accurate time measurements.
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.
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.
>“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.”
It's referring to Intel processors with hardware IBRS support, e.g.: Coffee Lake Refresh (e.g.: 9700, 9900) and newer. On those CPUs, Windows also makes use of IBRS alongside retpoline compilation of the kernel. See the table[1] in the linked article.
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.
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.
Why is the issue speculative optimization, not unsafe code? We know what unsafe code is, remote code, code loaded from unknown sources, etc., so those can be segregated at a cost, while safe code runs with efficiency. If it's about unsafe code slipping through due to misclassification, well, there are more vulnerabilities than the processor.
Think so. From an outsider (non-security) point of view at least.
Speculative execution is basically required for fast single-threaded performance, and it also seems to be fundamentally incompatible with running arbitrary programs on the platform securely.
We've all really invested in tricking ourselves into believing otherwise, but this is definitely a tick. It is a trick that many of our careers depend on, so we'll see various 'fixes' bandied about, but they won't solve tomorrow's hole.
Programs running locally should be assumed to have total control. So, like, don't run evil programs. And disable Javascript in the browser. (For the client side, maybe Intel and AMD could put a special in-order, no-speculation, no-branch prediction core on their chips from now on, shunt Javascript to that by default).
Okay, lets say the current crop of CPUs is burned to the tune of 15-28%. What's next? Can this effect be mitigated in the next round of design? Is speculative execution always going to be problematic like this?
Also, what can be done on the software side? Why is Linux so vulnerable, but not Windows? Is the kernel layout in Linux statically define or something?
> What's next? Can this effect be mitigated in the next round of design?
Yes. PCID is one example.The PCID, or Process IDentifier, lets the CPU avoid flushing the TLB on every context switch. Similar approaches could be taken to let the CPU know "this is not a situation where you need to be extra careful, you can be extra fast".
There are likely other hardware approaches that could help. I doubt we can ever get to "100% of the performance is back" because a side channel is always going to be possible if specific operations have specific effects like timing differences, but we can probably get to 99%. PCID alone drops the performance hit of kpti in half (or so).
> Also, what can be done on the software side?
memfd_protect is a cool thing that kinda helps in theory. There's probably a lot of stuff processes could do to protect themselves, in theory.
> Why is Linux so vulnerable, but not Windows?
I can only assume because Microsoft cared more to solve the problem. Windows implements a more complete mitigation than Linux, someone else can provide sources to the discussions that led to Linux's approach.
In today's arms race of exploits, you need to operate and prepare your interactions with computers with a defined threat scenario. This is never-ending.
> Linux creator Linus Torvalds famously rejected such warnings, arguing that such exploits weren’t practical.
And I would certainly agree with Linus, here's why:
> Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy.
Retbleed adds more credence to this idea of impractical-yet-technically-feasible exploits; where do you draw the line? Do you choose to be vulnerable to this 219 bytes per second leak at the cost of 28% CPU overhead? I would imagine, one could toggle on or off the mitigations they'd want with the implications provided in the future via modifying BIOS settings.
A Bitcoin private key is 32 bytes long. /etc/shadow on my machine is 1080 bytes long. Heck, my entire password manager database is probably no more than a few KB in size.
Sure, chasing the necessary pointers and data structures through the kernel or other user programs might add some overhead, but don't write off a 200b/s leak as harmless. It may well be enough to steal the secrets you care about the most.
This is a great case for developers using Electron. Nobody is every going to get anything meaningful from those apps at 219b/s -- there's far too much memory to read!
I didn't find the joke particularly funny, but how is it unsubstantiated that Electron apps use a lot of memory? That seems to be a pretty easy thing to check, and see that a fairly simple Electron app... uses a lot of memory.
Good point. I'm going to start allocating tens of megabytes of random data all over my address space at the beginning of execution so that I too can gain this advantage :)
You joke, but allocating and writing random data all over the heap and hiding and constantly moving key material through it is the idea behind Schneier's Boojum.
This is a very interesting insight. The vast majority of traditional unix security mitigations are about securing a multi-user system from malicious users. However a lot of the most frightening threat models now are about using data from a single-user system to hijack session tokens or other secrets and thereby compromise external systems that it has some sort of trust relationship with. That's why you see spearphishing attacks that compromise the clipboard - they are hoping that a useful secret gets copied from a password manager or similar. You don't need to elevate priviledge on the local machine if all the secrets are owned by the user you have compromised, and all these secrets are very small numbers of bytes because they are designed to go into a challenge response type flow.
Yep. The Unix security model feels out of date these days. Who cares about privilege escalation attacks when all my most sensitive data (ssh keys, browser cookies and saved passwords, code repositories, etc) is already readable by every program I run in my user account?
Desktop computing needs application sandboxing like phones have. I find it remarkable that nobody in the opensource world seems to care about this problem.
I think people care, just not enough to deal with the huge PITA that sandboxing turns out to be.
It takes a significant amount of discipline - and meticulous detail - to start going down the sandboxing path. In other words, it's tedious and not fun at all.
Cubes OS care about this problem and have a really great solution. If you’re linux-savvy I would recommend it. There are some friction points but it is 100% usable even as a main work OS (I did this for a while in one of the startups I worked for).
As an example of something you can do trivially in cubes, say someone sends you a PDF that you don’t trust you can just right-click on it, the OS will spin up a temp vm, copy the PDF over and start the PDF viewer in the VM. When you’re done, the VM is nuked and any nefarious b/s the PDF tried to do is gone. Typically these tempvms have networking disabled so there’s no way it can communicate with the mothership either.
It won't prevent theft of ephemeral SSH session keys, but consider using a HSM or at least a TPM (with Termius, or Secretive) for long-term private key storage. 2FA will situationally help with the other concerns. (You can and probably should use 2FA with SSH as well.)
If someone has the ability to run things on my machine as my user (which presumably would be required to exploit Retbleed), then they can already read the login cookies for all my accounts, as they are stored in plaintext on disk in Firefox's cookies.sqlite file. Password vault is a little more work, since it's encrypted on disk, but presumably they could just read my password manager's memory space during a period when the database is unlocked. Same with SSH keys, though they'd have to poke into ssh-agent's memory.
Yep. I’d happily ditch all the spectre and meltdown mitigations if they make my machine run faster - so long as my browser is still a secure sandbox against malicious code.
Anything running natively with my user’s permissions already has access to everything of value on my computer.
Yeah, it's between 1200 baud and 2400 baud - which would be right around where dialup was in the 80s. Plus the attack runs at 3.9KB/s on AMD processors - over 10 times faster!
Fair! Thanks for the correction. I intended to say bits per second. Luckily I think I’m still in the right ballpark for speeds (at least in the early 80s).
Did any of those old modems use QAM? It seems like many of the older protocols were FSK/PSK-based (yes, special cases of QAM, but not decoded the same way).
Good question. I've long since tossed my various modems from the epoch. I started using dial-up systems around 1987 or 1988, working through 300, 1200/75, and 2400bps, etc.
Referring to wikipedia [0] I note v22.bis was released in 1984, and while they're a bit vague, they suggest 2 or 3 bits per signalling change in those 1200bps modems.
I also recall, though perhaps later, vendors were often champing at the bit with 'proposed spec' compliant hardware available prior to the formal specifications dropping, so it was not uncommon to have some of those new speed devices prior earlier (obviously with some risk attached). I think that was more around the 14400bps era though.
Anyway, my extremely solid Telecom 2400bps modem was almost definitely running at 600baud (produced in the late 1980's, though in my possession from very early 1990's).
Depressingly, a lot of ostensibly tech articles (eg [1]) conflate baud with bps, making them poor-use / low-trust historical references.
It’s a fair point but also back in the day - “everybody” (especially the younger BBS and hobbyist crowd) incorrectly referred to them as 1200 baud or 2400 or even 9600 baud modem - as evidenced by the numerous historical references.
Now it's all a matter of bandwidth and reliability. The world of digital computers is overlaid with an analog world of side-channels that are measured in frequency and signal-to-noise ratio.
I worked on Spectre for a couple years when on V8 and read a couple books on information theory, signals, and probability. Computer science is catching up to EE little by little :-)
Are you saying windows runs 28% slower than Linux systems?
“Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today's public disclosure date,” Intel wrote in a blog post. “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.”
Yes, context switching specifically. It's well known that if spawning thousands of child processes, or if walking a directory of 100k small files to get metadata, linux can be much faster than windows. You might consider these just bad program design - on windows you'd strongly prefer to use many threads, and pack files of some kind (zip, cab, etc). There ends up being lots of different reasons why this kind of stuff can be rather slow on windows (but if you deal with fewer processes and fewer files you won't notice, it'll be fine). Some fascinating details: https://randomascii.wordpress.com/2019/04/21/on2-in-createpr... (and that blog has many similar fascinating posts)
This is probably another spike through the heart for SGX, at any rate. If you could use this to leak the attestation keys, SGX is useless for secure execution of code on a hostile system.
SGX is already dead on consumer chips, but I don't think this has any impact on SGX. SGX keys aren't stored in kernel memory so being able to leak data from kernel memory isn't going to leak the keys. Of course there are other attacks that can get SGX keys or 'protected data'
Someday we will learn that allowing adversaries to run code on our computers will always create leaks. In the old days whenever a new exploit was discovered, advisories would go out telling people to disable Javascript in their browsers. Now JS can no longer be disabled, and way too many sites rely on it unnecessarily, so we are stuck. Oops.
Our business has windows. Someone drove up, kicked in a window, stole some things and left. I keep trying to tell people to tear all their windows out, but I guess people think they add value to their home and so now we're stuck. Oops.
What we actually did was add "glass break sensors" to our security system.
You can also install glass that is 'vandal proof', with a plastic layer. It'll slow down whoever is trying to smash it enough until the police show up.
3M sell a range of security film for after market application. Also IR/UV blocking films. Former external latter internal. Worth looking at the energy savings because which can be significant depending on your local climate. Variants provide internal reflection suppression and tints which might make it attractive to executive pursors. The (public SKU) electrically conductive window film was discontinued unfortunately..
The difference now is we made it easier for people to break everyone’s windows at scale and take what they want from another country with unfriendly extradition rules.
Today's Javascript crowd has an even more insatiable appetite for cpu cycles than Microsoft Word did in the early 2000's. A 50x slowdown would do some good, I suppose, but there are also the many software escapes that keep occurring. "Trusted" execution environments have failed repeatedly in the past too. Remember SGX? I don't remember what went wrong with it but it wasn't timing related afair.
Wikipedia shows a spate of speculative execution/timing-based attacks against SGX, as recent as 2020. something like 10 different attacks.
business-wise, I think Intel's decision to gatekeep SGX and require developers to buy licenses to get signing keys probably doomed it, along with how weird and arcane it was to develop for. but the security was not good.
SGX is out there and being used. It's actually the solution to these problems, ultimately, because Intel CPUs are highly patchable via microcode and when you set up an enclave you're effectively opting in to better security for lower performance. For instance, a lot of the early attacks were blocked simply by making the CPU flush its state when entering or exiting an enclave. Intel could do that because an enclave is meant to be hardened, whereas other sorts of mitigations at e.g. syscall boundaries hit tough performance/security tradeoffs that are very different in different contexts.
Also, I'll say, having read a lot of SGX related research papers that many of the attacks were not really practical on close examination, or were immediately patched. The researchers don't tend to mention these things but e.g. using ancient crypto libraries without any side channel mitigations is rather common in that field.
For things like this, it'd probably make sense to use SGX more in the Linux kernel for holding secrets and doing other things. A lot of stuff in the kernel isn't really read sensitive (modulo generic secrets like KASLR slides). Having secrets like root hashes hanging around in kernel memory isn't a good idea but where to put them? One solution is to move stuff into enclaves. Unfortunately it would only help on server platforms.
> In today's arms race of exploits, you need to operate and prepare your interactions with computers with a defined threat scenario. This is never-ending.
There are very, very few threat models in which a 219 bytes/sec kernel memory disclosure is not catastrophic. Even in an ideal world where disclosing kernel memory wouldn't help an attacker bypass KASLR, it's catastrophic for any key material that happens to be in kernel memory.
KASLR is already broken on AMD systems. #1 is unpatched (AMD says "it doesn't directly leak memory", only the page table mappings, ie breaks KASLR) and #2 the PREFETCH+TLB-Evict combo is still unpatched unless you use non-default hardened configs (only mitigated by enabling KPTI which AMD recommends be disabled by default). #2 also allows a Meltdown-style attack which exfils data directly but hey, also breaks KASLR too.
I would add that if you’re in a position to actually exploit this (having a process running on the target computer and an access to exfiltrate the data), there is a good chance that you have access to simpler vulnerabilities than raw memory leaks from the cpu.
When the article says "scrambling", this is what it means. Normally there's enough time before disclosure for a patch to be prepared and sometimes even released. I wouldn't consider the phrasing of the headline an exaggeration this time.
Yes. Boot the kernel with the flag "mitigations=off". Run some benchmarks. It's not nearly as substantial as all the 'fear warriors' makes it out to be.
If Intel and AMD could drastically speed up their current CPUs, they would have already done so. This is definitely not a good thing for either of them.
I took a look at the paper. Unlike the Hertzbleed attack this one seems to justify the bleed naming given the ability to rapidly locate the password hash (which can then be quickly brute forced back to the root password, most likely). However! There are caveats. It appears that modern Intel chips actually already mitigate this:
> "We observed that eIBRS systems seem protected from RETBLEED. IBRS, which is the alternative for earlier systems, was considered too expensive to use in practice when Spectre was introduced in 2018. Flushing the entire BTB through IBPB upon kernel entry would arguably be even more expensive. Intel’s mitigation. Despite the performance cost of IBRS, it mitigates RETBLEED on vulnerable Intel CPUs. Hence, IBRS will selectively be enabled on systems that exhibit RSB-to-BTB fallback behavior that do not support eIBRS."
Translated:
• New Intel chips have better support for blocking this attack. You can get performance+security by using a new(ish) CPU. Windows already uses that support if present. Linux apparently doesn't, but will presumably migrate now the retpoline trick is broken. The big slowdowns would come for older CPUs without the right hardware to control these attacks.
But, wait:
"Concurrently to our work, Branch History Injection (BHI) [7] explored the limitations of eIBRS and found that indirect branch speculation can be hijacked to run previously executed indirect branch targets in the kernel. Whereas RETBLEED targets Intel CPUs without eIBRS and certain AMD CPUs, BHI targets Intel CPUs with eIBRS and ARM. Moreover, because of the limited number of disclosure gadgets available to BHI, unprivileged eBPF is required for practical exploitation, which consequentially has been disabled as a mitigation"
Translating again:
• Even with new Intel chips there's a way to break them but the conditions are so specific that no normal kernel compile will produce them. Instead you have to be able to JIT compile custom code on the fly that runs in kernel mode. The eBPF feature lets users do this, but, if you limit it to root then the problem goes away. Oh and also ARM chips aren't magically invulnerable or anything.
Overall, I think this confirms the impression I already had for some time - despite whatever other issues it may have Intel is ahead when it comes to security. People aren't really looking for vulns in ARM chips though that may change now with M1. In fact even vulns in AMD chips are considered second tier and not that interesting. But, Intel chips have more features to stop speculation attacks.
A lot of Spectre-type attacks have actually been addressed over time by new hardware features (usually in combination with OS patches), but chip makers seem to suck at communicating this to the general public. If you're worried about specex attacks then your best bet is to aggressively upgrade your CPU to stay on the leading edge, to ensure your OS and browser are always fully patched, and if you write software for Intel servers, to explore SGX enclaves which these days do a lot of pipeline flushing and partitioning on entry/exit.
Guy who worked closer to the metal in a previous life but sadly moved to web development 13 years ago and who is now looking to exit the area and return to hardcore backend, sysadmin and general system scripting roles here, giving his uninformed (in the details) take:
(TL;DR)
Yes there are real risks in disabling the mitigations like I did but the combined chances of actually being targeted _and_ duped into installing something that greatly accelerates the pace with which my stuff can be exfiltrated, are minuscule.
People love to talk about the "risk of event $A" but what's very often missed in these discussions that for an attacker to get exactly what they want from you they need the risk of several, if not many, events -- say, $A to $Z -- to be high at the same time which as we all know from math reduces the resulting probability severely (due to multiplication of several numbers and they are all less than 1.0).
(/TL;DR)
Several months ago I disabled all the mitigations on my home Linux server, and I plan to disable them on two laptops I'll install Linux on as well.
The server is headless so the attack surface is drastically reduced (unless the package manager gets frisky with executing semi-random Python/JS scripts in pre/post installation phases). The laptops are riskier, and we know how insecure X11 is in general; it's a free for all game once a malicious program gets installed.
To me the lost performance actually hurts. I have the before and after experience.
I made a quick and small analysis of my risks. My router is reasonably secure and I've done some elementary homework e.g. VLANs to isolate the gaming machines, guest smartphones and other risky devices from the rest of our home's trusted devices, allow-list mine / my wife's / few friends' devices and disallow outgoing traffic for everything else.
I am comfortable with my risk-to-reward ratio involved in disabling the mitigations.
I get all the reservations (and I would love to return to working closer to the metal one day, too). I am aware that 219 bytes/sec is plenty enough for a persistent worm-like software to eventually exfiltrate everything* it needs. I am 100% sure it can be done.
However:
- It requires significant time and effort on the part of the attacker. They have resources, I know, but they very likely don't have foolproof exploits ready even for the original Spectre/Meltdown exploits. They require several layers of things going wrong on my machine for them to succeed. And I block most of the JS on the sites I visit. Chance is still bigger than 0% but IMO not enough to get scared.
- It requires them to iterate on the said worm/virus many times because in no universe does any adversary have perfect programmers that create the perfect exfiltration software on the first try. Thus, them being able to auto-update the software on my machines is not a given because they get periodically updated and rebooted which might deprive them of the vector they used to get in (which might be ephemeral and stored only in memory or temporary files). Every several months I proactively upgrade the kernel which is yet another way for them to lose their way in.
- It requires several* things to go wrong for me at the same time, for this particular exploit. Not very likely I think. I am not excellent with security but I generally wouldn't jump through hoops to install some obscure program that might be infected (whether the Linux distro package repos are already infiltrated and are serving the three-letter agencies is a scary question but one worth asking; still, nothing I can do about that. I won't stop using Linux).
---
All in all, meh. If you are targeted by nation states or their contractors you have much worse things to worry about e.g. whether somebody in the Costa Rican cafe you work on your laptop that month from will call the police on you.
If you are a high-profile target you wouldn't sit on your...
374 comments
[ 3.3 ms ] story [ 247 ms ] threadIf 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.
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."
Yes.
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.
``` + 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...
Intel Coffee Lake (a.k.a. 8th Generation Core) or older and AMD Zen 2 or older are 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.
Though it seems like the code is not portable (?) between CPU microarchitectures.
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.
Per https://www.intel.com/content/www/us/en/developer/topic-tech... (click 2022 tab), there's C and D steppings of 9900k. Note Intel recommends some software mitgations for both steppings.
(It looks like the kernel decided it was too confusing to handle different steppings and is applying the mitigation to all: https://lore.kernel.org/lkml/20220712183239.024698478@linuxf... so maybe doesn't matter either way.)
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.
https://addons.mozilla.org/en-US/firefox/addon/umatrix/
uMatrix permits enabling or disabling JS (and other website features: images, CSS, media, frames, XSS, ...) by domain or subdomain, including default allow/deny permissions should you choose.
You can also temporarily enable or disable specific permissions, and save those changes permanently should you choose.
It's fiddly, but good fiddly.
That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.
(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)
Single-user systems can be affected by these, but they can be affected by more direct attacks.
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?
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.
If you only run code you trust, then (assuming your trust was placed in it properly) it won't steal anything from you.
Also, if you are running a web browser with JavaScript turned on, that is effectively another user able to steal your junk.
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
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...
That's how I feel though some days, tbh.
15 seconds later
(I'll admit: I didn't even notice until just now that it was you who'd made the parent comment, and I feel maybe a little bad about the tone I took. But I'm still right!)
I think people will realize when someone offensively applies this in the civilian space. The money is there waiting for those of you who want a few hundred million USD worth of crypto. The test of the exploit will be in the exploiting.
* 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...
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.
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.
> 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.
Yikes. I don't think I'll be enabling that mitigation on my workstation.
not "the reason", just "a reason". A lot of it is just laziness. Not compressing audio and video or doing a very poor job of it. For example a Fortnite update took the game from 60GB to 30GB without making it look like garbage so how did they do it? Optimization. Why didn't they do it sooner? Because they didn't care.
> The reason why Web sites are big is largely images, videos, JS, and CSS; if you took away broadband, you'd end up with worse-looking and less functional Web sites.
Video and images are again "a" reason (and again often the issue is poor compression) but so are bloated JS frameworks, user tracking, and ads. Even very simple websites can bloat to grow larger than full novels. (there are some good examples of this here: https://idlewords.com/talks/website_obesity.htm). You could cut the ads and the tracking and the JS bloat without any impact on the content delivered or the functionality.
People just don't want to take the effort to lower file sizes which is why people have to turn to things like repackers who can cut the sizes for downloads by more than half. Somehow they manage, and they do it for free no less, but game publishers can't?
We could do much better without sacrificing anything (that users care about) in the finished product. If we had to go back to slower processors people would be forced to care enough to write better code and optimize for speed. At least until some new trick for faster speed was developed at which point very little in our lives would be faster, but the code would be slower again.
Inefficient software has been a problem for practically all of the history of personal computing. I'll illustrate with two anecdotes:
I was in high school when Office 97 came out. I only have a vague memory of this, but I do remember one of my classmates complaining that it was sluggish on whatever computer he had at the time.
The first commercial product that I shipped, in 2002, was a desktop application written in Java (though, as shipped, it only ran on Windows). I didn't do most of the original development; it was developed by an outsourced development shop, and then I had to take over the project. Whether on my underpowered 366 MHz laptop or my boss's much more powerful machine, the app took considerable time to start up, so much so that we put in background music during some of the startup process (the app was a self-contained audio environment for blind people, so that was our equivalent of a splash screen). I never really dug into what caused the slow startup, but in hindsight, I would guess that it was the late-binding nature of Java, particularly the fact that classes had to be loaded individually as they were first used, often from multiple jar files, not to mention loading native code from multiple DLLs. The peanut gallery here may say the app should have been a statically linked native executable, but for all practical purposes, that would have meant C++, and if that had been a hard requirement, the app would never have shipped at all. And while we struggled to sell that particular app, it did have some happy users (indeed, for some of the target users that we did manage to reach, the app was positively life-changing in its impact), so I don't regret that we shipped it in its inefficient state. If the same app were developed today in Electron, with any decent build setup, I'm guessing it would be up and running in a few seconds.
Whether in the 90s, the 2000s, or today, most development teams have never had the resources to produce the highly optimized gems that we fondly remember from the past that we so often pine for. But the software that we do manage to ship is used and even enjoyed anyway. And, to bring this back to the original discussion, advances in hardware enable more under-resourced teams to ship more useful and enjoyable software that would otherwise not exist.
This is a really good point. Slow software certainly has its place. Not everything needs to be as optimized as possible. I don't think that the loss of speculative execution would put us back so far in terms of performance that it would hurt slower languages like java or python, but I think it might encourage putting more effort into optimization and probably create more interest in lower level languages. It might even lead to new creative approaches to speeding things up. That said, I'd really rather processors stay fast if they can do it while still being secure.
If we didn’t climb from KBs/MHz to GBs/GHz, only few vendors could ship their software, and that would suck even more.
For some reason there is no simple compiled language with simple but powerful runtime which could do the same thing electron does in KBs/MHz. It is not unrealistic and I think the problem lies within us, our methodologies and tradition to overcomplicate everything we touch. So anyone who tries to make a ladder has to cut through layers and layers of nonsensical abstractions, sacrificing performance and memory here and there, and only then you get something that business people can use.
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?
Products should do what the marketing says they should do.
...which is, that they were never designed to be side-channel-resistant. As early as the 80286 Intel was saying protected mode is not a real security boundary, only a mechanism to avoid accidental errors instead of deliberate maliciousness.
> 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.
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.
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.
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/e4fcee00cb6d82874dace7210...
5 characters (3 lowercase letters, 2 numbers) 365= 60,466,176
7 characters (1 capital letter, 6 lowercase letters) 527= 1,028,071,702,528
8 characters (4 lowercase letters, 2 special characters, 2 numbers)
688= 457,163,239,653,376
so in about 10 seconds it would be able to discover the latter which is absolutely insane to me. The only way is to increase the letters and special characters.
for instance a 12 character password (8 lowercase letter, 2 special, 2 #) would yield an unwieldly number of possibilities but given you can brute force 65 trillion per second at the lower end, we would be seeing an astronomical figure.
We might also see this brute force capacity dramatically increase thanks to Moore's law and then the sky is truly the limit.
a 32 character password would be broken within our lifetime in just a matter of years.
I expect this to take at least a few millenias to crack
I think you mean bcrypt..
Both Argon2 and scrypt win over that:
https://github.com/P-H-C/phc-winner-argon2 https://www.tarsnap.com/scrypt.html
Won't you make much more profit spending those resources on mining bitcoin? And where do you plan to get energy to run that calculation even if you hypothetically had enough performance?
If you're using 14 or higher, which is usually the recommendation thrown around these days, that 100k number will look more like single or double digits.
Links to ARM FAQs and other docs below. Note that ARM's list of vulnerable implementations doesn't account for third party designs eg Apple CPUs.
https://developer.arm.com/documentation/102587/0102/General-...
https://developer.arm.com/Arm%20Security%20Center/Speculativ...
It could also just be that they have designed them better but time will tell. A lot of things looked really secure until they suddenly were not.
Any performance improvement relies on the patterns of data also exposes the data itself. Intel and AMD wanted to make faster returns by analyzing the patterns in the return instructions by putting a branch prediction logic. When they do that it behaves differently depending on the data hence it is "observable" to outside world.
If any ARM manufacturer implements a similar feature, it will be vulnerable. There is only one question: When will it be practically exploitable?
So maybe don't quite panic yet. Developing story.
But people after volume break-ins might consider it obscure enough not to bother with. "State actors" are often more comprehensive, because they don't want to get blocked from a designated target by such incidentals.
It's a micro-architecture exploit, nothing specific to the x86 architecture. I highly suspect that some ARM implementations are also vulnerable to this exploit.
As long as return instructions can trick the Branch Preduction Unit (BPU) to produce a speculative return address that is not from the Return Stack Buffer (RSB), then return instructions can potentially be exploited to perform Branch-Target-Injection (Spectre V2). (I simplify it because there are other conditions such as the ability to set the injected branch address produced)
About 10 years ago a GPU-assisted tool could grind through several hundred million passwords per second to find the cleartext to a hash. That + dictionary + patterns could un-hash a lot of passwords very fast (md5 back then).
There's that, I guess...
Perhaps try to scale back our reliance on running massive great piles of untrusted code we pull from god-knows-where, just because some web page said to?
Perhaps not, but I do stand by my initial comment, it's crazy we just download and execute stuff from wherever and somehow have expectations of security!
Sure, that doesn't cover code in the actual page you download, but perhaps it would be a move in the right direction. And yes, maybe it would make things move more slowly, but honestly maybe that's just something we should take as the price of being more secure.
again though, you've literally just described the Apple app store.
who do you imagine will do this review, they're probably going to want to be paid, right? Maybe we could impose an industry-standard 30% cut of the revenue and give that to the company who does the app review and hosts the authenticated code for download.
what do you imagine will happen if third-party apps are allowed to evade app review? Facebook was literally already caught using its dev credentials to get people to install a spyware version of the service... and if they had ever been allowed to do so officially, they would have instantly blocked the web version and forced you to download the spyware version. So we can't allow people to install third-party app stores to bypass review or else everyone bypasses app review and the app review process is trivially circumvented.
oh, wait, those are the two things people hate about the app store, so your service sucks too. why are you suggesting this "locked-in walled garden" garbage!?!? /s
walled-garden walls aren't for keeping you in, they're for keeping danger out. Everyone has always been able to leave the walled garden whenever they wanted - you can leave at any time you feel the balance of apple services vs google services has shifted. And the price of bypassing app review has always been $99 for a developer credential that lets you build and run your own apps.
I'm more describing debian repos. A non-mandatory trusted source for JS libraries. Perhaps the browser creators would like to fund it.
> walled-garden walls aren't for keeping you in, they're for keeping danger out.
Great, so lets have an optional trusted source, that's available as standard in browsers, but which can be opted out of with a few button presses and a warning. Just as a concession to "I don't want any old web page to be able to execute any old crap without oversight".
No, I imagine browser developers probably would not like to fund the development and review of your codebase. How about you do that yourself?
Serious question, why would you even think that's an option? Why does Mozilla want to pay for doing code review for Facebook?
> Great, so lets have an optional trusted source, that's available as standard in browsers, but which can be opted out of with a few button presses and a warning. Just as a concession to "I don't want any old web page to be able to execute any old crap without oversight".
as stated, if such a "couple of button presses" mechanism exists, the worst offenders will instantly demand that you use it and bypass app review/permissioning for them. Facebook and Netflix and the like have "network effect" to get away with it, if you want to use facebook to talk to your friends/family you will do this, or else you won't use facebook. We could certainly start unwinding some of these monopolies so there is no longer such a network effect - but I'd absolutely want to see that happening before we even talk about loosening app review protocols, not just "loosen app review, step 2: a miracle happens".
User choice already exists - the optional trusted source is you build the app on your PC and deploy it on your phone with developer credentials. But the mere existence of a broad-spectrum mechanism by which publishers can publish un-reviewed code guarantees its usage. Show us that you aren't stealing our movies, or else you don't get to watch movies. It has to be a user-driven thing - and that's exactly what exists.
And again, as I already said - this isn't a hypothetical, Facebook already has been using its developer credentials to get users to install spyware that they couldn't get through the app-review process. They already are exploiting the "user-driven mechanism" beyond the allowable bounds, if you hand them the blanket ability to deploy third-party software that bypasses app review, that's essentially curtains for the concept of app review.
Your magical fantasy world where everyone is a good actor and nobody malicious will ever just demand that users push the button to bypass app review is just that - a naive fantasy. In the real world, widespread sideloading is antithetical to the concept of app review, period the end. Sideloading has to be gated significantly enough that a typical user won't want to go through the hassle - like requiring a $100/yr dev credential to do it.
Let me put this in perhaps a different context: how do you think this will all work out when it's WeChat and Tiktok demanding you give root access to the chinese government? There are a lot of people for whom WeChat is not an option, it's just the "facebook of china" and everybody communicates over WeChat. It's not going to be very nice when you hand WeChat the ability to demand that you root your phone for them, or else you just don't get to talk to your family.
> No, I imagine browser developers probably would not like to fund the development and review of your codebase. How about you do that yourself?
I don't write javascript or target browsers, I'm looking for ways to protect myself (and others) from people who do, without just throwing out the entire ecosystem. As such that seems a lot like other efforts that browser-makers take on.
I don't know why you're jumping on to apps, root access to phones, sideloading or any of the other weird topics you seem to want to drag into the discussion.
> how do you think this will all work out when it's WeChat and Tiktok demanding you give root access to the chinese government?
I don't know or care, because that's not within the scope of my suggestion, which is to have a default limit on where browsers pull javascript from.
Look, app review is a great model of the idea you're trying to think your way through - your idealized solution would look a lot like signed libraries and browsers would refuse to accept code that didn't come from a signed/trusted repo (the Library Store). This is no different from the App Store - it has been observed that the browser is evolving towards being an OS and the sites/libraries are the applications, and that's exactly what you've described, The App store for the web.
A lot of people find this model to be offensive towards user freedom, and allowing a mechanism to trivially bypass this essentially makes the exercise pointless, because then people just get conditioned to hammer the bypass button 20 times a day. Again, this has already been broadly explored by browsers - people rapidly learn not to pay attention to things like invalid certs if the mechanism to bypass them is obvious/trivial. Sites then learn that they don't have to care, because people will bypass them anyway, and the whole thing is an exercise in futility. Big red banners that say "you are about to sell your firstborn to Zucc, are you really sure???" do nothing, especially the 20th time you see them that day.
In your example: facebook would just tell you that if you want to use facebook, you need to add their repo. Done, no need for offenders to get library review ever, just need to have enough network effect to push the user to do it.
I'm not the only person who sees this similarity either, here's the previous comment in the chain:
> Nanny-state walled gardens like the Apple App Store?
Yep, precisely, you are proposing The Library Store. Mandatory library code vetting, only running code from the trusted Store repository. And it suffers the same weakness: if you allow a trivial bypass mechanism, it will be trivially bypassed, routinely. If you don't allow bypass, people think you're Turbo Stalin and accuse you of "nanny-statism".
Mozilla and the others doing this vetting still need to be paid too... so, is there some revenue they can get a cut of, for vetting code for all these random third-parties?
And if you want all of this to just be enforced best-effort on the honor system... I believe NPM already exists?
The "apt repo" model largely only works because there's no large player with a financial incentive to break it. Probably the closest thing is GPL-incompatible code where things can't get into kernel, and so they publish their own repos to get around it... if in your model the "kernel" is the "library store", your trustworthy source of "reviewed, clean code" and the reason the other stuff is incompatible is because it's shady anti-user code that's bordering on spyware and the apt-repo is resulting in malware getting onto user PCs then yeah, in that case, allowing "apt sideloading" would break the trust model there too. You might think "oh well, the user is boss" but you might have code like Facebook that is extremely peopular that people "have to" run even if it's unapproved for very good reasons, and as soon as you open this alternate mechanism you've instantly undone all your work on the review side. So restricting what developers can do actually results in an improvement in user freedom - GPL vs BSD/MIT in a nutshell.
> You seem to have gone off the deep end.
By the way, this is really uncivil. Yes, I have a very distinctive voice thanks to years and years of arguing on the internet. Think of it as Linusposting, hopefully funnier and less assholish, but bombastic, and it tends to leak through unless I make great effort to compress and filter everything I say. I do my best. You still have a responsibility to engage with the idea...
It's still fine for semi-trusted users, e.g. company employees.
At any rate, there's probably some search pattern to try and locate the relevant address across a fairly large address space, you need to take into account the lack of accuracy as well. Once you found the location then you presumably know the right offset and just read it straight out.
I'm very interested in the answer to that question as well, assuming it's true.
Lots of modern software goes to great lengths to ensure that any sensitive data is zeroed out from memory the second it's no longer needed. This includes efforts like modifying garbage collector behavior and preventing swapping so that this data really doesn't stick around a single moment longer than absolutely necessary.
If a standard Linux system really just keeps password hashes (root or not) in memory after loading them, I hope there's a very, very good reason for that. And I hope it's not "duh, we didn't think anyone would be able to read privileged memory".
There "are always ways", but not everybody always knows what they are, or even knows they need to know them. And, what you think ought to suffice too often does not.
For example, in
a compiler may reason that, since sekrit is on the stack, and no hardware device could know where it is, it may elide the whole block. And, some do.Sometimes you have to put the zeroing code in its own .o file so the caller's compiler won't know what it does.
I don't know that sudo takes any measures to protect that memory. You say "lots of modern software" but it's more like "the extreme minority of software" with regards to security effort.
Maybe /etc/shadow is in the filesystem cache.
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?
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.
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.
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.
But for APT groups that might need a wedge on particular machines it might be worthwhile, remember the length NSO group went with Pegasus.
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.
Well, kind of...
>> We find that disabling the JIT does not always have negative impacts. Our tests that measured improvements in power showed 15% improvement on average and our regressions showed around 11% increase in power consumption. Memory is also a mixed story with negatively impacted tests showing a 2.3% regression, but a larger gain on the tests that showed improvements. Page Load times show the most severe decrease with tests that show regressions averaging around 17%. Startup times, however, have only a positive impact and no regressions.
Most people are going to care about page load times more than anything else by far, and that's the one that quite clearly took a hit without JIT. It's great that no JIT makes Edge open faster, but how many times a day do you have to quit and restart your browser?
And Edge has so-called "Super Duper Secure Mode": https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
1: https://support.microsoft.com/en-us/microsoft-edge/enhance-y...
no they didnt, otherwise there would be a demo page you could use right now to check if you are susceptible
[!] 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.
The site pretty clearly says it works on Chrome 88, on Linux. Chrome 91 reduced the resolution of performance.now significantly, which likely broke this website (https://developer.chrome.com/blog/cross-origin-isolated-hr-t...). You're also trying this out on Windows, which is also not supported by the demo page in its default configuration.
But also: this was a demo page put together by a random security researcher on their own, based on a vulnerability from a year ago. It's not a reflection of what a motivated attacker could do with a sufficiently powerful exploitation primitive (say, this Retbleed attack).
w.r.t. js vs web asm: I could be wrong but I think V8 is the engine involved with webassembly as well so I'm not sure the wa vs js distinction matters here, but even so my main point is that there were significant software mitigations put into place in the browser. I'd expect reproducing this attack today would be difficult.
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/
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.
A cursory search did not find what further mitigations have been implemented since 2021.
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
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.
Do you seriously trust it to be like looking for a needle in a haystack? That haystack becomes much much smaller if you know where to look. An excellent adversary would know a lot about kernel memory and what data to get.
Grab a few bytes for a pointer... grab a few more bytes for another pointer offset from the first... just a few pointers and now you're at the secret storage arena. A few hundred bytes/sec is just a few hundred bytes/sec away from gaining sensitive information.
So on an AMD system you indeed know exactly where to look to get into kernel memory. The processor will just tell you where to look.
The speed comes down to time, again - either more efficient methods could be developed (perhaps in combination with other seemingly not-of-interest vulns) or simply by hardware getting even faster.
It also assumes an attacker never gets lucky, or perhaps knows something neither of us do.
I'm not sure I'd use the death/dying of Moore's Law as a mitigation strategy :P
Not at all - you don't sequentially dump all of kernel space - you probabilistically sample it and make guesses of where to look next based on the fingerprints you already have seen. It takes not long at all to find useful stuff.
Find a block that matches a known library? Ok, that entire section is known. Find a page table? Golden - you quickly walk it and you now know how everything else is laid out. Find any of zillions of known structures? Now you can walk those nicely.
I've written code to do kernel reconstruction over the PCI bus from an external security monitor - it's not hard or slow to reconstruct all of memory efficiently and without having to sample much simply by using tricks like these.
It's just like playing Battleship, except you can do it much more accurately with perfect knowledge of probabilities.
I think it is a reasonable approach to personal information security to focus on ensuring that you are robust to families of exploits which have concrete proof of concept in practice, and not wasting calories worrying about stuff that is (for the time being) mostly theoretical.
This advice obviously does not apply if you are protecting valuable corporate IP, or a repository of personal information, or god forbid national security secrets.
[Edit: hopefully having better mitigations in hardware by then]
My comment didn't follow the thread particularly well, I wasn't so much worried about the everyday person - just that this could be weaponized [against someone/thing]
My worry about this really goes as far as... keep the mitigations enabled. That's it.
A lot of people disable them today because they're aren't dangerous today - if nothing else, offering a countering opinion to change that trend.
I used to believe this was true. Then someone who had access to post tweets as very famous public figures used it to steal bitcoin.
I can tell you that someone's password is "password". There's still the question of which account uses that. Encryption keys are even less easy to use from that perspective, since they are basically random bytes otherwise. What if I told you the AES write key used to secure the TLS connection for this post is D2 B1 CD 58 26 AF 0B 56 29 AE D6 D3 5D 2D 58 96 93 5D 6D 58 26 BA 5A 5A E4 3D D5 7D 55 5C F9 EF ? Would you be able to do anything with that? You even said the keyword yourself: "ephemeral".
If I was someone who is being specifically targeted I might care, but I'm willing to bet that the vast majority of users are not, and those who are will know who they are (and something like this is probably the least of their worries.)
...which brings me back to the faulty premise of the original PoCs for these timing side-channels: they require gathering so much information about the environment beforehand, and such careful setup, that someone with that level of knowledge most likely doesn't need to use a side-channel anyway.
But otherwise you're putting way too much stock into your examples annoying attackers out of their work. I assure you, exploit developers will sit there and stare at hex dumps and put enough of those primitives together to build the exploit chain they need.
It's purely because security's such a shitshow in other ways that we don't see more attacks leveraging this sort of thing. If someone (like Jann) does enough research, puts it out there, and this becomes something that more hackers are comfortable with, they'll absolutely use this.
But this is par for the course in certain circles who put performance above security for literally decades, because performance is easy to measure (and therefore optimize!), and security isn't. It's the exact same reason we've been gaslit with FUD about needing to write all system software in unsafe languages.
Now the chickens are coming home to roost. All those corners we cut to save some memory, some time, or some money are back to haunt us--at every level of the stack.
Enjoy the meltdown :)
There's absolutely no excuse for the security boundaries that OSes have promised for decades, the foundation upon most everything we take for granted, should break down at a "mere" few hundred bytes a second.
I'm not saying there is. I'm saying running untrusted javascript on strange websites is not worth 15% of my CPU performance.
Some single users care if web pages, OS containers, and virtual machines can access data that is (supposed to be) forbidden to them.
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.
But some people have threat models that change that.
Those people (a minority for sure) know who they are, but we shouldn't be crippling the performance of everyone else just for them.
I highly doubt that. Most developers, by far, could not tell you the threat model for these attacks.
> but we shouldn't be crippling the performance of everyone else just for them.
You can turn the mitigations off.
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?
AMD has the Secure Processor (an ARM), but it has other duties right now, such as system and VM memory encryption.
I would say "by design" is much easier to achieve since physical space, slow interconnects, and "dumb" logic can be put between the two.
> The Secure Enclave Processor provides the main computing power for the Secure Enclave. To provide the strongest isolation, the Secure Enclave Processor is dedicated solely for Secure Enclave use. This helps prevent side-channel attacks that depend on malicious software sharing the same execution core as the target software under attack.
> The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It’s designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks. The Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities, secure boot, a dedicated random number generator, and its own AES engine.
Perhaps with an entirely separate chip running its own OS with its own RAM and IO, you could work with secrets, but traditional secure chips have so far been far from a silver bullet.
I think the Intel Management Engine is close enough to the system CPU that it is probably affected by side channel attacks, but perhaps AMD's PSP is removed far enough to nullify the effect.
As I mention elsewhere, an enclave is a good construct to use here because you're explicitly signalling to the CPU that the memory space has unusually sensitive secrets and you're willing to lose performance to protect them.
SGX is already being phased out by Intel for consumer/workstation products so I think they've given up on the concept themselves. I don't think they're supporting an alternative on consumer products either. Even if their server/enterprise implementation is secure enough, it won't protect against developers having their SSH keys exfiltrated by a game running in their browser during their downtime.
I think externalising the security mechanism is a good idea, but the current implementations simply aren't good enough to combat this issue.
I used to work quite closely with Intel on SGX related stuff. My understanding is, the issue on the client side is not really that Intel itself don't believe in it. They do. The issue is that it requires extensive kernel support. Microsoft never committed the resources to fully implement SGX or make it useful. What little support they shipped wasn't actually workable, especially as Intel updated SGX to address market feedback. Servers run Linux and there Intel were able to write their own drivers and do the necessary work for it themselves, so were less constrained by what Microsoft wanted to do. It's also an easier pitch in the cloud - there are more ideas for use cases.
W.R.T. SSH keys I don't quite understand the threat model you have in mind there. The point of SGX is that root access to the server where the enclave runs is unimportant. The attacker is assumed to have root throughout.
Their decision to turn SGX into an enterprise feature seems more like another product segmentation strategy to me, same with ECC RAM support. I don't see the point of dropping support entirely for a feature that's still actively being used by consumer products but maintaining the feature in more expensive chips.
WRT ssh keys: in a perfect world, authentication systems such as FIDO key stores, password managers and SSH agents live on a secure coprocessor, signing key material for applications on the main chip and loading their decryption keys from a secure chip like a TPM. If the code is written well, this would make it impossible for even an attacker with root access to gain access to the key material, you'd need physical probes on the motherboards to steal keys. Even kernel modules shouldn't affect the secrecy of the system once it's been initialized correctly. Without a separate, secure system, an attacker in a sufficiently performant browser writing their own timers can now extract data from the kernel (like, say, a process map) and make their way into SSH agent memory, extracting data at kilobytes per second in some processors, all through side channel attacks. A browser tab running 100% CPU for a while wouldn't even be that strange these days, for all you know it's Microsoft Teams or Slack running in the background.
Beyond the Windows issue, one reason SGX on the client didn't make it is that to really meet the threat model of a compromised OS/kernel, you need a secure input/output path. Video decoding had that, albeit wrapped behind NDAs, but keyboard input doesn't (as far as I know). So whilst you could protect the SSH connection itself inside an enclave, the actual screen/keyboard IO couldn't be defended. It'd not be useless, but it's not quite the convincing win it can be on the server where IO is all encrypted network packets or file system read/writes.
Even if the user mode side of the agent would be hijacked, all it could do is ask the secure part to sign requests; the key itself would never leave the enclave. The same would be true for other authentication protocols, such as FIDO2/U2F daemons. In effect, once you've found out about a malicious program, you wouldn't need to worry about someone else reusing your key afterwards. Just analyse, then kill all the open sessions for that user and you don't even need to roll over your keys if you trust the enclave well enough.
For password managers the main key store would he handles by the enclave and only the necessary passwords would leave the enclave and cross over to system space. This way you can't just keylog the passphrase and upload the key store to a server, you could at most extract a few passwords per minute by having a malicious daemon run in the background. Granted, this is a lot less practical or secure than the other methods.
The biggest challenge for this all is to get some kind of secret into the system that the normal CPU can't see, but the secure enclave can. I theorise that the TPM would be an excellent place to do this in, but an enclave can contain its own secret store for all I care. If the enclave can do encrypted I/O with its super secret key, the files on the file system would be difficult to tamper with and configuration and state could even be stored safely on a non-encrypted disk! Reusing old, valid credentials would work, of course, but for that a secure counter or whatever may be implemented to mitigate that. The enclave would also need to run each program in complete isolation of each other (basically no multi threading or caches to prevent side channel attacks) but your average computer wouldn't be running more than two or three daemons anyway. Another challenge is to prevent modification of the loaded agent code itself but that again could be secured by a hash stored on the TPM after the program first loads. Associate the secret key with the hash of the program and allow a hash-secured program to upgrade the hash and you've got a pretty difficult to break system, I reckon, without necessitating the use of manufacturer provided certificates and keys like Intel likes to require. You would need a code execution bug in isolated program on the enclave.
I don't really see how you could lock down a secure input path unless you use PS/2. USB input devices are complex and need some level of drivers to work right, especially ones that do more than your cheap plastic office keyboard. I believe Intel does have such a system when their iGPU is used, I believe it has to do with its enterprise remote access tools, but I think this would be too much of an attack surface for general purpose use.
The way it'd work is you'd just use the public key emitted by the enclave. Grab a Xeon workstation and you can even do such a thing from your desktop.
If you want, you can even prototype such a thing right now. My guess is I could implement that in about an afternoon's worth of work using Conclave:
https://docs.conclave.net/
The thing is, if all it's doing is avoiding key rotation in case of compromise it's a bit hard to justify. Yes, HSM vendors have built a whole business on that, but in practice I'm not sure people are willing to rely on it. Compromised CAs get revoked, right, root store ops don't say "well luckily the HSM means the compromise was only temporary".
Intel did in the past prototype USB keyboards that could do a D/H key exchange and submit encrypted keystrokes. Likewise, apps can do D/H key exchange to tunnel encrypted bitmaps to the GPU where they get composited onto the screen, that's secure video path. Unfortunately there is a long history of them running out of steam before managing to get this stuff deployed in the real world. Seems to be the general PC problem of too many different vendors too coordinate, and PC vendors mostly care about cost reduction rather than new features. Apple is in a better place to do such tech but their whole model is closed-by-default, so they have a secure enclave like tech but only they are allowed to use it. Intel is still the best bet.
Unfortunately the developer experience without something like Conclave is pretty terrible, still. Disclaimer: I started the Conclave project, though I don't work on it anymore.
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.
Could you please link me to something I can read about it?
We have that, it's called OpenBSD. :)
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.
IIRC cloudflare workers (a multi-tenant cloud environment) sets a static "current time" for each request and disallow multithreading to prevent accurate time measurements.
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.
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.
> 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/
hmm?
so, how is it?
1: https://cdn.arstechnica.net/wp-content/uploads/2022/07/retbl...
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.
In the cases for which this is not true we need to selectively lock down speculative execution.
There seems to be no end to these attacks. Just brief periods of remission.
Speculative execution is basically required for fast single-threaded performance, and it also seems to be fundamentally incompatible with running arbitrary programs on the platform securely.
We've all really invested in tricking ourselves into believing otherwise, but this is definitely a tick. It is a trick that many of our careers depend on, so we'll see various 'fixes' bandied about, but they won't solve tomorrow's hole.
Programs running locally should be assumed to have total control. So, like, don't run evil programs. And disable Javascript in the browser. (For the client side, maybe Intel and AMD could put a special in-order, no-speculation, no-branch prediction core on their chips from now on, shunt Javascript to that by default).
Also, what can be done on the software side? Why is Linux so vulnerable, but not Windows? Is the kernel layout in Linux statically define or something?
> What's next? Can this effect be mitigated in the next round of design?
Yes. PCID is one example.The PCID, or Process IDentifier, lets the CPU avoid flushing the TLB on every context switch. Similar approaches could be taken to let the CPU know "this is not a situation where you need to be extra careful, you can be extra fast".
There are likely other hardware approaches that could help. I doubt we can ever get to "100% of the performance is back" because a side channel is always going to be possible if specific operations have specific effects like timing differences, but we can probably get to 99%. PCID alone drops the performance hit of kpti in half (or so).
> Also, what can be done on the software side?
memfd_protect is a cool thing that kinda helps in theory. There's probably a lot of stuff processes could do to protect themselves, in theory.
> Why is Linux so vulnerable, but not Windows?
I can only assume because Microsoft cared more to solve the problem. Windows implements a more complete mitigation than Linux, someone else can provide sources to the discussions that led to Linux's approach.
> Linux creator Linus Torvalds famously rejected such warnings, arguing that such exploits weren’t practical.
And I would certainly agree with Linus, here's why:
> Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy.
Retbleed adds more credence to this idea of impractical-yet-technically-feasible exploits; where do you draw the line? Do you choose to be vulnerable to this 219 bytes per second leak at the cost of 28% CPU overhead? I would imagine, one could toggle on or off the mitigations they'd want with the implications provided in the future via modifying BIOS settings.
Sure, chasing the necessary pointers and data structures through the kernel or other user programs might add some overhead, but don't write off a 200b/s leak as harmless. It may well be enough to steal the secrets you care about the most.
But I'm not seeing this Boojum as a concept explained in quick results, actually, one of your prior comments mentioning it is top result. [1]
Would you please explain what you mean by Boojum / link to what you're referring to?
[1] https://news.ycombinator.com/item?id=27941909
- The login cookies I have for my email account, my bank or my GitHub account
- My password vault
- My ssh private keys - which could be used to mess with production systems or make changes to repositories on GitHub without my knowledge
All of this data is extremely small (handfuls of bytes) and could cause lots of harm.
Giving malicious javascript the power to exfiltrate any of these secrets would be a disaster.
Desktop computing needs application sandboxing like phones have. I find it remarkable that nobody in the opensource world seems to care about this problem.
As an example of something you can do trivially in cubes, say someone sends you a PDF that you don’t trust you can just right-click on it, the OS will spin up a temp vm, copy the PDF over and start the PDF viewer in the VM. When you’re done, the VM is nuked and any nefarious b/s the PDF tried to do is gone. Typically these tempvms have networking disabled so there’s no way it can communicate with the mothership either.
Anything running natively with my user’s permissions already has access to everything of value on my computer.
Perhaps I'm a boomer, but 219 Bps is damn fucking fast - faster then the first few modems I used.
> where do you draw the line?
Probably somewhere fucking much further below any point where human communication was deemed practical in the past 150 years.
Somewhat pathetic to me that people can't imagine 200 Bps as a usable bandwidth.
Eh?
219 Bps ~= 2100 bps (effective)
Assuming QAM that'd be something under 600 baud.
Baud and bps are not the same thing.
Did any of those old modems use QAM? It seems like many of the older protocols were FSK/PSK-based (yes, special cases of QAM, but not decoded the same way).
Referring to wikipedia [0] I note v22.bis was released in 1984, and while they're a bit vague, they suggest 2 or 3 bits per signalling change in those 1200bps modems.
I also recall, though perhaps later, vendors were often champing at the bit with 'proposed spec' compliant hardware available prior to the formal specifications dropping, so it was not uncommon to have some of those new speed devices prior earlier (obviously with some risk attached). I think that was more around the 14400bps era though.
Anyway, my extremely solid Telecom 2400bps modem was almost definitely running at 600baud (produced in the late 1980's, though in my possession from very early 1990's).
Depressingly, a lot of ostensibly tech articles (eg [1]) conflate baud with bps, making them poor-use / low-trust historical references.
[0] https://en.wikipedia.org/wiki/Modem#1980s
[1] https://www.techradar.com/au/news/internet/getting-connected...
I worked on Spectre for a couple years when on V8 and read a couple books on information theory, signals, and probability. Computer science is catching up to EE little by little :-)
“Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today's public disclosure date,” Intel wrote in a blog post. “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.”
There’s also other mitigations that don’t have that penalty that are working on employing: https://www.intel.com/content/www/us/en/developer/articles/t...
It looks like downplaying the potential of ret attacks was at best overly optimistic.
What we actually did was add "glass break sensors" to our security system.
Oops.
It will be dog slow, but it can't leak the behaviour of other components on the system.
business-wise, I think Intel's decision to gatekeep SGX and require developers to buy licenses to get signing keys probably doomed it, along with how weird and arcane it was to develop for. but the security was not good.
Also, I'll say, having read a lot of SGX related research papers that many of the attacks were not really practical on close examination, or were immediately patched. The researchers don't tend to mention these things but e.g. using ancient crypto libraries without any side channel mitigations is rather common in that field.
For things like this, it'd probably make sense to use SGX more in the Linux kernel for holding secrets and doing other things. A lot of stuff in the kernel isn't really read sensitive (modulo generic secrets like KASLR slides). Having secrets like root hashes hanging around in kernel memory isn't a good idea but where to put them? One solution is to move stuff into enclaves. Unfortunately it would only help on server platforms.
There are very, very few threat models in which a 219 bytes/sec kernel memory disclosure is not catastrophic. Even in an ideal world where disclosing kernel memory wouldn't help an attacker bypass KASLR, it's catastrophic for any key material that happens to be in kernel memory.
https://mlq.me/download/takeaway.pdf
https://mlq.me/download/amdprefetch.pdf
* https://ubuntu.com/security/CVE-2022-28693
* https://ubuntu.com/security/CVE-2022-29900
* https://ubuntu.com/security/CVE-2022-29901
* https://security-tracker.debian.org/tracker/CVE-2022-28693
* https://security-tracker.debian.org/tracker/CVE-2022-29900
* https://security-tracker.debian.org/tracker/CVE-2022-29901
When the article says "scrambling", this is what it means. Normally there's enough time before disclosure for a patch to be prepared and sometimes even released. I wouldn't consider the phrasing of the headline an exaggeration this time.
If it includes updates to the microcode in the cpu I persume you cant get out of it?
Anyone hopes these gonna be less of auch attacks anytime soon? Sure no, they are essential to sell more new cpus now!
[0] https://www.amd.com/system/files/documents/technical-guidanc...
> "We observed that eIBRS systems seem protected from RETBLEED. IBRS, which is the alternative for earlier systems, was considered too expensive to use in practice when Spectre was introduced in 2018. Flushing the entire BTB through IBPB upon kernel entry would arguably be even more expensive. Intel’s mitigation. Despite the performance cost of IBRS, it mitigates RETBLEED on vulnerable Intel CPUs. Hence, IBRS will selectively be enabled on systems that exhibit RSB-to-BTB fallback behavior that do not support eIBRS."
Translated:
• New Intel chips have better support for blocking this attack. You can get performance+security by using a new(ish) CPU. Windows already uses that support if present. Linux apparently doesn't, but will presumably migrate now the retpoline trick is broken. The big slowdowns would come for older CPUs without the right hardware to control these attacks.
But, wait:
"Concurrently to our work, Branch History Injection (BHI) [7] explored the limitations of eIBRS and found that indirect branch speculation can be hijacked to run previously executed indirect branch targets in the kernel. Whereas RETBLEED targets Intel CPUs without eIBRS and certain AMD CPUs, BHI targets Intel CPUs with eIBRS and ARM. Moreover, because of the limited number of disclosure gadgets available to BHI, unprivileged eBPF is required for practical exploitation, which consequentially has been disabled as a mitigation"
Translating again:
• Even with new Intel chips there's a way to break them but the conditions are so specific that no normal kernel compile will produce them. Instead you have to be able to JIT compile custom code on the fly that runs in kernel mode. The eBPF feature lets users do this, but, if you limit it to root then the problem goes away. Oh and also ARM chips aren't magically invulnerable or anything.
Overall, I think this confirms the impression I already had for some time - despite whatever other issues it may have Intel is ahead when it comes to security. People aren't really looking for vulns in ARM chips though that may change now with M1. In fact even vulns in AMD chips are considered second tier and not that interesting. But, Intel chips have more features to stop speculation attacks.
A lot of Spectre-type attacks have actually been addressed over time by new hardware features (usually in combination with OS patches), but chip makers seem to suck at communicating this to the general public. If you're worried about specex attacks then your best bet is to aggressively upgrade your CPU to stay on the leading edge, to ensure your OS and browser are always fully patched, and if you write software for Intel servers, to explore SGX enclaves which these days do a lot of pipeline flushing and partitioning on entry/exit.
(TL;DR)
Yes there are real risks in disabling the mitigations like I did but the combined chances of actually being targeted _and_ duped into installing something that greatly accelerates the pace with which my stuff can be exfiltrated, are minuscule.
People love to talk about the "risk of event $A" but what's very often missed in these discussions that for an attacker to get exactly what they want from you they need the risk of several, if not many, events -- say, $A to $Z -- to be high at the same time which as we all know from math reduces the resulting probability severely (due to multiplication of several numbers and they are all less than 1.0).
(/TL;DR)
Several months ago I disabled all the mitigations on my home Linux server, and I plan to disable them on two laptops I'll install Linux on as well.
The server is headless so the attack surface is drastically reduced (unless the package manager gets frisky with executing semi-random Python/JS scripts in pre/post installation phases). The laptops are riskier, and we know how insecure X11 is in general; it's a free for all game once a malicious program gets installed.
To me the lost performance actually hurts. I have the before and after experience.
I made a quick and small analysis of my risks. My router is reasonably secure and I've done some elementary homework e.g. VLANs to isolate the gaming machines, guest smartphones and other risky devices from the rest of our home's trusted devices, allow-list mine / my wife's / few friends' devices and disallow outgoing traffic for everything else.
I am comfortable with my risk-to-reward ratio involved in disabling the mitigations.
I get all the reservations (and I would love to return to working closer to the metal one day, too). I am aware that 219 bytes/sec is plenty enough for a persistent worm-like software to eventually exfiltrate everything* it needs. I am 100% sure it can be done.
However:
- It requires significant time and effort on the part of the attacker. They have resources, I know, but they very likely don't have foolproof exploits ready even for the original Spectre/Meltdown exploits. They require several layers of things going wrong on my machine for them to succeed. And I block most of the JS on the sites I visit. Chance is still bigger than 0% but IMO not enough to get scared.
- It requires them to iterate on the said worm/virus many times because in no universe does any adversary have perfect programmers that create the perfect exfiltration software on the first try. Thus, them being able to auto-update the software on my machines is not a given because they get periodically updated and rebooted which might deprive them of the vector they used to get in (which might be ephemeral and stored only in memory or temporary files). Every several months I proactively upgrade the kernel which is yet another way for them to lose their way in.
- It requires several* things to go wrong for me at the same time, for this particular exploit. Not very likely I think. I am not excellent with security but I generally wouldn't jump through hoops to install some obscure program that might be infected (whether the Linux distro package repos are already infiltrated and are serving the three-letter agencies is a scary question but one worth asking; still, nothing I can do about that. I won't stop using Linux).
---
All in all, meh. If you are targeted by nation states or their contractors you have much worse things to worry about e.g. whether somebody in the Costa Rican cafe you work on your laptop that month from will call the police on you.
If you are a high-profile target you wouldn't sit on your...