9 ms·

Here's the moneyshot: > Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy. The exploit can extract ker

Here's the moneyshot: > Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy. The exploit can extract kernel memory from AMD CPUs with a bandwidth of 3.9 kB per second. > The researchers said that it’s capable of locating and leaking a Linux computer’s root password hash from physical memory in about 28 minutes when running the Intel CPUs and in about 6 minutes for AMD CPUs.

yomkippur 4y ago
so basically passwords are useless on these CPUs? What can we do? Use playstation 2 hardware to run linux?
- photon-torpedo 4y ago
  The root password hash is not sufficient to log in as root, but knowing the hash enables an attacker to run an offline brute-force attack to crack the password. Depending on the password complexity, this may or may not be feasible. That said, this attack may be able to extract other information from system memory that would enable de-facto root access, it depends a lot on what's running on the machine. > What can we do? Install the patches and enjoy the reduced performance. Or run Linux on ARM, and hope that noone will find similar exploits in the ARM architecure.
  - yomkippur 4y ago
    So how complex does the password need to be? What if you have a 32 character password with mostly symbols, punctuations and non sensical strings mixed together? It seems like as quantumn computing gets better it would be a matter of time for them to crack any password going forward. Do we need an entire passage of the bible transformed into a password? I just assume it would be a lot more difficult to find the chimpanzee on the typewriter that can write a page from the bible purely by trial and error. That would take light years is my thinking but I could be wrong.
    - pishpash 4y ago
      Use physical tokens. Passwords is not the future.
      - MBCook 4y ago
        Is that an option for the root password on Linux?
        SkyMarshal 4y ago
        Yeah, for example: https://support.yubico.com/hc/en-us/articles/360018695819-Ubuntu-Linux-20-Login-Guide-Challenge-Response https://support.yubico.com/hc/en-us/articles/360018695819-Ub...
        Hackbraten 4y ago
        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?
        SkyMarshal 4y ago
        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.
    - nomel 4y ago
      For an Nvidia 3090, you you can do around [1]: MD5: 65 trillion guesses/second SHA-512: 2 trillion guesses/second Blowfish: 100k guesses/second My root password is fairly short, since I type it all the time. I would be screwed if anyone had interest. I don't think relatively short root passwords are all that uncommon. 1. https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace72106d73fef https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...
  - XorNot 4y ago
    I am curious if there's any evidence ARM is fundamentally immune to this sort of exploit, or if we're just not looking hard enough yet?
    - jlokier 4y ago
      ARMs are vulnerable to several spectre-style exploits, and have mitigations that can be turned on at some cost to performance just like x86. 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-frequently-asked-questions?lang=en https://developer.arm.com/documentation/102587/0102/General-... https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability https://developer.arm.com/Arm%20Security%20Center/Speculativ...
    - NovaVeles 4y ago
      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.
    - okanat 4y ago
      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?
  - ec109685 4y ago
    Password managers for every other password seem vulnerable?
    - YZF 4y ago
      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. So maybe don't quite panic yet. Developing story.
  - woojoo666 4y ago
    So M1 macbooks are safe?
    - ncmncm 4y ago
      Hahahaha. No. 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.
  - avianes 4y ago
    > 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)
- jacooper 4y ago
  These are password hashes, not the password it self.
  - moring 4y ago
    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).
    - scandinavian 4y ago
      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.
- Yuioup 4y ago
  OpenBSD disables hyperthreading by default. There's that, I guess...
  - bee_rider 4y ago
    I don't see the link (although, security stuff confuses me generally).
    - flatiron 4y ago
      For this there is no link. But having two processes share the same core at the same time could lead to problems.
- Nursie 4y ago
  > What can we do? 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?
  - kelnos 4y ago
    What's the alternative, though? Nanny-state walled gardens like the Apple App Store? No thanks; I'll take my chances.
    - nafey 4y ago
      Write your own OS /s
    - deleted 4y ago
      [deleted]
    - weberer 4y ago
      I think parent comment was implying the alternative is NoScript
      - Nursie 4y ago
        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!
        silon42 4y ago
        We need some kind of a code review system (peer based?) to review JS code that is allowed to be enabled.
    - Nursie 4y ago
      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.
- IshKebab 4y ago
  Don't let completely untrusted users on your systems. There are enough privilege escalation vulnerabilities in Linux that that was already true. It's still fine for semi-trusted users, e.g. company employees.
- npteljes 4y ago
  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.
  - Paianni 4y ago
    Those are affected. https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion_v7_20220712.pdf https://www.amd.com/system/files/documents/technical-guidanc...
