Live data from Hacker News

MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

mdsattacks.com

51–60 of 118 posts

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#51
post #23

Am I reading correctly that this has been under embargo for over a year?

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

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

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#52
post #22

In a Dutch article ( 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 ther…

Bigger is definitely not better for this kind of stuff at least as far as team sizes.

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#53
post #16

Commentary by Intel: https://software.intel.com/security-software-guidance/softwa... Commentary by RedHat: https://www.redhat.com/en/blog/understanding-mds-vulnerabili... ( https://news.ycombinator.com/item?id=19912108 ) Commentary by Ubuntu: https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigat...

Commentary by Chromium team: https://www.chromium.org/Home/chromium-security/mds

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#54
post #2

There 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

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

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#55
post #40

End-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, Kon…

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

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#56

Earlier quoted context omitted.

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

One CPU per process makes a lot more sense, especially now that we have so many specialized CPUs in our machines anyway.

Ye I got a feeling that shared processor time with strangers is not viable without specialized hardware.

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#58

It 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…

Hyper 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 ab…

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

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#59

It 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…

You can run Android and Linux apps on ChromeOS. And with PWA‘s and WebAssembly maturing the difference between native app and web app is getting smaller and smaller. Many developers use it for work. A lot of dev work in the enterprise isn‘t done locally anyway.
Post reply on HN