26 ms·

Retbleed: New speculative execution attack sends Intel and AMD scrambling

• uniqueuid 4y ago
  Oh no, not again. If there are enough of these attacks that don't involve ARM (I know some do), then I see a bright future for ARM servers. [edit]: Curious to see if Zen3 is also affected - if not, that would be great news.
  • trdtaylor1 4y ago
    Doesn't appear to be, additionally Windows deployments are not affected. Per Intel - "Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users."
    • olliej 4y ago
      It appears to be an attack specifically on the retpoline approach the Linux used to prevent the original specter attacks. Given it appears that Linux is the only OS that took that approach they’re the only one vulnerable? (The article explicitly calls out Linus ignoring warnings about this possibility)
      • gpderetta 4y ago
        Linux claimed it was not practical. Is this attack actually practical? Are 200-3kb/s sufficient for a realistic attack?
        • holycrapwhodat 4y ago
          > Are 200-3kb/s sufficient for a realistic attack? Yes.
        • marshray 4y ago
          So how many seconds would it take to leak your password at that rate?
          • olliej 4y ago
            Per the article 5-7 minutes for the root hash on the effected AMD systems? I'm guessing that's also not doing any kind of actual targeted traversal because if you can just do a heap walk you don't need anywhere near that amount of data.
        • pishpash 4y ago
          First dialup connections were 1200bps. Earlier adhoc connections were lower.
      • staticassertion 4y ago
        Someone should create an index of "Linus said this attack was impractical/ unimportant". I can think of a number of great examples off the top of my head.
  • ndesaulniers 4y ago
    Check the list from the Linux kernel patches: ``` + VULNBL_INTEL_STEPPINGS(SKYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(SKYLAKE_X, X86_STEPPING_ANY, MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(SKYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(KABYLAKE_L, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(KABYLAKE, X86_STEPPING_ANY, SRBDS | MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(CANNONLAKE_L, X86_STEPPING_ANY, RETBLEED), + VULNBL_INTEL_STEPPINGS(ICELAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), + VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(LAKEFIELD, X86_STEPPING_ANY, MMIO | MMIO_SBDS | RETBLEED), + VULNBL_INTEL_STEPPINGS(ROCKETLAKE, X86_STEPPING_ANY, MMIO | RETBLEED), + + VULNBL_AMD(0x15, RETBLEED), + VULNBL_AMD(0x16, RETBLEED), + VULNBL_AMD(0x17, RETBLEED), + VULNBL_HYGON(0x18, RETBLEED), ``` (I believe that zen3 is not affected) Via: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce114c866860aa9eae3f50974efc68241186ba60 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  • adrian_b 4y ago
    The researchers have tried their method against AMD Zen 3, Intel Alder Lake and Coffee Lake Refresh (a.k.a. 9th Generation Core) and it did not work against those. Intel Coffee Lake (a.k.a. 8th Generation Core) or older and AMD Zen 2 or older are vulnerable.
    • btdmaster 4y ago
      Where does it say that older (Intel 5th generation and earlier) versions are affected?
      • adrian_b 4y ago
        They have not tested CPUs older than AMD Zen 1, but based on the similar branch predictors they suppose that Bulldozer derivatives and Jaguar/Puma might also be vulnerable. Similarly, on Intel they have not tested CPUs older than Kaby Lake, but due to the similar branch predictors they suppose that Skylake, Broadwell and Haswell might also be vulnerable. Older CPUs than that might not have indirect branch predictors or the indirect branch predictors might be too simple, so this attack method might not be applicable.
        • btdmaster 4y ago
          I'm probably doing it wrong, but I'm getting SIGILL on Haswell for ret_bti and break_kaslr from the demo: https://github.com/comsec-group/retbleed https://github.com/comsec-group/retbleed Though it seems like the code is not portable (?) between CPU microarchitectures.
          • adrian_b 4y ago
            Since the attack method depends heavily on details of the indirect branch predictor obtained through reverse engineering, it is very likely that the code must be adapted to each different microarchitecture. The demo code probably also works in Skylake, which is almost identical to Kaby Lake, but for Haswell and Broadwell it probably must be modified, even if it is expected that this should be possible.
  • rayiner 4y ago
    In general, these attacks leverage the microarchitectural details of processors that implement speculative execution (which is nearly any modern processor). ARM processors can differ in their microarchitecture, so this particular exploit may or may not apply to them. It's not necessarily an "ARM" versus "x86" thing. (This specific exploit applies to a mitigation, retpoline, implemented in Linux. It appears that at least some ARM processors are vulnerable to the speculation attacks that make retpolines necessary in the first place: https://www.phoronix.com/scan.php?page=news_item&px=Google-Looking-At-AArch64-Retpo https://www.phoronix.com/scan.php?page=news_item&px=Google-L...)
    • pishpash 4y ago
      Doesn't change the practical effect of being slightly safer than the neighbor.
