Retbleed: New speculative execution attack sends Intel and AMD scrambling
arstechnica.com
arstechnica.com
> 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 ideas moreso than how they're said.
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
void f() {
volatile char sekrit[256];
sekrit[0] = 0;
}
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.
> 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?
- 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.
> 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.
--
hmm?
so, how is it?
1: https://cdn.arstechnica.net/wp-content/uploads/2022/07/retbl...
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.
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
delete WebAssembly
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:
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.
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?
I tried offload this workload to the cloud a few times, but that's just not as fast (and cheap) as local VM's.
Also requires internet, which I regularly don't have for periods of time.
I noticed a huge perf impact on my machines after the spectre mitigations rolled out and had to kill those in the kernel command line.
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.
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. :)
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).
Anyone hopes these gonna be less of auch attacks anytime soon? Sure no, they are essential to sell more new cpus now!
If there are enough of these attacks that don't involve ARM (I know some do), then I see a bright future for ARM servers.
[edit]: Curious to see if Zen3 is also affected - if not, that would be great news.
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.)
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.
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.
* 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.
[0] https://www.amd.com/system/files/documents/technical-guidanc...
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.
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.
* 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.
If it includes updates to the microcode in the cpu I persume you cant get out of it?
> "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 arse waiting to be hacked, too. You will not have static IPs and your machines will likely get periodically scrubbed, too. That's what I would do and I am a complete amateur. I am pretty sure the people who are actually pursued know much better than me.
So to me these articles are extremely interesting from the point of a view of a security researcher but an almost complete non-danger for most folk out there.
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.
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.
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.
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.