Intel ME: Myths and Reality [pdf] | Hacker News Reader

Intel ME: Myths and Reality [pdf]

events.ccc.de

74 pointszkms16 comments

The first section is weird: it compares random opinions from random social websites with another semi-random one from Hacker News (from someone who says it worked on it, but we don't even now at which level, and the "I think I would have known" part strongly make me think he actually would not have...), and lets conclude that secret services never had any stake in the design.

The unmarketed HAP bit is actually evidence they either can do some hack leveraging it, or at least are worried other services can or will become able to.

The theory that the complete subsystem would have been kept secret if it was of interest for secret services is also highly laughable. Especially when it is well known how they regularly leverage other marketed management/sideband services, for example in telecom equipment, to do their espionage operations.

As one of the authors referenced in the 'myths' section of the talk (the ME can do anything...), I have to disagree with the actual danger of the ME. It is connected directly to system memory, and from there you can actually do anything.

It's like saying "I have a car and can drive 20 miles, but being able to drive 2000 miles is impossible." Saying everything in impossible when you own the system memory is just a failure of imagination.

Systems going back to the first one, SCOMP (1985), NSA certified as secure had to mediate and pentest all software in the system. That includes firmware with SCOMP also having an IOMMU. The typical practice of high-assurance security in the 2000's was using separation kernels or ASIC's to force all input from untrusted subjects to be mediated on every access to a privileged component against a precise, security policy. From Orange Book onto Common Criteria, the fears about malicious management meant they usually put in a dedicated serial port for local, authenticated access to admin functions. Remote admin would need a serial or kvm switch with some security on it depending on what remote meant. If it was long-distance, there would likely be a Type 1 encryptor for link or IP layer.

Yeah, they've known it was a vulnerability for some time. Such a thing wasn't even allowed in secure systems with so-called "High Assurance Platform" being an attempt to mitigate risks in insecure boxes they know market will buy anyway. Stuff like SELinux Trusted Solaris, and so on go here. Recently, for SIGINT and/or politics, NSA is doing 90-day evaluations of COTS products to replace secure, Type-1 gear. The Assurance part that I saw had same requirements as EAL1: so low nobody certified to it to avoid being laughed at. I can only assume bringing in lowest grade stuff across whole DOD when medium assurance is already marketed is a BULLRUN-style subversion to boost surveillance. We don't need smart enemies with these kind of "Defense" policies.

Regarding keeping secrets, if that's one's perspective and belief. I think the whole thing would be too big to hide. So, you give it a legitimate purpose, and keep its subversion to yourself.

In reality, Intel was able to market it legitimately for its features. May well have needed to, in the face of competition.

But what may have been discussed in back rooms, with other interests -- ones that can't be ignored, and that also represent a big chunk of business? (Both purchases, and influence on trade, surveillance, and any number of other factors that affect one's business.)

Anyway, I think a whole processing subsystem would be too big and obvious to hide. Hiding functionality within it? Quite plausible.

And we have precedents, in this regard. (Fiber trunk and other splitting/tapping, e.g. the "ATT room"; the Clipper Chip agenda; weakening of NIST encryption standards; the scope of "inadvertant" domestic data collection;...)

Page 37: "WHAT CAN I DO ABOUT IT?"

Page 45: "WHERE'S THE INTEL ME FIRMWARE?" The Intel ME firmware is in the same flash chip of the BIOS/UEFI, in its own region.

Page 46: "Reading and writing it with an external programmer is quite simple." ..showing 2 pictures of raspberry pi connected to disassembled laptops with wiring all over the place.

How simple is simple I wonder :D

When I was in Shenzhen, one of the services offered in their electronics markets were laptop BIOS reflashes, and all they did was take the cover off and clip an adapter[1] to the chip for a few minutes. Once you have the hardware setup, it's not hard.

[1] https://www.aliexpress.com/item/SOIC8-SOP8-Flash-Chip-IC-Tes...

Same as installing coreboot for the first time. It's not "simple" for non-techs but generally it's easy to pick up if you know even a small amount about electronics.

I'm dumb as heck and I managed to get the wiring right and set an rPi up for SPI flashing.

Like very simple. Boards like Minnowboard actually have a header that you can connect a Dediprog SF100 to. No deadbugging required. eg. https://minnowboard.org/tutorials/updating-firmware-via-spi-... . Being able to sign that code is the real trick.

I would argue that the existence of the HAP bit, along with the ridiculous amount of found security bugs (that on almost every ME currently in the wild will not ever be patched, mind you) can be seen as the ME being used as a planted NSA backdoor, disguised as being a (useful) utility.

They get to exploit all the bugs to do their nefarious things and can neuter the ME of their own machines to not provide the same attack surface. I find it highly unlikely that the NSA did not know about how insecure the current ME generation is and I also find it very hard to believe that Intel would not have put any effort into pentesting it.

Or maybe it was just pure corporate greed on Intel's part after all. I fear we'll never know, unless another NSA leak happens that contains information about this.

Here's the recording from the talk: https://media.ccc.de/v/34c3-8782-intel_me_myths_and_reality

IMO the first half is almost useless, but the second one is actually worth listening to.

Like wilun said: The first section is weird. They are ruining the point they are trying to make when they say: "myth x" - and then they say it is basically true.

myth 1: and they come to the conclusion "pretty unlikely". So no you didn't mythbust - just you don't think it is true. Also, if it is made for solving real IT problems then why can't I disable it? (without using me_cleaner)

myth 2 conclusion: "yes, but it depends". So you are saying it is true.

myth 3 conclusion: "was possible, not anymore". You are saying it is true again.

myth 4 conclusion: "its complicated" - nobody said it was easy but its possible so that makes it true.

and so on ...

Igor Skochinsky is great. He explains it so anyone can understand (something becoming rarer these days), he is very helpful on Github too.

The presentation is basically a collection of social media posts made by self-described hobbyists who right from the start state they are not security researchers.

The relevance of this post is very limited.

They also wrote some scripts and ran some experiments, or did you stop reading after a while?

> or did you stop reading after a while?

Of course. How much time do you spend reading opinions on a highly technical field from hobbyists who readily admit they are no experts, and whose work is based on a hand-picked list of comments posted by anonymous people on social media?

I would gladly read the whole presentation from start to finish if it was written by experts talking about their research in their domain of expertise. This is not that.

The title is "myths and reality." Where did you think the myths were going to come from?

Reply on news.ycombinator.com