• rayiner 4y ago
  When will people realize that the problem is running untrusted code on the same CPU as code that needs to keep secrets?
  • bombcar 4y ago
    The problem is cloud, basically, where you're defined by running various VMs on the same CPU. Single-user systems can be affected by these, but they can be affected by more direct attacks.
    • merb 4y ago
      on clouds the only problem is HT. on vm providers it's cpu overcommitment (clouds rarely do that)
  • superkuh 4y ago
    Back in the 2000s pretty much everyone knew not to run un-trusted code ("don't open that email attachment"). But then javascript happened and the utility was so profound everyone decided to forget.
    • selfhoster11 4y ago
      Even if it's far from obvious to an average person that JavaScript is a pwn vector, I think you're more correct than not. You need enough isolation to run untrusted code. If JS code can still exploit CPU bugs, then clearly more isolation is needed one way or another.
    • mirashii 4y ago
      I think you're looking at the past with rose-colored glasses. ActiveX allowed the execution of unsandboxed x86 code from controls embedded in webpages and was enabled by default in Internet Explorer, the dominant browser of the time. Javascript caught on because it's at least interpreted and sandboxed, a huge step up from what ActiveX was.
    • ginko 4y ago
      Can't you mitigate just the Javascript VM? JS is a slow scripting language anyways. Seems like a waste to slow down the entire system.
• smegsicle 4y ago
  it says [dupe] but where's the good one?
  • ndesaulniers 4y ago
    Sorry, Dang fixed it up and told me to stop posting so many different links as new submissions. So I'll add a good list here: * https://comsec.ethz.ch/research/microarch/retbleed/ https://comsec.ethz.ch/research/microarch/retbleed/ * https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf * https://www.youtube.com/watch?v=dmSPvJxPm80 https://www.youtube.com/watch?v=dmSPvJxPm80 * https://arstechnica.com/information-technology/2022/07/intel-and-amd-cpus-vulnerable-to-a-new-speculative-execution-attack/ https://arstechnica.com/information-technology/2022/07/intel... * https://www.theregister.com/2022/07/12/amd_intel_retbleed/ https://www.theregister.com/2022/07/12/amd_intel_retbleed/ * https://www.phoronix.com/scan.php?page=news_item&px=RETBLEED https://www.phoronix.com/scan.php?page=news_item&px=RETBLEED * https://regmedia.co.uk/2022/07/12/handout_retbleed_amd.pdf https://regmedia.co.uk/2022/07/12/handout_retbleed_amd.pdf * https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html https://www.intel.com/content/www/us/en/developer/articles/t... * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce114c866860aa9eae3f50974efc68241186ba60 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... * https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html https://www.intel.com/content/www/us/en/security-center/advi... * https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00707.html https://www.intel.com/content/www/us/en/security-center/advi...
    • usr1106 4y ago
      I believe according the HN rules original sources should be preferred over journalistic coverage. But given the fact that probably a minority here will greatly benefit from the academic paper or the patches, I'd say the Arstechnica article is an excellent compromise. Edit: The article is well-written IMHO, but I nearly did classify "sends scrambling" in the title as clickbait not worth opening.
