Money quote, though this may be slightly old news and this is just a summary of known information:
One of the most common questions regards
the possibility of remote exploitation.
We think that remote exploitation is possible
if the following conditions are true:
1. The target platform has AMT activated.
2. The attacker knows the AMT administrator
password or can use a vulnerability to
bypass authorization.
3. The BIOS is not password-protected (or
the attacker knows the password).
4. The BIOS can be configured to open up
write access to the ME region.
If all these conditions are met, there is no
reason why an attacker would not be able to
obtain access to the ME region remotely.
Also note that during startup, the ROM does
not check the version of firmware, leaving the
possibility that an attacker targeting an
up-to-date system could maliciously downgrade
ME to a vulnerable version.
That list of conditions does not seem incredibly unusual to me. Consumer hardware should have AMT disabled and be safe, but on business machines the highest bar is an AMT vuln, and given the huge size and apparently terrible code quality of the AMT I expect to be seeing auth bypasses for it on a regular basis.
Could you elaborate on why you think its apparent that AMT has 'terrible code quality'? Specifically, versus other high profile products that continue to have multiple security bugs being introduced every release cycle - Windows, iOS, Android, Linux, etc.
I can give you an example of why I think the code quality is questionable:
At my work we use AMT for legitimate purposes: remote administration and support (we have offices in different cities). A big problem for us is that the AMT crashes by itself and the computer needs to be power-cycled for the AMT to work again. Sometimes the web-interface don't answer, sometimes the passwords doesn't match anymore. I think there is a process that is writing where it shouldn't, because it works again after the computer is power-cycled by removing the power-cord.
I now have a script that checks every registered computer twice a day , to see if it is still possible to login to the AMT, and if not, it sends an email to a person at the local office requesting them to restart the computers that fails.
When it works it is a great tool, allowing us to fix computers and give support without the need to travel to each city.
It's sad hearing that it hasn't changed much in over a decade — back when I was primarily doing sysadmin work, of the various manufacturers, only Sun's ILOM (on the V20z/V40z Opteron servers) seemed to reflect the existence of a QA department.
IBM, Dell, HP, etc. all had problems like you described where the management processor would hang after receiving unexpected traffic (e.g. nmap scans), too many simultaneous logins, etc. and, naturally, nobody had thought to implement a watchdog timer to reboot if it became unresponsive even if they had the same functionality available for the actual server.
Thanks for that ! I'm looking to implement AMT (or something like it) at our office. I'm a developer but as the defacto sysadmin I was looking into how stable the AMT platform is. I occaisionally have to re-image machines, and I figured I could just ask people to plug it into a network jack and let me remotely take care of it.
That's really pathetic that a "consumer ready" embedded piece of software whose whole job is remote-management... needs to be remotely managed because it crashes all the time.
It has a classic C buffer overflow - there's a read where the amount read can exceed the buffer size. This is a consequence of C's biggest design flaw - the language doesn't know the size of arrays. That's the root cause of most buffer overflow vulnerabilities.
It also means that Intel didn't do much code review. There are automated tools which recognize that specific class of bug.
I'd wager that only a minority of projects use linters, static analysers, etc in continuous integration. I'd also wager that only a minority treat warnings as errors.
This is true but experience shows us that optional safe practices don't seem to be enough. A safe by default language looks like it makes the most sense in practice.
Every description I've heard of it has language like this:
AMT is a large module with a huge number of
different network protocols of various levels
integrated into it. This module contains a great
deal of legacy code but can only be found in
business systems.
In absolute terms it's probably not as bad as a desktop operating system, which is laboring under sisyphean compatibility constraints on top of huge attention from researchers and a nearly totally intractable threat model. Relatively speaking, though, those same things must be taken into account - their attack surfaces are thousands of times bigger and they attract thousands of times more attention. Seeing about as many critical vulns in the AMT as in, say, the entire Linux kernel... yeah, I'd call that "awful code quality".
Plus there's the fact that the original vulnerability was literally "you can get in by sending an empty password". A culture that lets a bug like that through cannot be conducive to good code.
>Seeing about as many critical vulns in the AMT as in, say, the entire Linux kernel... yeah, I'd call that "awful code quality".
But that is not the case. Linux has had 400+ security bugs this year (as you point out, in part due to its greater attack surface) versus the 2 from AMT. I'm trying to reconcile this idea that "ME = BAD" in a practical way by comparing it to software that's in mass use and already being exploited. The tech press over time has needlessly over-hyped such security issues making it harder to put things in perspective. So far, I'm not seeing anything special about ME that would also not apply to many many other products.
>Plus there's the fact that the original vulnerability was literally "you can get in by sending an empty password". A culture that lets a bug like that through cannot be conducive to good code.
I don't see the tech press not recommended OSX anymore !
Filter Linux's list to "scores > 8" to take the sampling bias into account - the only way to observe an AMT vulnerability in the first place is to gain remote super-root on a widely-deployed core system that may be a PITA to patch. That takes linux down to 27 for 2017. Of those, only about ten are for the kernel itself rather than for binary drivers for nvidia, broadcom, qualcomm, or htc hardware. About half of the total are marked "android"; given that my understanding is that the android kernel has significant changes I wouldn't be surprised if those are android-only exploits. The intersection leaves a grand total of 6 vulnerabilities that are in the actual linux kernel and comparable in severity to the two AMT compromises we've seen.
> I don't see the tech press not recommended OSX anymore !
I certainly don't rec apple. Never have, though previously for non-security reasons, and unless they do a lot of changing, never will.
Sure but as a user of Linux, I don't particularly care why the bugs are present in Linux. My view is if you ship it, you should own it. Assigning blame to Nvidia or whoever can go both ways. They might point the blame back at the interfaces inside Linux for being unclear or less than adequately documented, or whatever. Or they might blame some other aspect. Nobody knows unless you're the person who actually wrote the code or has intimate knowledge specific to the bug. In any case, my point wasn't to compare Linux vs AMT. I'm considering deploying ME/AMT to manage systems inside our office. After all this news having come out, I'm waiting till the dust settles. I have to unfortunately wade through a lot of hype to get to the meat of the issue. So far I haven't seen anything that would dissuade me from deploying ME internally.
The problem is the location of the vulnerablities: on the CPU itself.
Get pwned in linux? Nuke and pave can usually solve it. The exceptions being BIOSes and hdds/usbs with vulnerable firmwares which can be exploited to restore the malware. However in that case an actor has to target your hardware combination specifically, and there are a plethora of different hdd/usb manufacturers.
Get pwned in ME? No longer your hardware. On top of that it applies to all Intel CPUs, and potentially remotely to Intel AMT CPUs.
Sure, but I see no reason not to be able to just re-flash the ME firmware in that case. I guess as an embedded developer, maybe I'm just seeing things from a different POV than most people here.
Well, the easy way to flash the firmware goes through the ME, so that's about as good at removing infected ME firmware as Windows Update is at removing viruses. The other way... I mean, you could simultaneously bring down every computer your company and its employees own, airgap them all, open the cases, expose the SPI headers, flash the firmware, bring them all back online, and hope you don't have to do it again tomorrow because someone didn't get the memo and was working from home that day. And that nobody did anything Bad while they owned your entire corp net. You could do that. I wish you the best of luck.
I dont understand. Why is reinstalling an OS a solution to a rooted OS but re-flashing ME/AMT isn't? You patch the OS bug that lead to it being exploited, and you patch the ME bug that lead to it being expoloited. I'm assuming a scenario where Intel (and/or BIOS/UEFI/MB vendors) behaves like a sane OS vendor and releases regular updates/fixes. Anyway, we're really geting far off topic. I guess I'm replying too :)
Anyway, we're really geting far off topic. I guess I'm replying too :)
Heh, I'm here to have interesting conversation, not necessarily on-topic conversation. :P
Why is reinstalling an OS a solution to a rooted OS
but re-flashing ME/AMT isn't?
The issue is that it looks to me like there's no equivalent to "reinstalling the OS", since the non-SPI route for flashing the ME is an ME function. That's why I used windows update as an example - flashing new ME code is less "boot from install media and reinstall" and more "sudo dpkg -i new-kernel.deb" or "run windows update". And if the ME is compromised - dpkg/winup in this analogy - it could easily propagate itself to the new firmware. Since at least some of the vulnerabilities are in bootloader code that's stored in ROM, it may be flat-out impossible to prevent the ME from compromising the new image if it's running while you're flashing - IOW, time to crack the case and find the SPI headers.
Also, really, reinstalling the OS is a solution to a rooted OS only almost all of the time - a truly determined infection can lodge endospores in places like GPUs and hard drive controllers. They just don't do that kind of thing because the spectacular range of PC hardware makes that capability cost-ineffective. If they can find something like that for the ME, or if they don't even have to because they control the only way to update firmware and it's the same on every intel system, that's a much higher-value target.
Yeah, this is the kind of info I'm trying to figure out. The ME update mechanism seems to not be so cut and dry. The three regions RGN/EXTR/UPD can be updated seperately. It seems like ME updates could be delievered either as a full OEM bios update, or a by an Intel supplied UPD-only update. Also, The update seems to be a simple direct flash via the SPI controller. Not sure if any running ME processes can interfere with that. Happy to go through any links you have..
Now that I think about it, I'm not sure that the exact route matters. The ME can read and write its own firmware storage; that's a necessary capability for writing new firmware with the MEI. So if a compromised ME gets a chance to execute code after new firmware has been flashed, it can read out that new firmware and reinfect it. And that means that even direct flash via SPI won't work unless you can take the ME offline, flash the firmware, and then restart the motherboard without ever giving the compromised firmware a chance to do anything. Which I'm not sure is... entirely possible? I can see setups where it's impossible to be able to get access to firmware storage with the ME offline. This is getting way into the details of how these motherboards are wired up.
> So if a compromised ME gets a chance to execute code after new firmware has been flashed, it can read out that new firmware and reinfect it.
Yeah, or it could just fake the flash operation. Much easier than re-infecting a potentially unknown firmware. Lots of oppurtinities here.
>And that means that even direct flash via SPI won't work unless you can take the ME offline, flash the firmware, and then restart the motherboard without ever giving the compromised firmware a chance to do anything. Which I'm not sure is... entirely possible
It looks like the ME processor can execute instructions from the firmware/spi region, its own memory, or from a reserved region in RAM. During the SPI flash, if the ME CPU is not offline, then it has the potential to accidentaly execute instructions out of the firmware region being flashed to and cause havoc. This may necessiciate that the ME MCU enter some kind of idle state during flashing, and then be rebooted. Although, as an aside, maybe the flashing works by copying to an unused region and then fliping a 'new firmware at location X' bit and rebooting the ME CPU which will then do the actual flashing. I haven't found any details yet, but I haven't looked that hard either.
You can normalize against anything. Can we normalize Linux against the fact that millions of people potentially could have reviewed the source code, and prevented the bugs? You can bias things with proper justification any which way. At some point, we just have to accept an imperfect method :)
> Specifically, versus other high profile products that continue to have multiple security bugs being introduced every release cycle - Windows, iOS, Android, Linux, etc.
This is not the correct comparison. AMT has terrible code quality compared to the gateware/microcode of your average x86_64 CPU.
That ME/AMT is as insecure as some consumer OSes is no excuse, especially given it's certainly quite possible to install an OS on your x86 machine that is far more secure than your average consumer OS (or than the code AMT runs, which apparently falls to 1990s-vintage buffer overflows).
I think comparing the code quality of the AMT to that of another OS is a fair comparison, given that the current-gen AMT is running a modified version of MINIX[1].
I would presume that in large corporations where AMT isn't actively used for configuration management, corporate IT will almost always have disabled AMT in the BIOS. Am I wrong about this?
Some IT shops aren't very on top of BIOS configs. They should be, but just because they should be doesn't mean it matches reality. It doesn't occur to everyone to go into BIOS for any reason other than boot problems, let alone to audit for reducing attack surface area. I can see that falling through the cracks in policy and practice.
IME and based on what I've read, it's usually not possible to disable AMT; that option is not always present. However, I don't have great data to base that on; do others have a different experience.
In the meantime, a high level of technical proficiency is needed to defend against monolithic personal computing environments that are hostile by design.
* Assume personal computing environment is hostile
* Use an external firewall and have a whitelist-only policy
* Use an external NIDS
* Physically disable all hard-connected non-wired interconnectivity
Monitors and keyboards ("I leave message here on service but you do not call") still leak, of course, but this is a good start, and most people need to be concerned with practical attacks that could be carried out over the internet.
New Year's 2018 resolutions: 1) Review backup policy including backup testing procedures 2) Implement personal digital security measures
I've often thought that the current mentality of a "convenient" monolithic personal computing environment (whether an iPhone, laptop, or PC) doesn't properly assess threats.
When broadband internet first became popular in my area growing up, it was acceptable practice (and recommended by ISP's) to simply plug your non-firewall'ed DSL modem ethernet directly into your computer. It truly was unprotected sex in the worst possible way. Perhaps the next evolution will fundamentally reconsider personal computing design from a security-first perspective.
Your reasoning has merit, of course. And, that's a sad commentary on the current state of affairs, in which one cannot trust a firewall appliance to do its job.
Perhaps the movement for open source hardware should focus on minimal security appliances.
Note that this document is dated 2017-12-05, so it's not anything new to those who have seen the previous items about ME on HN.
According to page 12, one of the conditions for remotely exploiting this is that AMT has to be activated, something which probably isn't going to be true for PCs used at home and not part of a corporate network.
Such a vulnerability has the potential to jeopardize a
number of technologies, including Intel Protected Audio Video Path (PAVP),
Why aren't companies pressuring Intel to remove or disable the ME? It seems like a huge security risk for entire organizations. It's especially difficult to fix when running Linux, and many organizations/servers use Linux.
I ask myself that question every time I read something about ME.
Possible answers, in ascending order of paranoia, are:
* A lot of people just don't care. "It's not gonna happen to me"
* Some customers like the remote management capabilities without having to spend money on licenses for vendor-specific remote management systems such as HP iLO. If you have to manage hundreds or thousands of machines, it can make your life a lot easier.
* The NSA tells Intel (and AMD) to put it in there or else.
I assume some customers talk to Intel about this. I vaguely recall reading that the NSA gets servers with ME disabled. So "They" are most certainly aware of the risks.
FWIW, a while ago someone posted a video of a talk on HN given by a Google employee who talked about replacing stuff like UEFI firmware in their servers with their own code. If that person keeps going down that road, it's just a matter of time before he runs into the Management Engine.
I really hope that this issue generates enough pressure on Intel/AMD to provide a way to disable or replace their proprietary ultra-privileged code. But it is not easy to explain this to people without sounding like a paranoiac.
>The NSA tells Intel (and AMD) to put it in there or else.
Exactly. And this is where mass surveillance comes in to play: having dirt on anyone and being able to use it as leverage.
ie. Intel is forced to put it in there or the NSA will 'leak' how they <insert illegal business practice Intel engaged in that will put them out of business if published.>
There were investigating flashing the ME for their compute cloud processors [0] to avoid the possibility of an ME vulnerability being exploited, which would greatly harm their reputation.
Intel ME is frequently featured here on HN, but the general population is completely clueless.
This is quite possibly the worst and most widespread computing vulnerability that has ever existed, and it's likely that Intel will just maintain the status quo until there's some sort of black swan event.
Worst vulnerability ever? AMT has to be enabled, attacker has to know AMT password, BIOS password and BIOS has to be misconfigured. I understand clickbait hyperbole and appeal to emotions are good for getting eyeballs but lets keep some perspective. Remember heartbleed, conflicker or blaster?
But not vulnerable. This is like saying a local root exploit is the Worst Vulnerability Ever in a system that was correctly firewalled from its earliest implementations.
"Worst" implies harm, not just potential. It doesn't get to be The Worst until something happens, no matter how much it offends your personal design sensibilities or confirms your conspiracy priors.
Sorry, but "running but not vulnerable" is not nearly good enough nowadays. This means that a real exploit (e.g., via yet another insert-your-favorite-spooky-agency tool leak) can be quickly scaled to a large fraction of computers worldwide.
If you are saying that when assessing the vulnerabilities, potential harm is not important, only actual is, would you feel that putting remotely activated bombs on all planes is not a major vulnerability as long as no one has a password?
You're talking past me. It's an important flaw. It should be fixed where possible. It should be mitigated where not possible.
It's not remotely The Worst Vulnerability Ever and any attempt to hyperbolize in that direction is hurting the efforts of the people actually trying to protect you.
I think you're right it's not remotely The Worst Vulnerability Ever. Personally I'm a bit worried that we're just one exploit away from it being that in the future though. :/
I usually like to include a metaphor to explain the equivalence as I see it, but I'm struggling to come up with any other thing where we've built in a problem like this that's waiting for a single event that could effect nearly everyone. The closest I can come up with is Snow Crash, and having to reach that far into science fiction leads me to think we likely have a poor grasp on how to assess this risk (since we as a species are fairly bad at assessing and mitigating risk for events we haven't encountered before). Hopefully it's just an extreme failure of imagination on my part.
The backdoor code that a user, who bought the hardware, cannot shut down is a major flaw. It is, IMO, far from The Worst Vulnerability Ever, but it is a flaw that the manufacturer is not inclined to address; in fact, it is seeing this as a feature.
Thus advocacy, including overstating its impact, is likely the only option for those who want it changed.
> any attempt to hyperbolize in that direction is hurting the efforts of the people actually trying to protect you
Can you clarify this -- who are those trying to protect us and why do they want this mis-feature to stay? Are you talking about spooks who use this as a backdoor in their own cyber attacks? If so, this IMO only adds urgency to the need to close this backdoor -- such tools often leak and backfire.
>Sorry, but "running but not vulnerable" is not nearly good enough nowadays.
What does that mean practically? What you said applies to every networked device and tech. All routers, all computers, all OSs, all voip phones, etc, etc are 'one vulnerability away'. from total compromise.
Mitigation does not necessarily mean to entirely protect. Having less of a homogeneous ecosystem mitigates the risk of any one vulnerability, as it's unlikely to affect as many systems. It's not a solution, but it may help.
1. You have no idea if it's vulnerable or not. For starters, you don't have the source code and nobody you trust has seen it. You would have to take Intel's word that "disabling" it actually works, and hope that there is no other vulnerability Intel doesn't know about.
2. It doesn't have to be "vulnerable" to be used in an attack; it's essentially designed to be an attack. So any government agency or leaked Intel info may be sufficient to abuse.
3. You can't reliably check/audit if it is being exploited or not since it runs at a higher privilege than any diagnostics you might try to run on your own computer.
Disclaimer: I am not an expert in computer security.
"This is quite possibly the worst and most widespread computing vulnerability that has ever existed."
The problem is to make that true, you have to carefully phrase the situation as "this has the potential to give rise to the worst, bad .... etc".
And that's the thing. Ignoring this ranks along attitudes like "that cement pool of mining tails right above town is quite sturdy", "we just need a little time to reduce our carbon emissions..." and "we shouldn't kill the IoT with too much regulation..." etc
If X isn't a problem right now!, then it seems like X is going to get about zero attention from a world swimming in things that are a problem right now.
And that too is going to give rise to further problems down the road, to say the least.
If we're unlucky, the 'black swan event' will be something along the likes of Pluto's Kiss. Imagine a Morris worm equivalent, but which bricks the computers it infects after destroying the filesystem.
Even if everyone has backups of everything, offline, it'll be years before all the destroyed computers can actually be replaced. This isn't a scenario I want to happen for real.
"BIOS PSP Support disabled" is the only statement we have, in the form of a new option in the BIOS Setup.
That sounds like the equivalent of "HECI Disabled" for Intel BIOSes, which has been around for years.
It doesn't do anything to shut down the hidden CPU (PSP). It just sends a command to disable the bridge over to the main CPU. All the other ways of talking to the PSP remain open.
I also hate Intel and AMD for that, but I think they'd prefer we didn't hate them. I conclude that there are big reasons to still do what we hate them for. I'm afraid even a black swan event wouldn't make those reasons go away.
What I think needs to happen is for other countries to realize this issue is a matter of national security, and to fund development of alternatives.
Well, I will not buy an Intel CPU anymore. I also try to avoid Intel in all other chip classes like networking chips where Intel is suspiciously active. Sometimes I wonder if their name is giveaway that people just don't realize. Soon I intend to move to an Intel-free single board computer for my day-to-day computer usage. Now, for other people I can't speak.
What can an ordinary person do? Plugging out the network cable? What about laptops? Can this vulnerability hack into Wi-Fi and allow itself to the internet? But then again the moment you plug internet back in you're done.
Use non-x86 platforms such as an ARM based Chromebook, or potentially an x86 with the ME partially disabled (coreboot or similar, but it's not a 100% guarantee).
> Plugging out the network cable?
It depends on the vulnerability scope. If it's over HECI (virtual PCI device between host OS and ME) then removing the network cable won't save you from local malware owning the ME via HECI.
> But then again the moment you plug internet back in you're done.
Well considering how few people ever update the firmware of their devices, it's unlikely a majority of computers would ever be patched against an ME vulnerability anyway.
Starting with ME12 Intel is going to start checking the ME firmware version number in the ME's silicon (read-only) boot ROM to prevent firmware downgrade attacks. [1] This version number is stored in single use eFuses which can only be incremented, and are during an ME update.
But it depends on your threat model. As stated in the PDF, there are only 3 known exploits against the ME, and only one results in unsigned code execution. Until someone weaponizes such an exploit, which at the moment it seems physical access is needed, then Intel x86 owners are safe.
If your adversary is a three letter agency or nation state attacker, then you've got bigger concerns than someone hacking your ME (starting with, say, your OS).
> Use non-x86 platforms such as an ARM based Chromebook
Careful there. Microsoft has been slipping PC bits into their Windows Arm systems because Windows is so hopelessly tied to the PC platform that they had to PCify their Arm with EFI, ACPI and other PC legacy junk. Just be sure your Arm does not have any of this anti-consumer crap and you should be good to go.
I removed Intel ME from my Thinkpad x230 last weekend. I highly recommend this machine. Still quite powerful, very serviceable, upgradeable, Linux friendly and cheap (you can get one in good condition for ~$150 USD in USA).
EDIT: You can also get a laptop with Intel ME disabled. As far as I know you can get a modern laptop without ME from System76, Purism. For a while Dell offered such machines, but that might no longer be the case.
An ordinary person can buy a PC with it disabled. Dell has started offering to disable the management engine for $30. Choose "Intel vPro - ME Inoperable, Custom Order" when ordering.
I think people are mostly worried about the persistent, highly privileged processes that it starts (especially the remote-access features when they don't need them).
The initialization stuff (in the BUP module) are necessary and AFAIK, nobody is suggesting that be removed.
The me-cleaner is getting more and more bugfixes over time. For the average person simply sanitizing a firmware image to disable the ME will be enough. The question is more at what point are you confident you won't brick the system doing it.
I have not done any research recently in the success rate of ME cleaner, but it isn't that low, it usually works to the best of my knowledge, and once we have good documented statistics saying "this works most of the time" it becomes more feasible for those not directly involved in its development to start using it more proactively to get rid of this vulnerability.
The irony is that AFAIK the ME cleaner itself depends on exploiting some vulnerability in ME in order to disable it... so it may get more difficult in the long term.
The good news on that front is most board manufacturers abandon updates after a year or two. My ASUS mobo right now was released in 2013 and saw its last firmware update in late 2014. With the exception of the most modern boards, you can generally assume there will be no more updates for your hardware after a year or so.
