Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disabling Intel ME 11 via undocumented mode

blog.ptsecurity.com

Post reply on HN
Print view View original

121–130 of 228 posts

Re: Disabling Intel ME 11 via undocumented mode

#121

Post by wolfgke »

cyphar wrote: post #58
codedokode wrote: post #47

Earlier quoted context omitted.

It can be useful for other purposes too, for example for enforcing DRM so that DRM code runs on a ME engine. And of course DRM code can be backdoored too so playing a specially crafted video would run code from it.

Intel ME is not an effective DRM scheme. You need to be exceptionally careful when you mention DRM, because if it becomes commonly believed that Intel ME could be used to implement DRM all of a sudden the DMCA comes into play. Research into Intel ME vulnerabilities becomes a federal crime.

> because if it becomes commonly believed that Intel ME could be used to implement DRM all of a sudden the DMCA comes into play. Research into Intel ME vulnerabilities becomes a federal crime.

This is rather an argument against DMCA or an argument why researchers working in this area should consider leaving the USA.

Re: Disabling Intel ME 11 via undocumented mode

#122

Post by wmf »

userbinator wrote: post #109

Nonetheless, our research team (Dmitry Sklyarov, Mark Ermolov, and Maxim Goryachy) Dmitry Sklyarov! There's a name I haven't seen in a while... good to see he's still actively doing this stuff. The immense complexity of the base firmware and hardware in a modern system is astonishing. XML, MINIX, and three(!) complete 486 cores in the PCH. Given this amazing feat of engineering, and the goals of the ME, it makes me w…

In my experience firmware is developed by an underclass who are happy to have any decent-paying job at all.

Or maybe the people who work on the ME realize that it's far from the largest risk in the system.

Re: Disabling Intel ME 11 via undocumented mode

#123

Post by [deleted] »

mnbghj wrote: post #90
carapace wrote: post #75

Earlier quoted context omitted.

Years and years ago, when color printer/scanners were fairly new, I tried to scan and print a $5 dollar bill. I was curious. The machine printed out about a third of the image but the rest of what it printed was a very official looking notice to please call the US Treasury. (edit: HP was the manufacturer.)

Likely to do with the EURion constellation: https://en.wikipedia.org/wiki/EURion_constellation Another item of interest may be printer stenography, in which every piece of printed paper, seemingly from every printer, can be traced back to make, model and potentially even the unit used to print it: https://en.wikipedia.org/wiki/Printer_steganography

[deleted]

Re: Disabling Intel ME 11 via undocumented mode

#124

Post by wolfgke »

v4n4d1s wrote: post #30
dabockster wrote: post #27

Does AMD have anything like Intel ME on their chipsets? I recently completed a Ryzen build and am curious.

Search for "AMD PSP".

> Search for "AMD PSP".

To quote https://news.ycombinator.com/item?id=14803645

"AMD seems not to use the brand name "AMD PSP" anymore. Instead some years ago they began to use the name "AMD Secure Processor". Nevertheless it is just the same: Read the small footnote at http://www.amd.com/en-gb/innovations/software-technologies/s... which begins with 'AMD Secure Processor (formerly “Platform Security Processor” or “PSP”)'."

Re: Disabling Intel ME 11 via undocumented mode

#125

Post by tomxor »

Q: How does one actually determine intel ME is present in a CPU... I've got an old P8600, I can find no definitive list of CPUs or ways to test for it. Some articles say all intel CPUs since 2006, others say only the newer "core" brand.

Re: Disabling Intel ME 11 via undocumented mode

#126

Post by wolfgke »

rubatuga wrote: post #49
eganist wrote: post #32

Earlier quoted context omitted.

My understanding is this step isn't really a necessity but rather was done to prove that ME could be disabled at an extremely low level since the missing binaries would no longer trigger what's effectively a failure condition. Could be wrong. Probably safer to just set the killbit rather than also tamper with ME directly is ultimately my point. That's my risk aversion at work.

I'm simply intrigued how this bit has managed to elude so many developers and hackers over the years. It's literally an option in an intel software tool, and yet you have people who have vehemently complained about Intel ME for the past few years. I have some serious cognitive dissonance going on right now.

> I'm simply intrigued how this bit has managed to elude so many developers and hackers over the years.

Lots of hackers already knew that for many years - I would rather call it "common knowledge". But they had no idea what one could do to change anything about this. Just like "AMD PSP"/"AMD Secure Processor" - it is common knowledge that it exists, but we have no idea what it really does or how one can disable/disarm it.