• nibbleshifter 4y ago
  > will add as much as 28 percent more overhead to operations. Yikes. I don't think I'll be enabling that mitigation on my workstation.
  • bicolao 4y ago
    Windows is not affected because it uses IBRS instead, which is less performant than retpoline. So the question is, is IRBS overhead less or more than 28% now?
    • mise_en_place 4y ago
      It begs the question, was speculative execution a good idea in the first place?
      • pcwalton 4y ago
        I highly suspect that a comprehensive accounting would show that any basic hardware optimization like speculative execution has saved the total worldwide computing industry hundreds of millions of dollars, if not more. At large scale, optimizations add up to enormous value.
      • pishpash 4y ago
        Compared to what alternative?
        • autoexec 4y ago
          slower processors with more efficient software? For as far as we've come with hardware, the actual user experience hasn't changed anywhere near as dramatically because faster machines just allowed people to push out slower software, the same way that hard drives moving from MBs to GBs to TBs just meant that games and applications bloated up to fill all available disk space and websites bloated up to consume increased bandwidth as we went from 56k to broadband.
          • 4y ago
• bredren 4y ago
  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
• jl6 4y ago
  Today’s episode of Modernity Is Built On Sand… I’m not clear why Windows is unaffected. Does Windows already use the recommended mitigations, and if so does it already suffer from the performance penalty?
  • hatenberg 4y ago
    windows uses a different mitigation, nor retpoline so it's not affected.
• usr1106 4y ago
  Maybe a stupid question... For user machines running JavaScript in the browser is the most common case of running untrusted code. Since 2018 when Spectre became public, has a single JavaScript program become public that exploits Spectre (whatever variant)? Unpatched user machines exist proably all the time. For the cloud where your neigbors might run whatever (bad) they come up with is this just a simple Linux vulnerability? (Or HW vulnerability Linux did not work-around well enough) Wouldn't you alway need to attack the hypervisor? Of course, that might be Linux, too. Has there been any piece of software published that just reads your neighbors memory? Of course major cloud providers patch at disclusure, but I'm sure there are smaller ones where it can take a long time. If yes, how could I miss that? If no, Linus hasn't been that wrong that the attacks are not feasible. Unless one assumes the NSA has been running them since 2018.
  • userbinator 4y ago
    Yes, JS demos existed, but the usefulness of the data you can extract was limited. Making sense of the extracted data has always been the difficult part, as even if you manage to find a key and can recognise it as such, you still need to know what it's securing and also have access to do anything more.
  • zdragnar 4y ago
    Google had a decent writeup and proof of concept for leaking via JavaScript: https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html 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/answering-your-questions-about-meltdown-and-spectre https://cloud.google.com/blog/topics/inside-google-cloud/ans... What retbleed means for this is anyone's guess, but I'd hazard a thought that it's not great.
    • deleted 4y ago
      [deleted]
• userbinator 4y ago
  The researchers said that it’s capable of locating and leaking a Linux computer’s root password hash from physical memory in about 28 minutes when running the Intel CPUs and in about 6 minutes for AMD CPUs. Presumably under very ideal conditions? I've been indifferent to all these sidechannel attacks since the original Spectre/Meltdown and continue to maintain my opinion that this is really not of any significance to a single-user PC.
  • api 4y ago
    It's of most significance to cloud hosts and other shared hosting providers where there might be targets of sufficient value to motivate someone to spend a lot of time and effort cracking stuff.
  • layer8 4y ago
    It seems likely that if no mitigations were made available, actual attacks would eventually surface. That aside, other attack vectors are currently still much easier to target. The interesting thing about side-channel attacks, compared to other attack vectors, is that they can’t be addressed without impacting performance.
    • itvision 4y ago
      Nothing has surfaced for the past four years that all these vulnerabilities were revealed. Not a single piece of malware uses any of https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerabilities https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...
      • whizzter 4y ago
        That we know of! Since timing attacks like this probably needs a bit of machine specific tuning it's probably not that much of an interest to regular mass-market attackers. But for APT groups that might need a wedge on particular machines it might be worthwhile, remember the length NSO group went with Pegasus.
  • inetknght 4y ago
