Earlier quoted context omitted.
It is nice to know lenovo already has the updates, but sadly I'm gonna have to install windows for that :(
Send me your IP and I'll patch it for you.
Wouldn't really work behind a NAT...
An in-depth security review of the Intel Management Engine
111–120 of 192 posts
Re: An in-depth security review of the Intel Management Engine
#112Does anyone have an idea to what extent macbooks are affected? Intel ME is baked in every CPU but according to The Register [0] the AMT part is not running on Apple hardware. [0]: https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulner...
Most reports I've read, including the one you have just linked, state Apple hardware as unaffected by this.
Re: An in-depth security review of the Intel Management Engine
#113What was wrong with IPMI for out of band management? What problem was ME actually solving?
Re: An in-depth security review of the Intel Management Engine
#114Earlier quoted context omitted.
> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonom…
>> or if they allowed complete disabling via motherboard jumper > That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) Then how does Intel disable it for governmental customers (high-assurance)?
The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the IOMMU, and the IOMMU itself is a hardened function; the translations that it performs for the OS do not involve the ME. And so on.
Though the ME currently performs some complex early initialization tasks, the notion that a modern x86_64 platform simply cannot work, or cannot work efficiently, without the ME running indefinitely/alongside the OS is plainly wrong.
Re: An in-depth security review of the Intel Management Engine
#115Earlier quoted context omitted.
>> or if they allowed complete disabling via motherboard jumper > That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) Then how does Intel disable it for governmental customers (high-assurance)?
The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the…
Yeah I always thought DRAM refresh was built into the hardware, so this was kind of shocking for me to read too. I assumed he knew what he was talking since I couldn't imagine why else he would think it's something done by the ME.
Re: An in-depth security review of the Intel Management Engine
#116Don't rush to apply the Intel ME patch!
Several HN users here (beefhash, jlgaddis, joe_the_user) have raised the possibility that applying the patch might make it impossible to get rid of the Intel ME entirely.
If you don't apply the patch, someone may come up with a nice new exploit (using the security bugs) to completely remove the Intel ME.
If you do apply the patch, it might close off possible exploits and you'll be left with an Intel ME that's impossible to remove.
Re: An in-depth security review of the Intel Management Engine
#117Wow all 6th, 7th and 8th gen are all vulnerable along with a bunch of Xeon processors. Even the laptop I am typing this on is vulnerable, this is going to be messy. Plus all the fun vulnerabilities like arbitrary code execution, unauthorized access to privileged content. These must be related to the blackhat talk coming up in December about hacking a turned-off computer and running unsigned code on ME [0]. Yep and th…
> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. In corporate use, these tools can be incredibly useful. If they were more transparent, then they could be used by normal us…
> I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there.
> If they were more transparent, then they could be used by normal users for remote administration as well.
The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. There aren't even any robust specifications for it (like those for ISAs); it's literally a black box -- and one granted terrifying access to both the system's internals and external network interfaces.
It's 10PM. Do you know if your ME has been provisioned by evil malware?
I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. It's not an innocent housekeeping microcontroller, it's one hell of a remote-access-tool, plain and simple. That intelligence agencies have demanded that Intel provide a bit to neuter the ME after its bringup is testament to that.
My personal computer isn't part of an enterprise/corporate network, and I don't want any RAT (nor an auxiliary CPU with network access that is waiting to be provisioned to act like a RAT) installed on it, the same way my house-lock isn't keyed with a master key that the police holds.
I (and most other end-users) do not need any sort of remote-management capability. We need trustworthy and robust computers that are capable of not leaking secrets and losing control to adversaries -- and "remote management" hardware is a severe step backwards from that.
Re: An in-depth security review of the Intel Management Engine
#118Earlier quoted context omitted.
>> or if they allowed complete disabling via motherboard jumper > That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) Then how does Intel disable it for governmental customers (high-assurance)?
The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the…
> The GP is simply wrong on many/most of its technical claims
I concur. Also regarding: ACPI, there often is an auxiliary microcontroller used to do power management and keyboard interfacing called "embedded controller" (sometimes there's also a mysterious ASIC, part numbers for them include Rohm BU77700KVT Toshiba TB62D515FG,TB62501F) that lives on some SMBus and with which the ACPI implementation, running on the main processor, talks with.
Re: An in-depth security review of the Intel Management Engine
#119Does anyone have an idea to what extent macbooks are affected? Intel ME is baked in every CPU but according to The Register [0] the AMT part is not running on Apple hardware. [0]: https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulner...
Most reports I've read, including the one you have just linked, state Apple hardware as unaffected by this.
Is there a official position/statement from Apple on this?
Re: An in-depth security review of the Intel Management Engine
#120Would you upgrade the firmware or leave it in?
Who knows what benefits this defect can give you down the line. Maybe it will be possible to take over the entire Management Engine. That would be neat.