Wow 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 the two researches doing the talk are the two people credited in this announcement, Mark Ermolov and Maxim Goryachy. Great work by them finding these vulnerabilities and disclosing them, these are the kind of vulnerabilities that the NSA would salivate over.
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. The cynic in me thinks that this will change absolutely nothing.
There is a great website called The Bad Thing [1] that has compiled the known information about Intel ME.
I just ran the detection tool on my laptop and I am running a vulnerable version of Intel ME, but I can't even do anything about it until my system manufacturer provides a patch for it. I feel like this is going to be one of those situations that ends up leaving millions of devices unpatched and vulnerable a few years down the road.
> 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 users for remote administration as well.
But it needs to be secure, and it needs to exist without secrecy. If this portion were free for the user to configure, or if they allowed complete disabling via motherboard jumper, or simply open sourced it, that would be a better step.
However, the NSA's activities have destroyed all trust in these sorts of features coming from an American company, so even if it were completely open sourced, there's no guarantee that there isn't other hardcoded ROM also executing in tandem with the open source components.
> 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.
> 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.
Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying to distance yourself from it. Maybe you don't like the words "non-libre" or "proprietary" but you certainly seem to be arguing for the same thing that they are arguing for.
> 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.
Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want.
Again, maybe you don't like the way people argue for it, but you're arguing for the same freedom that others want.
The source code won't give you shit. Even if you have it all, right here, right now:
1. you cannot disable it completely - there's an image of Intel ME, burned into the chipset, which checks for the presence of the ME + AMT in the SPI flash, and it checks for signature. (There's an exception to this, with skylake and above)
2. you cannot run a modified or reverse engineered version of it, unless you have Intel's private key to sign your own binary.
Well, source code under GPLv3 would prevent this too. The source code is one building block, but it's not the only one. It does seem like a necessary building block to begin with, though. Otherwise, how could you make the hardware do what you want it to do if you don't even have access to modify what it's currently doing?
Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want.
Access to the firmware binary running on the ME processor and documentation for the latter would be even better than having source, since the latter assumes you trust the toolchain too.
If you live in a city apartment, it’s likely locked (at least in part) with a key that the fire department holds. In Seattle in the mid 2000s we had a spate of hundreds of breakins due to ill secured fire dept master keys (in cheap lock boxes).
> 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 autonomously by the PCH these days, with the CPU just asking the PCH to "get it done." And the logic that runs in the PCH to interpret those requests and decides when and how to apply them, is executed by the ME.
The ME only managed to not exist previously, because mainboards were previously both "simpler" (every bus spoke exactly one protocol and the controller chip for that bus did the protocol signalling) and more complex (tons of single-purpose controller chips.) The PCH boils all that down to one chip, and it needs a CPU to do it, and that CPU is the ME. Getting rid of it would mean going back ~15 years in computer capabilities.
(Another way to think of the PCH is that it's basically an SoC chip, with the "heavy lifting" of application execution moved out to a separate, upgradable CPU socket. But, like any SoC, it still does need some sort of internal CPU. The ME is that CPU.)
>> 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.
This is backed up by older systems working fine with the ME firmware completely removed, and on newer systems, for 30 minutes before a watchdog triggers: https://github.com/corna/me_cleaner
> 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.
On newer Thinkpads, the firmware for the EC is on the same SPI Flash as the ME firmware, but on a different partition. The EC is an entirely separate chip (labeled ThinkEngine) and by virtue of being only on SMBus is a lot less dangerous.
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.
Are you sure? As I understood it, the first two things that the ME runs on boot do much of that configuration. I can never remember the name of the first, but the second is the bring-up (or BUP) module.
It's sad to me that manually setting an IRQ is so horrible a prospect that it's better to compromise the entire system.
Honestly, I don't understand why there needs to be another CPU in the system. Do systems really need arbitrary bus protocol translation in real time? If people could agree to reasonable standards (a real possibility in the technological asymptote we have entered) we can eliminate this complexity entirely.
Then we can worry about something else, which is secretly embedding mini-CPUs into the CPU itself.
> Honestly, I don't understand why there needs to be another CPU in the system.
There are tons of processors in modern systems. Most separate chips for controlling sub-systems have them, like DRAM, NICs, USB, keyboards, monitors, storage devices, video cards, etc...
The reasons are performance and flexibility - when separate components act like remote hosts, the device manufacturer can divide up work between the OS driver (main CPU) and target system as desired.
To add to that: this is really nothing new, hard drives have had such chips for decades now, and even floppy disk drive for Commodore [0] was powered by its own 6502 CPU back in the 1980s.
Ehm, on my Haswell motherboard there is a HW jumper called "ME disable" and it works quite fine...
Also people have found different methods to set a bit that effectively shutdown the ME: These were put there by Intel even if they aren't official or supported for the general public.
I agree with your overall conclusions, but I am having a hard time imagining the 'normal users' who would use remote administration... though perhaps if that were normal-for-HN users...
Whenever my HTPC gets borked (it's a Hackintosh, it gets borked a lot), I regret not buying a "Q" motherboard. As it is, to fix the box, I have to temporarily switch the HDMI cable to the internal graphics, plug in a USB keyboard and mouse, and then sit down in front of it on the floor, craning my head to look at my TV beside it. With AMT access, I just could remote into the BIOS from my laptop on my couch.
IPMI is fantastic, so long that the understanding is in place that access to your IPMI vlan may as well be considered root access to the node. BMCs tend to be pretty miserable when it comes to security. It's generally a good idea to have ACLs in place to ensure BMCs can only communicate with a secured management node, and importantly that BMCs cannot communicate with each other.
And even if all the dedicated IPMI ports are on a separate switch, if you have root on one box, you can attack another via the IPMI network. You have to put ACLs on the switch to prevent traffic except to the admin node.
If you have a hard time imagining normal users who would use this, then I suggest you grow your imagination and teach users what possibilities there are.
Normal users can be sold on the idea of devices talking to each other (though in the case of Bluetooth I'd say it may have soured them on the whole thing). But I'd still say that even convincing a non-dev that wake-on-lan would be handy for them is a stretch, let alone more... Also I'm not sure how much evangelism is really appropriate - I may think that shelling into my headless server at home is great, but if you are happy with just cat videos, who am I to say you need to do more?
> I just ran the detection tool on my laptop and I am running a vulnerable version of Intel ME, but I can't even do anything about it until my system manufacturer provides a patch for it.
I would carefully analyse if patching is a good thing.
Those vulnerabilities might be used in good way to disable ME and all this intel crapware completely, while if patched, this again may be impossible without doing manual chip clip and reprogramming with external device. Of course YMMV.
> these are the kind of vulnerabilities that the NSA would salivate over
No need to salivate over something that you paid for and that you already used for 8 years.
Post-Snowden if you believe the NSA has already broken into most things and has very often paid to facilitate this (like loss-making Skype US server routing, or inefficiently using valuable silicon space for IME), you are no longer a conspiracy theory lunatic - you are just a mere sane person applying Occam's razor.
I don't think it's necessary to pay when you can just threaten charges of treason (Melissa Mayer) or make an example out of the uncooperative (Joe Nacchio).
> 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
Our brightest hope for reform involves (a) a breach involving ME and (b) European regulators laying fines on Intel.
What about fully libre firmware such as libreboot? What about isolating and disabling the ME as what Purism has done? What about fully open processors based upon open instruction sets such as RISC-V?
> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors
They clearly invested some serious money into this sort of thing and see it as a differentiator (or AMD wouldn't have followed suit). Chances that they'll throw it all away because of a few vulnerabilities are very, very thin.
AMD has had their own version of this for quite some time. Its called the Platform Security Processor (PSP), it has been in anything AMD since around 2013 [0]. I am not sure if Ryzen / Threadripper has it, but I would be surprised if it didn't.
If I'm not mistaken, PSP is not at all like ME, it runs code if you supply it with such but on it's own it doesn't listen to network traffic or run it's own OS, atleast, last I checked.
I'd still consider AMD the better player in the game.
Throwing it away is unlikely but the fact that this affects Xeon processors means that pretty much every single data center across the world could be affected. And that means that a lot of companies with a lot of money will complain.
> Wow all 6th, 7th and 8th gen are all vulnerable along with a bunch of Xeon processors.
Do we really think older systems are magically not vulnerable to any of these? It seems more likely that they're vulnerable but old enough that they're getting ignored... and so they'll never get fixes.
Nah. Intel are still selling new systems with SPS 3.0 on them, and those systems are still receiving updates, including security updates (I bought one in March, and it's had two firmware updates since, both with ME changes involved). I can believe that they aren't vulnerable to this one.
I was going to contribute something similar, I recall early dismissals suggesting that the 'low end' machines didn't have this capability. I recall Mike Guimarin's comment of "If transistors are free (and they are) why not cut down the internal SKUs and put this on all processors" which apparently Intel did.
Of course as it becomes clear you can (and should) disable it, if you do that on a corporate laptop you might find that your IT team is both mad and proud of you at the same time. Quite the quandry.
> these are the kind of vulnerabilities that the NSA would salivate over.
Are you really suggesting the IME and AMD's similar component are not the fruit of a collaboration between these market dominating companies and the NSA?
I prefer the wording in Lenovo's security advisory [0]:
> "Potential Impact: An attacker could load and execute arbitrary code outside the visibility of the user, operating system, and hypervisor/virtualization platform; resulting in exfiltration of secrets, subtle manipulation of system operation, or denial of service."
I figured out how to install it using Windows PE. First, get a Windows installer image or WADK and mount it. Microsoft provides these, but hides the download link well. Then get the ME firmware update installer and the AMT/ME software installer from Lenovo and execute the unpackers with wine. From ~/.wine/drive_c/DRIVERS/WIN/AMT, do "cabextract SetupME.exe". You can discard everything but the "HECI_REL" directory from this, including SetupME.exe.
Now you need wimlib to create the WinPE image: "mkwinpeimg --windows-dir=/mnt winpe.img --overlay=$HOME/.wine/drive_c/DRIVERS"
The resulting winpe.img can be dd'ed to a USB thumb drive. Boot into it, and execute "cd /WIN/AMT/HECI_REL/win10", "drvload HECI.inf" (to load the MEI driver) and then "cd /WIN/ME/", "MEUpdate.cmd" to update the ME firmware.
Does 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.
# modprobe mei_me
# modprobe mei_txe
# modprobe mei
# lsmod | grep mei
mei_me 36864 0
mei_txe 20480 0
mei 86016 2 mei_me,mei_txe
# python2 ./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 1.0.0.128
Scan date: 2017-11-23 20:37:48 GMT
*** Host Computer Information ***
Name: mbair
Manufacturer: Apple Inc.
Model: MacBookAir5,2
Processor Name: Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
*** Intel(R) ME Information ***
Engine: Intel(R) Management Engine
Version: 8.0.4.1441
SVN: 0
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is not vulnerable.
"This system is not vulnerable". Meh - one can never be sure with ME running silently in the background...
When the HW dies, I'll most probably go for a Chromebook with Coreboot - and install Debian on it.
I've had it - enough with this idiocy from Intel and AMD ; if they can't see how these "signed black boxes" are harming them, they deserve what's coming (open, and powerful enough architectures - i.MX8, RISC-V, etc).
These most recent vulnerabilities don't require AMT. I don't see any reports of me_cleaner being used on a Mac yet, but I'd assume they are running the same ME firmware as everything else unless there is evidence otherwise.
No, not yet. I went into my local Apple store and brought it up to one of the genius's and they haven't heard anything at all about the exploit from HQ. But, I can confirm that Intel's ME is present in all Apple macs. The physical hardware is completely unchanged according to the Apple genius bar employee.
It's unclear to me whether or not Apple uses Intel firmware for the non AMT portions of ME. I will report back to you when I find out. However, the evidence I've seen so far isn't looking too good, and it definitely looks like the vast majority of macs made in the last 5 years are all vulnerable, many appearing to run outdated Intel firmware to boot -- not good for Apple.
where some people run a python program to check the version of their ME firmware (which works and returns numbers completely consistent with Intel firmware numbering). I wonder if Apple just isn't aware of the hack yet?
I can confirm that on a coworker's MacBook 12,1 running ArchLinux mei-amt-check[0] reports no AMT.
I'd rather have a more thorough ME test than just AMT I could run though, coupled with a statement from Apple that ME is or will be entirely neutered on Macs in the future.
Yet another reason owner-controlled machines like the Talos™ II [0] are so important. Yes, it may cost a bit more up front, but what's the cost again of having your data stolen and then, especially with the older machines here, having to replace all of your hardware to boot?
Plus, purchasing machines like that one not only sends a clear signal that we want backdoor-free computing, but also allows the further development of more libre computing options. Wouldn't you rather have Linux and BSD as first-class citizens on new hardware, instead of always needing to play catch-up from behind?
Q: Why preorders? Why can't I evaluate a production machine right now?
A: Although we have Talos™ II hardware in our labs, IBM has not yet released the POWER9 CPU to the general public. The POWER9 launch is scheduled for Q4 this year; we intend to make Talos™ II available to everyone shortly after POWER9 launch via our pre-order model. This model allows us to manage supply of the Talos™ II systems for Q4 shipment, and we intend to transition to a more standard ordering model once the POWER9 processor has reached general availablility (GA). Orders placed after our pre-order cutoff will not ship until 2018, and you would be missing out on the benefits of early market access to the POWER9 processor, so we strongly recommend that you place your pre-order as quickly as possible!
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.
Right now to remove ME you need to connect an external flash programmer. It seems really unlikely that anything they do with a firmware update will be able to block that at least if someone can get a pre-change image.
Maybe there is a way to reprogram to disable ME without the flash programmer which these fixes may block. If my laptop weren't already ME disabled, I'd probably apply the fixes.
Good question. I'm not aware of any; I say make one.
The question is what the best IRC server would be to use; considerations include reputation and "unpopularity", ie certain overly busy networks may scare some people away.
There's also the possibility of using Discord.
The main issue is encryption; most won't have any opinions on the subject, but more vocal types who may be useful to have on board may insist on specific forms of security in order to participate.
Anyone able to explain why Intel’s severity rating for this is “important” and not “critical”; meaning of the terms per Intel’s own words:
“Critical: A vulnerability, which if exploited, would allow remote execution of malicious code without user action.”
“Important: A vulnerability, which if exploited, would directly impact the confidentiality, integrity or availability of user’s data or processing resources.“
This doesn't allow remote access, just privilege escalation. So you'd already have to have some degree of access to the system to be able to use this vulnerability.
So, will Intel be patching both the vulnerabilities and the kludges people have found to remove ME? Thus making some customers safer while maintaining systemic risk for everyone?
The motherboard manufacturer integrated the chipset into their board. They worked with Intel, or Intel's spec/API directly. They are responsible for your machine's interaction with the CPU.
The same is true of all the devices directly integrated into your motherboard. Broadcom/Intel wireless chipset, Ethernet, audio, etc.
I ask, because I assume this amount of complexity wasn't created because it was cheap, or end-users were crying out for it. There may be other customers -- those with three-letter agency names, who would wish for code to run on the computer you possess (note, I did not say "own", so long as someone else has control).
It's getting too easy to be this paranoid. Besides, it was fun when I sounded crazy. Now it's alarming.
Good times when kernel privilege escalation was the worst you had to fear.
I'm not familiar enough with the Intel ME to tell, but could this possibly be exploited with the arbitrary code execution in the ME being used to set the HAP bit without requiring hardware intervention?
I think you're suggesting extremely interesting but I'm not totally clear on it. So someone[1] has come up with some code to either disable (kill switch) or remove the Intel ME. (Setting the HAP bit is the kill switch.)
Now Intel and its vendors are going to issue a patch for the Intel ME. Are you saying that as a result of applying this patch we might not be able disable or remove the Intel ME? In other words, we'll end up with a slightly more secure Intel ME, but be worse off since we can't exploit any bugs to get rid of it?
If I'm understanding you correctly, this sounds like the iPhone situation: upgrade to a newer iOS and lose the ability to jailbreak.
Hold off on patching this vulnerability so that it can be exploited later in order to disable ME entirely. Their firmware updates could very well close off these existing "known holes", making them impossible to exploit.
If we can take advantage of them to kill the ME entirely, that's even better than Intel releasing this fix.
In my case, their Linux detection tool is less than useless:
$ sudo ./intel_sa00086.py
...
*** Risk Assessment ***
Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
...
Thanks, Intel!
If you have a Lenovo machine, check Lenovo's security advisory [0] to see if it is affected. Intel has the wrong URL in their link.
Edit: FWIW, the (Linux) tool creates a .log (and .xml) file in the current directory that was slightly more helpful:
$ tail -n 4 SA-00086-cluefire-2017-11-20-21-09-36.log
HECI error: No device with MKHI found[2]
Can't find SPS version in the tool output
Status: HECI_NOT_INSTALLED
Tool Stopped
This workstation doesn't have an "HECI" [1], apparently. It does have SPS, but "spsInfoLinux64" throws an error too:
Error 9460: Unknown or unsupported hardware platform
This box has 2 x E5-2620 v4 CPUs so it is reportedly "not affected" but I thought I'd double-check anyways. Oh well, I won't miss out on all the excitement -- I'll still get to have some fun updating my other machines and all of $work's servers in the datacenters. :/
I get the exact same thing, I might be wrong but I don't think that the windows version does anything different. According to the website it seems that the vendor needs to provide software to patch the firmware.
Yep. "Let's put a chip in it" IoT nightmare now applies recursively to chips. Everything is insecure by design.
I am really looking forward for either ARM to displace x64 or even better RISC-V. With ARM you have many more vendors so more chance for options, and RISC-V is the ultimate in openness.
> i.MX6 is modern-ish and is bootable without blobs.
i.MX8 will soon be released in quantity to the public and it is claimed by people who experimented with testing samples of it that it is similarly open as the i.MX6 in this sense.
As a quick note for folks who don't follow embedded SoCs: the NXP i.MX8 [1] is quite high-powered in this niche. It sports eight ARM cores in total: 4X Cortex-A53, 2X Cortex-A72, 2X Cortex-M4F.
As someone who has spent ~four years working on software for a single M4F, that reads like "it's a datacenter on a chip", more or less. It's ... big.
It also has dual-gigabit Ethernet, USB 3.0, USB 2.0, and enough other low/medium-speed serial interfaces to make you go dizzy. :)
At least you might be able to get a chip without a backdoor in hardware. Binary blobs are still a little easier to audit and can in theory be replaced.
ME FW is just a signed binary blob after all... Just running on an x86 core in the PCH, no difference at all compared to Qualcomm SCM/TZ firmware in that regard at least...
No, it is not isolated and it is certainly not disabled. It must run as part of the initial platform boot; whether or not they politely ask it to shut itself down after boot is irrelevant to the core claim being made that the ME is "isolated and disabled" on their platforms.
> ARM could be a affordable alternative to x86 if that works for you.
Even the open source friendly Raspberry Pi relies on proprietary blobs and proprietary firmware, with vast parts of the documentation only being available to system integrators (meaning: not you) under an NDA.
Theirs is a Broadcom chip, but my understanding is that the scenario is pretty much the same for other ARM vendors. If the chip is anything more complicated than your average 8-bit micro-controller, expect it to be running some kind of "system" which is, of course, closed source.
The stuff running on the ARM itself is all open, but the firmware blob runs on a separate CPU with a different instruction set, which has a view of the entire memory map of the device and ultimate control over the device's behavior (sound familiar?).
I may be wrong, but my impression is that a lot of the other ARM boards out there have the ARM chip as the main CPU, and without a management chip watching it. In any case, a board like that, or a Pi with a reverse-engineered firmware blob (currently in development) would be better than the Raspberry Pi as it is now.
It's bad enough Intel have created the ultimate trojan, but their detection tool can't even fix the problem!
The tool rightly points out that my desktop consumer system is vulnerable (from the list, no Intel CPU manufactured in the last 5 years isn't), then suggests I contact the manufacturer for an update. Here is what the tool says my system manufacturer is:
Manufacturer: To Be Filled By O.E.M.
Model: To Be Filled By O.E.M.
I will get right on that and bug "To Be Filled By O.E.M." for an update! It's an ASRock motherboard, by the way. But with this approach they are not going to patch even 5% of personal computers out there..
This isn't uncommon. You're not wrong to expect that, if they did not do their job when configuring these data, they will not do anything to support you postsale. Their lifecycles are so short maybe your product is several generations old now.
Some of the board vendors do a better job, but usually still not as good as "namebrand computers." There is a lot of engineering work that goes into integration. It's not readily visible to endusers/consumers and therefore difficult for us to appreciate it or evaluate it for completeness or accuracy.
I hope that someone does a survey of computer and board vendors' support for this problem. I would like to see who abandons products last.
They still haven't publicly documented and supported the HAP bit.
If Intel actually cared about your security they would document that. It says so right in the security advisory that the external researchers are the reason for the security review, and not due to customer concerns.
How does this affect Apple products? I've looked around for discussion of Intel ME with regards to Apple and the silence out there is deafening. [edit] I guess I also want to know is, does Apple provide Intel firmware patches bundled with their own software update?
I suspect they'll be patching this one, but I don't know if they have updated the ME firmware in the past.
However, Intel's own platform tools (MEInfo and MEManuf running in a UEFI shell) can't even communicate with the ME on my 2015 Macbook Pro, so I would be quite interested to know what exactly they have done differently with regard to configuring the platform.
People have been archiving every version of the ME firmware for each chipset, and it would appear there are some versions that may be specific to Apple hardware. I'm not sure what is different, if anything, but you can see (and download) the particular firmware versions here: https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...
Very interesting! Thanks for the link. I'm curious if Apple has done something to disable it either themselves or via a special deal with Intel. It's also interestingly timed with the announcement of the new iMac apparently having an A10 coprocessor.[0]
The detection tool for Linux is a Python 2 script. It contains ~15 print statements. If you change them to print functions, the script works fine on Python 3.
The Intel dudes could have added "from future import print_function" and made it version-independent.
This time it's only 6th Generation Core processors and up? I thought even the older ones had pretty much the same version of ME installed, which had the previous vulnerability.
So after it is exposed, after 3 generations of products, do they admit it is not a "feature". I can't imagine why they thought this kind of escalation couldn't be cracked by a 3rd party, or how it would bring brand value. This is "clipper" and yes, the hacker can control it. Dangit. Sell-outs.
I'm just waiting for the ransomware that lives on AME, and is burned to the various dies instead of on hard-drives. Isn't that what this open door means?
The question then becomes which of any of these can be exploited by a non administrator local user or remotely via LAN (which might include the local machine depending on handling of loop back). Personally I can already see a bunch of on site upgrades I'm probably going to have to do for small clients.
I almost wish it covered 3rd-5th generation, just to help me push some folks to upgrade.
Remote administration. Installing a new OS remotely, for example. There is legit demand for that. Imagine manually re-imaging 1000 workstations or servers.
That is AMT, which is just one application on the ME. More in general it aims to handle things the system should do independently of the OS, even when powered down.
That _can_ include advanced power management, secure computing stuff, watchdog functions and stuff like that.
Based on the analysis performed by this tool: Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
Does that mean that the Intel ME is disabled, so I don't have to worry about it? I certainly don't want to install anything that might enable the Intel ME if it's already disabled!
What a quandary. This reminds me of all the information I was asked to give to get a detailed credit report. If I didn't give it, they weren't going to give me the report. If I gave it, they would add to my credit file even if they never had it before.
That's what you get if the tool can't identify the ME version. (I get "not vulnerable" if I run the script with sudo -- ME version too old for these vulns, though likely has other, undisclosed vulns -- but without sudo, I get "may be vulnerable", since it can't talk to the kernel driver.)
So while us technonerds wait and see whether our OEMs will bother to push out firmware updates sometime in the next 6 months, remember that 99% of users will go unpatched anyway because grandma never upgrades her BIOS.
Basically you have to trust the compiler because it compiles all code on your system, including itself. Not entirely the same, and I think the Intel trick is more nefarious.
So does this mean 5th gen and below ones are not vulnerable or Intel just couldn't be bothered to review the ME version on those? Unclear from the article.
Does "attacker with local access to the system" mean "physical access to the system"?? Initially I thought it meant "attacker able to run an unprivileged process on the system" but then I see other wording that seems to imply that case, so does "local access" mean physical access? (e.g. connect a USB drive, boot the box off their own media?)
The examples I've heard about are plugging a usb drive in and that's the ballgame. The big one, that I have not heard of, would be accessing the ME and privilege elevation over network.
As I understand it, the ME subsystem is an overseer, and is running even if your main PC is powered off. It has control over the network, unobservable from the downstream CPU/OS. It could therefore receive commands/input from the network and update itself while "off", or transmit data outbound. So unless the system is unplugged from the wall, the ME subsystem could be doing God-knows-what.
It would be a little more interesting if a "virtual USB drive" (similar to a virtual floppy/CD-ROM drive) in remote consoles (BMC/iDRAC/ILO/IPMI/etc.) could be used to exploit it.
I don't see any remote exploits here (other than "attacker with remote admin access..."). Is that correct? Presumably an attacker with remote admin access is already all powerful? Or is the concern that they can backdoor the hardware in an undetectable way, remotely?
A vulnerability where someone can remote control your machine is bad.
A vulnerability where someone can remote control your machine even after you swap out all local storage and install a new OS is another thing entirely.
True but I'd still like the nature of access required to exercise these vulnerabilities clearly defined. e.g. if I have a box that I've maintained strict physical control over, and not allowed admin access to an attacker, does that mean said box can't have been subverted via these vulnerabilities?
I would be curious to know what the attack scenario is exactly? I assume this is local, not remote, but the article is not very specific. Furthermore, has any kind of PoC been published?
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.
The question I think people should be asking is not "what problem was it solving?", but rather "why was it implemented directly into the processors hardware/firmware?"
The NSA has an NSL and threats of jail to anyone at Intel who pushes back against this. Inslaw and Promis was always leading to this, and that's why they killed Danny Casalero.
what i don't get is how would the consumer benefit of having these features? it all looks like a nonsense to me and I'd rather live without it. i think it's time to say goodbye to Intel and opt for another vendor.
I'd be glad to switch to raspberry pie or AMD, but I don't know whether or not those chips have similar crap in them. is the Intel alone with this? do others do it too?
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. The cynic in me thinks that this will change absolutely nothing.
There is a great website called The Bad Thing [1] that has compiled the known information about Intel ME.
I just ran the detection tool on my laptop and I am running a vulnerable version of Intel ME, but I can't even do anything about it until my system manufacturer provides a patch for it. I feel like this is going to be one of those situations that ends up leaving millions of devices unpatched and vulnerable a few years down the road.
[0]: https://www.blackhat.com/eu-17/briefings/schedule/#how-to-ha... [1]: https://www.cs.cmu.edu/~davide/bad_thing.html