• wyldfire 4y ago
  > The researchers said that it’s capable of locating and leaking a Linux computer’s root password hash from physical memory in about 28 minutes when running the Intel CPUs and in about 6 minutes for AMD CPUs. Given this attack vector, it makes some sense for relatively static secrets like these to be moved into something like the Secure Enclave where the CPU can perform signature verification but never store the secret itself in memory or cache. I know other ARM-based SoCs have these too. So presumably Intel and AMD offer something like this in their latest-generation CPUs?
  • kramerger 4y ago
    Maybe... AMD has the Secure Processor (an ARM), but it has other duties right now, such as system and VM memory encryption.
  • saagarjha 4y ago
    Putting something in an enclave doesn’t magically make it impervious to side-channel attacks.
    • nomel 4y ago
      > doesn’t magically I would say "by design" is much easier to achieve since physical space, slow interconnects, and "dumb" logic can be put between the two.
    • wyldfire 4y ago
      Here's how Apple describes their design of the Secure Enclave. I'd figure that Qualcomm, NXP, AMD, etc have a similar design. > The Secure Enclave Processor provides the main computing power for the Secure Enclave. To provide the strongest isolation, the Secure Enclave Processor is dedicated solely for Secure Enclave use. This helps prevent side-channel attacks that depend on malicious software sharing the same execution core as the target software under attack. > The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It’s designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks. The Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities, secure boot, a dedicated random number generator, and its own AES engine.
• causi 4y ago
  I wonder if eventually we'll have to have a "secure mode" operational setting where all speculation is disabled along with other extreme security measures any time a computer needs to handle credentials.
  • yababa_y 4y ago
    dedicating a single core to the task and interfacing with existing secure enclave / smart card like protocols would get you pretty far.
    • inetknght 4y ago
      Cores can share cache. Cache leaks from speculation are a thing. So dedicating a single core might not be strong enough countermeasure. There's of course little other recourse without a secure processor. I will be very saddened when a secure processor becomes required standard hardware because it will, no doubt, contain only phantom blobs that hinder ownership and promote corporate bullshit.
      • blackoil 4y ago
        Isn't MS Pluton already standard in all new processors?
      • jquery 4y ago
        Apple's maniacal control of their hardware is what makes my phone an excellent appliance but a terrible general purpose computer.
        • katbyte 4y ago
          My MacBook and Mac studio make pretty good general purpose computers.
  • itvision 4y ago
    Yeah, in this mode the CPU will just work 10 times slower.
• kwertyoowiyop 4y ago
  This is what happens when we stray beyond the true path: 6502.
  • spogbiper 4y ago
    the 6809 was better
    • NegativeLatency 4y ago
      IDK might be some danger lurking in all those extra instructions :)
      • crest 4y ago
        Just patch your compiler/macro assembler to insert HCF instruction before any conditional control flow instructions.
      • timbit42 4y ago
        If you're worried about extra instructions, the DEC PDP-8 has half as many as the 6502.
    • kwertyoowiyop 4y ago
      16-bit arithmetic? Sheer luxury! Every morning we had to wake up at midnight, rewrite all our math routines from scratch, then our manager would kill us all with a machete and dance on our graves! And we liked that just fine.
• DethNinja 4y ago
  How this exploit would affect the average ssh based system? Would it enable a privilege escalation path for password-less SSH key based accounts? Also, I thought it was common sense that sensitive data on RAM should be scrambled after use. There are many TLS implementations that scramble data on RAM after use, I thought Linux would’ve already implemented a similar system.
  • flatiron 4y ago
    You need to be able to run code on a machine. So server that you cannot log into isn’t vulnerable. This is for malware running as an executable or possible JavaScript through the browser (maybe web assembly too)
    • pantalaimon 4y ago
      Browsers don’t expose the high accuracy time sources anymore that are needed for this attack.
      • klabb3 4y ago
        So can this be fixed by making it more difficult to measure time, either through CPU ticks or multithreaded measurements? Can it be a privileged operation to have high accuracy timing? IIRC cloudflare workers (a multi-tenant cloud environment) sets a static "current time" for each request and disallow multithreading to prevent accurate time measurements.
• yomkippur 4y ago
  I'm convinced that cybersecurity is impossible. Any entity with the resources and command over talent and determination is capable of defeating any counter measures in the long run. It's like trying to fill up a bucket but by the time you find the hole and patch it, another one appears constantly, leading to exhaustion. Perhaps with AI we can drastically lower the cost of this exhaustive effort but so can the other side, employing AI to increase the cost. It would be like a never ending tug of war that just ends up taking up more and more resources, sort of like the nuclear arms race of the 60s which was only curtailed by both sides agreeing to commonly beneficial compromises.
  • ethbr0 4y ago
    Cybersecurity and quick software/hardware development are impossible. There are plenty of much more secure systems. They just iterate much more slowly, and are consequently much lower-performance or less-featured. For an extreme example, see what IoT's recent "all features, quickly" craze has done to their security posture.
  • deleted 4y ago
    [deleted]
