11 ms·
MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs
- titzer 7y agoThere are 4 separate vulnerabilities in MDS, not just the one reported in the ZombieLoad paper. They each have CVEs. Chrome Browser response here: https://www.chromium.org/Home/chromium-security/mds https://www.chromium.org/Home/chromium-security/mds
- xucheng 7y agohttps://cpu.fail/ https://cpu.fail/
- wyldfire 7y ago> Linux users should apply kernel and CPU microcode updates as soon as they are available from their distribution vendor, and follow any guidance to adjust system settings. Canonical says that they have those for 14/16/18.04 [1]. But possibly more interesting is the fact that this disclosure has been so well synchronized. How do the relevant players decide what the threshold is for informing other tech companies? How does everyone know what policies that the constituent companies use to prevent early disclosure or unintended disclosure to 'somewhat-less-trusted-employees'? Is this all coordinated by US CERT? [1] https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigat...
- jchw 7y agoWell, practice makes perfect... by 2020 the process of disclosing CPU vulnerabilities should be pretty streamlined, if the pace doesn’t slow down.
- Twirrim 7y agoAs with Spectre/Meltdown, L1TF et al, Intel chooses who to loop in to their disclosure. All of it is tightly controlled under an embargo. Who they choose to involve is entirely their decision, and is likely based on previous experience with those parties and their likelihood of leaking. Intel doesn't want these kinds of things to leak before official communication is done, or it's pretty much guaranteed to impact their stock price. This time around has gone much smoother than the previous ones, though L1TF was pretty good too. L1TF was a little rough with the patching side of things because the patches were finalised a little late. The various distributions and companies knew that the embargo was due to end at 10am pacific, and were probably (like us) refreshing the security advisories page on Intel's site waiting to pull the trigger on all the relevant processes, like publishing blog pages etc.
- Ajedi32 7y agoWow, ChromeOS decided to disable hyperthreading entirely? That seems like a pretty drastic mitigation. I wonder if that's just a short term solution or if they're planning to leave it that way indefinitely.
- jlgaddis 7y agoOpenBSD preemptively did the same thing [0] in 6.4, released nearly a year ago. [0]: https://news.ycombinator.com/item?id=17350278 https://news.ycombinator.com/item?id=17350278
- StudentStuff 7y agoHyper-Threading has been a source of security concerns for a decade now, and vulnerabilities in existing HT implementations have been trickling out over the last few years. Unlike Management Engine or TrustZone, at least we can disable Hyper-Threading (for a 30% performance hit).
- rightbyte 7y agoThe security concern is remote code execution via JS, and sharing processor time with other people you don't trust, right? It should be up to the VM-as-a-service and browser vendors to flush the cache properly.
- compiler-guy 7y agoNo. The security concern is attackers reading data they shouldn’t. The article explains how. “Microarchitectural Data Sampling (MDS) is a group of vulnerabilities that allow an attacker to potentially read sensitive data.” That is way more serious than stealing cycles.
- silversconfused 7y agoOne CPU per process makes a lot more sense, especially now that we have so many specialized CPUs in our machines anyway.
- 7y ago
- Causality1 7y agoFor me as a home user, taking a performance hit of any kind in response to threats which haven't yet been seen in the wild simply isn't good math.
- jMyles 7y agoI don't think that anybody can know whether this is true, since exploitation leaves little evidence. Even before this is witnessed in the wild for the first time, you can't really know which secrets of yours have already been exfiltrated.
- Causality1 7y agoEverything that can't be fixed with a ten minute phone call to my bank is already public knowledge thanks to Experian, so I really don't have anything left to fear.
- sroussey 7y agoIf that is so, please leave your email and password here...
- jMyles 7y agoYou have no conversations that'd you prefer not be sold on the darknet? With friends, family, therapists, doctors, lawyers, consultants? No pictures of your kids that they might not want spilled into a searchable database and used for machine learning to sell them things later in life? No private or symmetric keys which might be used to impersonate you or eavesdrop on you later? No in-progress documents which you aren't ready to publish? No conversations with political allies that you might not want the state to peruse? No intimate conversations with sexual partners? If that's true, then I think you have a very different attack surface than most people. I think most people are willing to take a small performance hit not to open up access to much of the data that goes across their CPU, which is not an exaggeration for the combination of attacks which have been published against Intel CPUs over the past 3 years.
- JdeBP 7y agoThe overview page, https://cpu.fail/ https://cpu.fail/ , is on Hacker News as https://news.ycombinator.com/item?id=19911715 https://news.ycombinator.com/item?id=19911715 .
- sctb 7y agoThanks! We've merged these.
- dang 7y agoAnd unmerged them. See https://news.ycombinator.com/item?id=19912588 https://news.ycombinator.com/item?id=19912588. Sorry for the chaos but this was a weird edge case. The marketing maybe went overboard this time?
- Thorrez 7y agoWhat does "UC" in "Meltdown UC" mean?
- orhmeh09 7y agoMicrocode most likely.
- thro_away_n 7y agoAm I reading correctly that this has been under embargo for over a year?
- oasisbob 7y agoNearly a year, at least, judging by when the CVE numbers were assigned.
- kmfrk 7y agoIt was discovered June last year according to this timeline, so a lot of people must've successfully kept mum for a long time: https://mdsattacks.com https://mdsattacks.com.
- temac 7y agoMaybe we should start to seriously question the value of so long embargos. This is coordinated disclosure; if the vendor refuses reasonable coordination (and it seems Intel does, with such delays, and also because it stills silos the security researchers way too much), then fuck them and publish (probably not immediately but certainly not after a year...) It seems that broadly the same principles have been found independently by tons of teams. Expecting that well-financed actors have not explored that field and/or not yield any similar result at this point is completely insane. Meaning, given the high level of technicality required, it's even doubtful that the embargo protected anybody; it might be that no attacker exist (and I postulate will ever exist) that will be simply waiting for 3rd party disclosure before writing its own exploits in that class. On the other hand, typical security providers monitoring threats in the field might not be aware for a long time of the existence of such vulnerabilities. Now here arguably the first counter measures are similar to those for L1TF, so hopefully sensitive operators would already have disabled HT. However, it is not very cool to not make them aware of this additional (and slightly different) risk during such a ridiculously long period. Also: does Intel has competent people working on their shit anymore??? They know the fundamental principles; which is speculative execution on architecturally out-of-reach data, followed by a fault and a subsequent extraction via covert channels of un-rolled-back modified micro-architectural state. The broad micro arch is widely known, so do they really expect that 3rd party security researchers won't found all the places where they were sloppy enough to speculatively execute some code on completely "garbage" data? Or were they themselves unable to do a proper comprehensive review, despite having access to the full detailed design (and despite a dedicated team having been created for that)? In either case, this is not reassuring.
- gambler 7y agoIt seems that we need to move away from clever, complicated low-level micro-optimizations that rely on mangling instructions and just use more cores. That should allow for simpler security model.
- kccqzy 7y agoThere are plenty of scenarios where synchronization overheads between cores dwarf the performance gain, but OoO execution can help. But maybe instead of having more cores, we should expose the different execution units within a CPU core to the architectural level? That however brings back memories of Itanium, and the general fact that compilers just can't do static scheduling well enough.
- api 7y agoI've started to think Itanium might have been sort of on the right track but ahead of its time and in some ways poorly executed.
- kccqzy 7y agoI still don't think so. Exposing these microarchitectural concerns to the architectural level limits flexibility. In order for compilers to efficiently schedule multiple execution units, the compiler needs to know the exact latency of all instructions. That may be doable for arithmetic, but varies greatly from one generation of processor to the next. And compilers definitely cannot know the latency of a load: from a few cycles in L1 cache, to a few thousand cycles in DRAM, to millions of cycles if there's a page fault. And these things vary a lot, not just between processor generations but within the same processor generation.
- JdeBP 7y agoCommentary by Intel: https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling https://software.intel.com/security-software-guidance/softwa... Commentary by RedHat: https://www.redhat.com/en/blog/understanding-mds-vulnerability-what-it-why-it-works-and-how-mitigate-it https://www.redhat.com/en/blog/understanding-mds-vulnerabili... (https://news.ycombinator.com/item?id=19912108 https://news.ycombinator.com/item?id=19912108) Commentary by Ubuntu: https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-microarchitectural-data-sampling-mds-vulnerabilities https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigat...
- tarlinian 7y agoSome additional pages by Intel describing mitigation techniques for non-HT domains (including the new overload of the VERW instruction): https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling https://software.intel.com/security-software-guidance/insigh... Details of which steppings of which processors are affected by which CVEs: https://software.intel.com/security-software-guidance/insights/deep-dive-cpuid-enumeration-and-architectural-msrs#MDS-CPUID https://software.intel.com/security-software-guidance/insigh...
- rurban 7y agoThey advise only to use lfence, similar to compiler vendors. I advise to use a full mfence instead when clearing secrets. Load/store ordering is violated in caches. And cleaning secrets is done not so often, it needs to be reliable. MDS is thanksfully only for small data, and modern keys are much larger. But adding a simple verw for the tiny non-cache buffers does not hurt either.
- mtgx 7y agoCommentary by Chromium team: https://www.chromium.org/Home/chromium-security/mds https://www.chromium.org/Home/chromium-security/mds
- josh2600 7y agoAm I reading this right? It looks like this bug lets you read any part of an intel chip's processing payload in-flight? That's gnarly if true.
- Theodores 7y agoIt is funny how ChromeOS is the most ridiculously secure of the commonly available operating systems. It is not as if you can do much other than surf the internet with it. It makes me chuckle to think that my not-so-computer-literate friend whom I gave a Chromebook to is protected from anyone snooping in on Youtube, Hotmail and Youtube running on this toy machine (designed for 9 year olds). There really is nothing to hide there. Meanwhile, people doing important work on proper computers are properly vulnerable to this new Hyperthreading theoretical attack. I will be interested to find out if there is a drop-off in performance on ChromeOS, e.g. Youtube stuttering whilst the whatsapp web tab updates itself with a new message. If there is nobody complaining then why did we need Hyper-Threading in the first place?
- saagarjha 7y ago> It is not as if you can do much other than surf the internet with it. You can run Android apps and run Linux programs.
- silversconfused 7y agoHyper threading was an intel stop-gap reaction to the athalon64 x2, which was a REAL dual core, to buy them time while the pentium D was created and later laughed off the market. We finally got an "OK" dual core from intel when they decided to hack pentium 3 cores together and call it the Core duo, and with the core 2 duo they finally caught back up to AMD (by hacking amd64 instructions onto the P3 cores) and were able to start taking market share back. Nothing interesting happens between then and threadripper, but now we would be back to eating popcorn and watching the rest of the fight..... but the fight is over and everyone is over in the other arena watching arm and webkit winner-take-all style demolishing the incumbent platforms.
- temac 7y agoCalling Core duo a Pentium III core, esp. when talking about microarchs, is a slight misrepresentation. Of course it was way closer and more of a derivative of the PPro descendants. But P6 did not vary a lot between PPro and P III, while before reaching Core Duo it went through Pentium M, and then enhanced. So yeah, it looks like more a Pentium III than a Pentium 4, but it was certainly not just a "hack [gluing] pentium 3 cores together" Also Netburst was not that bad. It was a dead-end, yes, but on some markets it could compete with what AMD had. Plus implementing SMT is not necessarily extremely easy compared to SMP, especially when you evolve designs. And anyway, Intel shipped HT way before AMD shipped the Athlon 64 x2...
- thijser 7y agoIn a Dutch article (https://nos.nl/artikel/2284630-nederlanders-vinden-beveiligingslekken-in-intel-chips.html https://nos.nl/artikel/2284630-nederlanders-vinden-beveiligi...), one of the researchers says "het aantal mensen bij bedrijven als Intel die zich op dit niveau met beveiliging bezighoudt, is echt op de vingers van twee handen te tellen." = There are 10 or fewer people working on security at this level at companies like Intel. This sounds very hard to believe to me. With the previous attacks there surely are bigger teams working on this kind of stuff?
- baq 7y agohow much more would you expect? 10 people is pushing the two-pizza limit.
- thijser 7y agoPeople don't necessarily need to be in one big team. Lots of things that are important can be worked on by more than 10 people. (Surely Google and Facebook each have more than 10 people working on security). Is there evidence that so few people are working on security at Intel?
- peteradio 7y agoBigger is definitely not better for this kind of stuff at least as far as team sizes.
- api 7y agoThere are probably fewer than 1000 people in the world capable of finding these kinds of vulnerabilities. Sounds about right to have 10 at Intel.
- deleted 7y ago[deleted]
- mehrdadn 7y agoAlso for MDS: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html https://www.intel.com/content/www/us/en/security-center/advi... I like how Intel prominently thanks their own employees for finding the bugs and later simply acknowledges the existence of any anyone independent reporters with zero thanks.
- BorRagnarok 7y agoInteresting. This could mean that Intel actually discovered and thus knew about all those security-holes before the non-Intel researchers did. Or they're just being awkwardly disingenuous here, that's also a possibility.
- dexen 7y agoEnd-user security, in web browser context: do I understand it correctly that if my browser was to only ever execute JavaScipt in bytecode format (without compilation to native code) it would be safe from those kinds of exploits? Presuming the bytecode interpreter would be "slow enough" and "jittery enough" and "indirect enough" to hamper any attempts at exploiting subtle timing+memory layout bugs like that? IIRC, Konqueror (of KDE) had reasonably fast bytecode JS engine. I wish the browser was still undergoing fast development, used to be my daily driver for many years.
- sigotirandolas 7y agoAFAIK, there are techniques to detect and denoisify minuscule timing differences over millions of samples, and the fundamentals of most techniques apply to interpreters as well, so it is not a solid protection. That said, it would make things harder in practice since you’re introducing an extra indirection level and just making everything slower. As for interpreters in modern browsers, I’d be surprised if there’s no way to entirely disable the JIT somehow... since most JIT implementations I have seen have an interpreter fallback for debugging and easier portability to new CPU architectures.
- olliej 7y ago[edit: I finally finished reading everything. It seems like these new leaks can be triggered from JS as they still fundamentally reduce to "read time for memory access"] For spectre simply having attacker directed control flow was sufficient - so logically almost any scripting language could be exploited. Same goes for most of the TLB attacks. Others required native code because they needed to use specific instructions (that aren’t going to be emitted intentionally by any compiler - jit or otherwise).
- Rafuino 7y agoBetter Intel page on the MDS vulnerability is here: https://www.intel.com/content/www/us/en/architecture-and-technology/engineering-new-protections-into-hardware.html https://www.intel.com/content/www/us/en/architecture-and-tec.... Interesting point: "MDS is addressed in hardware starting with select 8th and 9th Generation Intel® Core™ processors, as well as the 2nd Generation Intel® Xeon® Scalable processor family." Looks like my 8700K isn't on the list though.
- fakwandi_priv 7y agoAccording to the researchers in the paper[0] this is not true. >We have verified that we can leak information across arbitrary address spaces and privilege boundaries, even on recent Intel systems with the latest microcode updates and latest Linux kernel with all the Spectre, Meltdown, L1TF default mitigations up (KPTI, PTE inversion, etc.). In particular, the exploits we discuss below exemplify leaks in all the relevant cases of interest: process-to-process, kernel-to-userspace, guest-to-guest, and SGX-enclave-touserspace leaks. Not to mention that such attacks can be built even from a sandboxed environment such as JavaScript in the browser, where the attacker has limited capabilities compared to a native environment. [0] https://mdsattacks.com/files/ridl.pdf https://mdsattacks.com/files/ridl.pdf
- Rafuino 7y agoI searched the the paper and it doesn't seem to falsify what I linked to, but I'll have to dig deeper into the research. "Recent Intel systems" isn't specific enough.
- annoyed_lurker 7y agoPage 16 in the slides[1] lists vulnerable processors, 8700K is one of them [1] https://mdsattacks.com/slides/slides.html https://mdsattacks.com/slides/slides.html edit: This is mentioned in the paper as well, on page 8
- deleted 7y ago[deleted]
- bigato 7y agofunny that you don't see their email address for contact if you don't have javascript running, which is exactly one of the doors for this kind of vulnerability as they mention on their site
- outworlder 7y agoAgain, Intel CPUs only.
- neop1x 7y agoCan I ask for money back? Intel should return 30% cost of all vulnerable CPUs then... because disabling HT is effectively reducing the claimed performance specs.
- dfrage 7y agoForeshadow/L1TF is the only prior problem of this nature that is unique to Intel. Meltdown bugs were also found in ARM and IBM POWER and mainframe designs, and Specture hits all of those and AMD as well.
- classic959 7y agoThe interactive guide on that page is an effective way to visualise the components in relation to the attacks. Does anyone know what this would have been built with?