cmeacham98 4y ago
How can it possibly require reading a few hundread kilobytes of memory to leak the root hash? Maybe I'm naive but I assumed it would be much faster.
- YZF 4y ago
  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.
  - p-e-w 4y ago
    > 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".
    - ncmncm 4y ago
      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.
      - zozbot234 4y ago
        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.

yomkippur 4y ago

so basically passwords are useless on these CPUs? What can we do? Use playstation 2 hardware to run linux?

photon-torpedo 4y ago
The root password hash is not sufficient to log in as root, but knowing the hash enables an attacker to run an offline brute-force attack to crack the password. Depending on the password complexity, this may or may not be feasible. That said, this attack may be able to extract other information from system memory that would enable de-facto root access, it depends a lot on what's running on the machine. > What can we do? Install the patches and enjoy the reduced performance. Or run Linux on ARM, and hope that noone will find similar exploits in the ARM architecure.
- yomkippur 4y ago
  So how complex does the password need to be? What if you have a 32 character password with mostly symbols, punctuations and non sensical strings mixed together? It seems like as quantumn computing gets better it would be a matter of time for them to crack any password going forward. Do we need an entire passage of the bible transformed into a password? I just assume it would be a lot more difficult to find the chimpanzee on the typewriter that can write a page from the bible purely by trial and error. That would take light years is my thinking but I could be wrong.
  - pishpash 4y ago
    Use physical tokens. Passwords is not the future.
    - MBCook 4y ago
      Is that an option for the root password on Linux?
      - SkyMarshal 4y ago
        Yeah, for example: https://support.yubico.com/hc/en-us/articles/360018695819-Ubuntu-Linux-20-Login-Guide-Challenge-Response https://support.yubico.com/hc/en-us/articles/360018695819-Ub...
        Hackbraten 4y ago
        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?
        SkyMarshal 4y ago
        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.
  - nomel 4y ago
    For an Nvidia 3090, you you can do around [1]: MD5: 65 trillion guesses/second SHA-512: 2 trillion guesses/second Blowfish: 100k guesses/second My root password is fairly short, since I type it all the time. I would be screwed if anyone had interest. I don't think relatively short root passwords are all that uncommon. 1. https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace72106d73fef https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace7210...
- XorNot 4y ago
  I am curious if there's any evidence ARM is fundamentally immune to this sort of exploit, or if we're just not looking hard enough yet?
  - jlokier 4y ago
    ARMs are vulnerable to several spectre-style exploits, and have mitigations that can be turned on at some cost to performance just like x86. 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-frequently-asked-questions?lang=en https://developer.arm.com/documentation/102587/0102/General-... https://developer.arm.com/Arm%20Security%20Center/Speculative%20Processor%20Vulnerability https://developer.arm.com/Arm%20Security%20Center/Speculativ...
  - NovaVeles 4y ago
    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.
  - okanat 4y ago
    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?
- ec109685 4y ago
  Password managers for every other password seem vulnerable?
  - YZF 4y ago
    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. So maybe don't quite panic yet. Developing story.
- woojoo666 4y ago
  So M1 macbooks are safe?
  - ncmncm 4y ago
    Hahahaha. No. 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.
- avianes 4y ago
  > 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)
jacooper 4y ago
These are password hashes, not the password it self.
- moring 4y ago
  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).
  - scandinavian 4y ago
    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.
Yuioup 4y ago
OpenBSD disables hyperthreading by default. There's that, I guess...
- bee_rider 4y ago
  I don't see the link (although, security stuff confuses me generally).
  - flatiron 4y ago
    For this there is no link. But having two processes share the same core at the same time could lead to problems.
Nursie 4y ago
> What can we do? 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?
- kelnos 4y ago
  What's the alternative, though? Nanny-state walled gardens like the Apple App Store? No thanks; I'll take my chances.
  - nafey 4y ago
    Write your own OS /s
  - deleted 4y ago
    [deleted]
  - weberer 4y ago
    I think parent comment was implying the alternative is NoScript
    - Nursie 4y ago
      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!
      - silon42 4y ago
        We need some kind of a code review system (peer based?) to review JS code that is allowed to be enabled.
  - Nursie 4y ago
    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.
IshKebab 4y ago
Don't let completely untrusted users on your systems. There are enough privilege escalation vulnerabilities in Linux that that was already true. It's still fine for semi-trusted users, e.g. company employees.
npteljes 4y ago
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.
- Paianni 4y ago
  Those are affected. https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion_v7_20220712.pdf https://www.amd.com/system/files/documents/technical-guidanc...

cmeacham98 4y ago

How can it possibly require reading a few hundread kilobytes of memory to leak the root hash? Maybe I'm naive but I assumed it would be much faster.

YZF 4y ago
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.
- p-e-w 4y ago
  > 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".
  - ncmncm 4y ago
    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.
    - zozbot234 4y ago
      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.