• alasr 4y ago
  From the FAQ of ETH Zurich's "Computer Security Group" website: > Are only Linux systems affected? > We’ve built the proof of concept code for Linux. But, because the fundamental issue is at the hardware level, Microsoft and Apple computers with the affected hardware have this issue too. -- [1] https://comsec.ethz.ch/research/microarch/retbleed/ https://comsec.ethz.ch/research/microarch/retbleed/
  • tester756 4y ago
    >“Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users. Intel is not aware of this issue being exploited outside of a controlled lab environment.” hmm? so, how is it?
    • smileybarry 4y ago
      It's referring to Intel processors with hardware IBRS support, e.g.: Coffee Lake Refresh (e.g.: 9700, 9900) and newer. On those CPUs, Windows also makes use of IBRS alongside retpoline compilation of the kernel. See the table[1] in the linked article. 1: https://cdn.arstechnica.net/wp-content/uploads/2022/07/retbleed-by-cpu.jpg https://cdn.arstechnica.net/wp-content/uploads/2022/07/retbl...
• cosmiccatnap 4y ago
  I think speculation... Is just not in the cards for most use cases. Yes you can isolate cores and you can encrypt the data and use enclaves and all that with much effort and complexity and overhead might eventually fix the 90th percentile but in the end the core issue is simply the nature of speculation as a strategy to improve cpu performance.
  • stu2b50 4y ago
    IMO it’s the reverse. Not having speculation absolutely cripples processor performance. For most use cases, it’s clearly better to have the performance but accept the risk of these vulnerabilities. In the cases for which this is not true we need to selectively lock down speculative execution.
    • deleted 4y ago
      [deleted]
  • pishpash 4y ago
    Why is the issue speculative optimization, not unsafe code? We know what unsafe code is, remote code, code loaded from unknown sources, etc., so those can be segregated at a cost, while safe code runs with efficiency. If it's about unsafe code slipping through due to misclassification, well, there are more vulnerabilities than the processor.
• runlevel1 4y ago
  Are we at the point where it's irresponsible to run on shared tenant infrastructure? There seems to be no end to these attacks. Just brief periods of remission.
  • bee_rider 4y ago
    Think so. From an outsider (non-security) point of view at least. Speculative execution is basically required for fast single-threaded performance, and it also seems to be fundamentally incompatible with running arbitrary programs on the platform securely. We've all really invested in tricking ourselves into believing otherwise, but this is definitely a tick. It is a trick that many of our careers depend on, so we'll see various 'fixes' bandied about, but they won't solve tomorrow's hole. Programs running locally should be assumed to have total control. So, like, don't run evil programs. And disable Javascript in the browser. (For the client side, maybe Intel and AMD could put a special in-order, no-speculation, no-branch prediction core on their chips from now on, shunt Javascript to that by default).
    • dannyw 4y ago
      I migrated my ethereum PoS validation nodes from multi-tenanted cloud to a dedicated server for that reason.
• javajosh 4y ago
  Okay, lets say the current crop of CPUs is burned to the tune of 15-28%. What's next? Can this effect be mitigated in the next round of design? Is speculative execution always going to be problematic like this? Also, what can be done on the software side? Why is Linux so vulnerable, but not Windows? Is the kernel layout in Linux statically define or something?
  • staticassertion 4y ago
    (non expert thoughts ahead!) > 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.
  • tedunangst 4y ago
    If Zen 3 is already not vulnerable, don't even have to wait for the next round of designs.
