> 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.
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.
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.