Or baseband processors - you can be pretty sure that there exist backdoors. I always tell people that they should throw away their mobile phones and love to say that they are bugging devices with integrated telephony functions - in this order; and this is true even if we do not assume any evil backdoors - for those reasons I don't own one. But people don't care.

Or have you never considered why Intel pushed Wifi so much (Intel Centrino)? Doesn't Wifi (or "accidental" bugs in the chip firmware for it) look like a backdoor that can also be used over an air gap? If you need a further point on this: https://puri.sm/posts/hard-not-soft-kill-switches/ Why does the PCISIG M.2 NGFF standard require that a pin has to be pulled high do disable Wifi and Bluetooth? I always tell people that they should avoid Wifi and use ethernet instead. Also to no avail.

Re: Disabling Intel ME 11 via undocumented mode

#127

Post by forapurpose »

arca_vorago wrote: post #93
nickpsecurity wrote: post #79

Earlier quoted context omitted.

They added it for business reasons for remote monitoring and control since enterprises like it. That's a large part of their sales. It also had consumer benefits. Related tech also helped DRM machines through Trusted Computing alliance. And they probably got defense contracts or payments for selective use by NSA or other organizations. Lots of return on that investment. Lots of reasons unrelated to those you mention.

>remote monitoring and control There are opensource ways to do out of band management without it. >consumer benefits. Related tech also helped DRM machines through Trusted Computing alliance. Nobody I knew who was knowledgeable wanted that shit in the first place. It was always edging away consumer control of the platform. DRM is part of the problem here! Same thing with web standards. What annoys me the most about t…

>>remote monitoring and control

> There are opensource ways to do out of band management without it.

I'd be surprised if there is a cost-effective open source alternative to this requirement: Remotely access and control a computer under any circumstance where it has power and a physical network connection. Solutions like AMT work even if there is no functioning processor or memory, because ME provides its own processor and memory. The open source alternative would need the same hardware.

At best, it would mean the corporate IT department designing, buying, installing, integrating, and supporting additional hardware, for tens of thousands of computers. That's very hard to justify when the computers come with hardware already installed, integrated with everything else, and supported by the vendor.

If someone could put FOSS on ME (or competing proprietary solutions), I'd be all for it. I suspect it would be very difficult, as we can't even figure out how to disable ME.

Re: Disabling Intel ME 11 via undocumented mode

#128

Post by wolfgke »

rsync wrote: post #85
throw2016 wrote: post #12

The more details leak about ME the more shocking it becomes. Why is this accepted in any free democratic society? There can be discussions, there can be debates but in everyday life this is already accepted. And even if one does not want to accept it what are the choices given similar technology is now integrated in other processors? If we accept that computers are essential to operate in modern society then this is…

"There can be discussions, there can be debates ..." Can there be ? If ME is part of DRM platforms (and I believe it is) then disabling it is circumvention of a digital copyright mechanism which brings the DMCA into play. "The lawsuit against 2600 magazine, threats against Professor Edward Felten's team of researchers, and prosecution of the Russian programmer Dmitry Sklyarov are among the most widely known examples…

This is rather an argument against DMCA or an argument why researchers working in this area should consider leaving the USA.

Re: Disabling Intel ME 11 via undocumented mode

#130

Post by totony »

eganist wrote: post #32
totony wrote: post #26

Earlier quoted context omitted.

Thw article also mentions removing some non critical binaries and modifying the ME filesystem

My understanding is this step isn't really a necessity but rather was done to prove that ME could be disabled at an extremely low level since the missing binaries would no longer trigger what's effectively a failure condition. Could be wrong. Probably safer to just set the killbit rather than also tamper with ME directly is ultimately my point. That's my risk aversion at work.

I believe you're right

"Once the DID is received, BUP—depending on the mode, which is determined by various factors—either starts IBL processes from InitScript (in normal mode) or hangs in a loop, which it can exit only when it receives a message from the PMC, for example as a result of a request to restart or shut down the system."

But I am not sure if those are stopped: "Secondly, it starts a whole string of processes; some of them are hard-coded (SYNCMAN, PM, VFS),"

Since the authors only mention that the InitScript/IBL Processes are not started, I assumed the hardcoded ones were started, but could be prevented from loading in the following way: "2. In the CPD section of the FTPR, remove or damage all modules except those required by BUP for startup:"

Post reply on HN