• gzer0 4y ago
  In today's arms race of exploits, you need to operate and prepare your interactions with computers with a defined threat scenario. This is never-ending. > Linux creator Linus Torvalds famously rejected such warnings, arguing that such exploits weren’t practical. And I would certainly agree with Linus, here's why: > Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy. Retbleed adds more credence to this idea of impractical-yet-technically-feasible exploits; where do you draw the line? Do you choose to be vulnerable to this 219 bytes per second leak at the cost of 28% CPU overhead? I would imagine, one could toggle on or off the mitigations they'd want with the implications provided in the future via modifying BIOS settings.
  • nneonneo 4y ago
    A Bitcoin private key is 32 bytes long. /etc/shadow on my machine is 1080 bytes long. Heck, my entire password manager database is probably no more than a few KB in size. Sure, chasing the necessary pointers and data structures through the kernel or other user programs might add some overhead, but don't write off a 200b/s leak as harmless. It may well be enough to steal the secrets you care about the most.
    • deleted 4y ago
      [deleted]
    • deleted 4y ago
      [deleted]
    • shepherdjerred 4y ago
      This is a great case for developers using Electron. Nobody is every going to get anything meaningful from those apps at 219b/s -- there's far too much memory to read!
      • keyle 4y ago
        I think you're mixing things up. The valuable data isn't related to the load time of an application into memory.
• yabones 4y ago
  For anybody curious, here's the current status of the CVEs on Ubuntu and Debian. tldr, patches haven't been released yet * https://ubuntu.com/security/CVE-2022-28693 https://ubuntu.com/security/CVE-2022-28693 * https://ubuntu.com/security/CVE-2022-29900 https://ubuntu.com/security/CVE-2022-29900 * https://ubuntu.com/security/CVE-2022-29901 https://ubuntu.com/security/CVE-2022-29901 * https://security-tracker.debian.org/tracker/CVE-2022-28693 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-29900 * https://security-tracker.debian.org/tracker/CVE-2022-29901 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.
• ThinkBeat 4y ago
  Is there a way to disengage / opt out of all the mitigations? Several seem to seriously impact performance esp. in aggregate. If it includes updates to the microcode in the cpu I persume you cant get out of it?
  • TheWoodsy 4y ago
    Yes. Boot the kernel with the flag "mitigations=off". Run some benchmarks. It's not nearly as substantial as all the 'fear warriors' makes it out to be.
  • shepherdjerred 4y ago
    Microcode is loaded after boot right? I think it can all be disabled. Linux has configurable flags for mitigations.
• zx8080 4y ago
  This vector of attacks allows CPU makers legitimately __slow down__ existing CPU models and sell new ones. Anyone hopes these gonna be less of auch attacks anytime soon? Sure no, they are essential to sell more new cpus now!
  • kelnos 4y ago
    If Intel and AMD could drastically speed up their current CPUs, they would have already done so. This is definitely not a good thing for either of them.
    • tux2bsd 4y ago
      Imagine if software was forced to be more efficient...
• gok 4y ago
  Ok so can we now admit retpolines were a stupid idea?
• iam-TJ 4y ago
  Important to note that dynamically generated eBPF RETurn instructions are one of the vulnerabilities noted in the AMD paper [0]. [0] 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...
• mike_hearn 4y ago
  I took a look at the paper. Unlike the Hertzbleed attack this one seems to justify the bleed naming given the ability to rapidly locate the password hash (which can then be quickly brute forced back to the root password, most likely). However! There are caveats. It appears that modern Intel chips actually already mitigate this: > "We observed that eIBRS systems seem protected from RETBLEED. IBRS, which is the alternative for earlier systems, was considered too expensive to use in practice when Spectre was introduced in 2018. Flushing the entire BTB through IBPB upon kernel entry would arguably be even more expensive. Intel’s mitigation. Despite the performance cost of IBRS, it mitigates RETBLEED on vulnerable Intel CPUs. Hence, IBRS will selectively be enabled on systems that exhibit RSB-to-BTB fallback behavior that do not support eIBRS." Translated: • New Intel chips have better support for blocking this attack. You can get performance+security by using a new(ish) CPU. Windows already uses that support if present. Linux apparently doesn't, but will presumably migrate now the retpoline trick is broken. The big slowdowns would come for older CPUs without the right hardware to control these attacks. But, wait: "Concurrently to our work, Branch History Injection (BHI) [7] explored the limitations of eIBRS and found that indirect branch speculation can be hijacked to run previously executed indirect branch targets in the kernel. Whereas RETBLEED targets Intel CPUs without eIBRS and certain AMD CPUs, BHI targets Intel CPUs with eIBRS and ARM. Moreover, because of the limited number of disclosure gadgets available to BHI, unprivileged eBPF is required for practical exploitation, which consequentially has been disabled as a mitigation" Translating again: • Even with new Intel chips there's a way to break them but the conditions are so specific that no normal kernel compile will produce them. Instead you have to be able to JIT compile custom code on the fly that runs in kernel mode. The eBPF feature lets users do this, but, if you limit it to root then the problem goes away. Oh and also ARM chips aren't magically invulnerable or anything. Overall, I think this confirms the impression I already had for some time - despite whatever other issues it may have Intel is ahead when it comes to security. People aren't really looking for vulns in ARM chips though that may change now with M1. In fact even vulns in AMD chips are considered second tier and not that interesting. But, Intel chips have more features to stop speculation attacks. A lot of Spectre-type attacks have actually been addressed over time by new hardware features (usually in combination with OS patches), but chip makers seem to suck at communicating this to the general public. If you're worried about specex attacks then your best bet is to aggressively upgrade your CPU to stay on the leading edge, to ensure your OS and browser are always fully patched, and if you write software for Intel servers, to explore SGX enclaves which these days do a lot of pipeline flushing and partitioning on entry/exit.
• pdimitar 4y ago
  Guy who worked closer to the metal in a previous life but sadly moved to web development 13 years ago and who is now looking to exit the area and return to hardcore backend, sysadmin and general system scripting roles here, giving his uninformed (in the details) take: (TL;DR) Yes there are real risks in disabling the mitigations like I did but the combined chances of actually being targeted _and_ duped into installing something that greatly accelerates the pace with which my stuff can be exfiltrated, are minuscule. People love to talk about the "risk of event $A" but what's very often missed in these discussions that for an attacker to get exactly what they want from you they need the risk of several, if not many, events -- say, $A to $Z -- to be high at the same time which as we all know from math reduces the resulting probability severely (due to multiplication of several numbers and they are all less than 1.0). (/TL;DR) Several months ago I disabled all the mitigations on my home Linux server, and I plan to disable them on two laptops I'll install Linux on as well. The server is headless so the attack surface is drastically reduced (unless the package manager gets frisky with executing semi-random Python/JS scripts in pre/post installation phases). The laptops are riskier, and we know how insecure X11 is in general; it's a free for all game once a malicious program gets installed. To me the lost performance actually hurts. I have the before and after experience. I made a quick and small analysis of my risks. My router is reasonably secure and I've done some elementary homework e.g. VLANs to isolate the gaming machines, guest smartphones and other risky devices from the rest of our home's trusted devices, allow-list mine / my wife's / few friends' devices and disallow outgoing traffic for everything else. I am comfortable with my risk-to-reward ratio involved in disabling the mitigations. I get all the reservations (and I would love to return to working closer to the metal one day, too). I am aware that 219 bytes/sec is plenty enough for a persistent worm-like software to eventually exfiltrate everything* it needs. I am 100% sure it can be done. However: - It requires significant time and effort on the part of the attacker. They have resources, I know, but they very likely don't have foolproof exploits ready even for the original Spectre/Meltdown exploits. They require several layers of things going wrong on my machine for them to succeed. And I block most of the JS on the sites I visit. Chance is still bigger than 0% but IMO not enough to get scared. - It requires them to iterate on the said worm/virus many times because in no universe does any adversary have perfect programmers that create the perfect exfiltration software on the first try. Thus, them being able to auto-update the software on my machines is not a given because they get periodically updated and rebooted which might deprive them of the vector they used to get in (which might be ephemeral and stored only in memory or temporary files). Every several months I proactively upgrade the kernel which is yet another way for them to lose their way in. - It requires several* things to go wrong for me at the same time, for this particular exploit. Not very likely I think. I am not excellent with security but I generally wouldn't jump through hoops to install some obscure program that might be infected (whether the Linux distro package repos are already infiltrated and are serving the three-letter agencies is a scary question but one worth asking; still, nothing I can do about that. I won't stop using Linux). --- All in all, meh. If you are targeted by nation states or their contractors you have much worse things to worry about e.g. whether somebody in the Costa Rican cafe you work on your laptop that month from will call the police on you. If you are a high-profile target you wouldn't sit on your 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.