Google Working To Remove MINIX-Based ME From Intel Platforms (tomshardware.com)
An anonymous reader quotes a report from Tom's Hardware: Intel's Management Engine (ME) technology is built into almost all modern Intel CPUs. At the Embedded Linux Conference, a Google engineer named Ronald Minnich revealed that the ME is actually running its own entire MINIX OS and that Google is working on removing it. Due to MINIX's presence on every Intel system, the barebones Unix-like OS is the most widely deployed operating system in the world. Intel's ME technology is a hardware-level system within Intel CPUs that consists of closed-source firmware running on a dedicated microprocessor. There isn't much public knowledge of the workings of the ME, especially in its current state. It's not even clear where the hardware is physically located anymore.
What's concerning Google is the complexity of the ME. Public interest in the subject piqued earlier this year when a vulnerability was discovered in Intel's Active Management Technology (AMT), but that's just a software that runs on ME--ME is actually an entire OS. Minnich's presentation touched on his team's discovery that the OS in question is a closed version of the open-source MINIX OS. The real focus, though, is what's in it and the consequences. According the Minnich, that list includes web server capabilities, a file system, drivers for disk and USB access, and, possibly, some hardware DRM-related capabilities. It's not known if all this code is explicitly included for current or future ME capabilities, or if it's because Intel simply saw more potential value in keeping rather than removing it.
What's concerning Google is the complexity of the ME. Public interest in the subject piqued earlier this year when a vulnerability was discovered in Intel's Active Management Technology (AMT), but that's just a software that runs on ME--ME is actually an entire OS. Minnich's presentation touched on his team's discovery that the OS in question is a closed version of the open-source MINIX OS. The real focus, though, is what's in it and the consequences. According the Minnich, that list includes web server capabilities, a file system, drivers for disk and USB access, and, possibly, some hardware DRM-related capabilities. It's not known if all this code is explicitly included for current or future ME capabilities, or if it's because Intel simply saw more potential value in keeping rather than removing it.
You are not alone. This is not normal. None of this is normal.
Google Working To Remove MINIX-Based ME From Intel Platforms
... and replacing it with Android. "Just how much juicy monetizable user data could we get that way?"
(I believe I'm joking, but I'm not completely sure...)
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Hrmm, so some of these intel systems would have linux on it, and linux would be on some AMD x86 systems, and intel ME isn't on Qualcomm/ARM chips in mobiles that android (linux) runs on, or any of these IoT devices. I'm willing to wager there are more mobile phones in the world than intel ME enabled PCs at this point.
Tanenbaum gets the last laugh over Torvalds.
It's the year of the Minix desktop!
Google might want to talk to Purism, who claim to have completely disabled Intel's ME in their secure Linux based laptops.
If ever notice that when thigns are powered off they are still using 1-10wats? Or that LED's are still lit or blinking?
This is the case with PC's, Microwaves, Dumb TV, VCR's, your name it.
PC's no longer have an on/off button. It's now a button that asks the CPU to shutdown. Power is not cut removed, and some parts stay powered on. Can't ask the CPU to power on, if there's no power for it to reconize the input.
The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
It seems like just a day ago, there was a Slashdot posting about this, and several highy-rated comments amounting to "naw man, there's no way this could be a problem!"
So with all the verifiable, proven news of backdoors being built-in to software and hardware over the past decade, and all the news of vulnerabilities in software and hardware that compromise systems, people say "nah, not a problem, see, you can turn it off" about this "computer in my computer." Really? It's off?
I'm not seeing reports saying "The Intel ME is off by default in consumer devices, and this is verified by researchers." In fact, I'm seeing the opposite, which says that the Intel ME is always on. Do we have any proof that the "off switch" in BIOS actually makes this feature unexploitable? Because, really, that's what I want: I want this feature to be unexploitable, and the only way I can be sure of that is for it to be disabled, for real, because I don't need this feature.
So yeah, please forgive us all if we are just a BIT skeptical about Intel ME. Forgive us if we're skeptical of spokespersons at Intel saying "There's no problem with this feature."
This may be worth 0.02 or less but I believe the vulnerabilities can be mitigated somewhat by using disk encryption. I store all of my data on virtual encrypted file system with a hardware decryption key. When I am done with the filesystem, I just unmount it and remove the USB thumb drive that acts as the decryption key. Yes, it's a pain in the ass and yes, it really only works on desktops. It is a little impractical to do this on a server. It would be good for Google to find a way to stop this Intel menace.
Due to MINIX's presence on every Intel system, the barebones Unix-like OS is the most widely deployed operating system in the world.
I seriously doubt this claim. Phones have outnumbered PCs for years, for one thing. And Linux is deployed maybe even in more TVs and routers than phones, and numerous other embedded systems, now increasingly including cars. Anybody with decent stats on this?
When all you have is a hammer, every problem starts to look like a thumb.
First, not all Intel systems that are capable of it actually have the management engine software. Second, the Intel PC motherboard probably does not hold the "largest number of systems" title, that might belong to Android phones. And anyway isn't the fact that MINIX with its BSD/MIT style licensing was used for the most user-hostile system in recent time an indictment of that license? You would not see GPL software used for this, for obvious reasons, and people who use GPL should be proud of that.
Bruce Perens.
The remote management tools are off by default, but you still need the chip on to run the power management software on it, or the CPU turns off in 30 minutes.
And as it is a black box, it might be doing several other tasks while doing the power management.
See subject: Stop it's ability to send info. outward via router port filtering ala ports 16992-16995 that Intel AMT/ME uses so filter those ports in a modem/router external to OS/PC. Intel ME/AMT operates from your mobo but has NO CONTROL OF YOUR MODEM/ROUTER!
(This stops it cold talking in/out permanently OR being able to remotely 'patch' it to use other ports by Intel OR malicious actors/malware makers etc.!)
Additionally, once you disable the AMT engine's software interface (ez via software these articles note)? A malware to 'repatch' this = impossible (bios updaters require it in usermode ware, e.g. ASUS).
(I only allow 80, 8080 & 443 in/out here on a SINGLE stand-alone system (no home LAN but TCP/IP connected online in BOTH my modem or router port filters or software firewalls))
HOWEVER - Be CERTAIN your modem/router's internal ware is "solid" as well (turn off things like UPnP etc. & CHECK router/modem HAS NO KNOWN BACKDOOR EXPLOITS (tons do unfortunately)) - get it patched ASAP if it's KNOWN exploited & TONS of routers, ARE https://it.slashdot.org/comments.pl?sid=9995967&cid=53488785/
* GOOD ROUTERS/MODEMS HAVE PORT FILTERING OPTIONS (crappy ones do not)!
APK
P.S.=> Good luck - it's the BEST EASIEST & CHEAPEST DEFENSE using what you already have (hopefully, again as not ALL modems have port filtering but most do & certainly GOOD ONES DO) vs. this threat by stopping it being able to communicate in/out period, from OUTSIDE of the INTEL chipset external to it via a router/firewall hardware... apk
2) It's OFF BY DEFAULT.
We don't believe Intel's claims. After the Edward Snowden revelations, after the way that an exploitable backdoor was hidden in the Dual_EC_DRBG standard, after news that Microsoft works to provide backdoors in its Windows operating system, and after government officials have insisted that backdoors must be provided, we just don't trust Intel. The ME has the potential to be the most perfect backdoor in almost every computer. And if the Intel ME is a backdoor, then most of our computers are vulnerable if anyone (anywhere in the world) learns how to exploit it.
2) If the ME isn't running or is running incorrectly, the platform will not power on. It may be completely unreachable from the network in some implementations, but it is the arbiter of whether the system will turn on or not. It's easier to describe it as 'disabled', but it certainly is running.
we just don't trust Intel.
Fair enough, but why would you trust Google?
It is not in the CPU, but that hardly makes a real difference. I'm not sure why people are getting all pedantic about whether it is in the CPU or in some part that is always paired with the CPU to run. The ME seems to be able to make out-of-band requests to the CPU to do potentially anything (including read memory locations). Sure it may not be able to be super high performance over DMI compared to being on CPU, but it's plenty good enough to be worried about it.
why would you trust Google?
I don't trust Google. But it certainly is interesting news that Google doesn't trust Intel, either.
https://www.eff.org/deeplinks/...
As the ME is a black box, we still have no idea what ports it uses... We know for sure that it does use those ports listed, but can you prove it doesn't use any others?
Lack of evidence does not prove innocence.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It's a UNIX system, I know this!
There's no contradiction, we know for sure it uses *some* ports but do not know what other ports it *might* use. Your notion of blocking the known ports is flawed as it may well communicate via other as yet unknown ports.
See subject: Point me to a valid reputable security community source that shows more ports being used than what I listed.
I don't need to prove that more ports are being used, you need to prove that other ports are *NOT* being used in order to validate your claim that filtering at the network layer is effective.
Monitoring in/out communique from router logs external to the PC would tell fact of what ports it used easily beyond Intel's docs.
Monitoring the network traffic only shows the communication that actually takes place, not the communication that *could* take place. We don't know if any circumstances exist in which it could attempt other forms of communication. Sure the network router could log this traffic were it to take place, but we cannot be sure of all the triggers which would make it do so. That also assumes that the device only has wired connectivity, which is connected directly to your networking equipment. If the device has any form of wireless connectivity it could attempt communication with anything that's within range.
Unless we are 100% sure of all the possible network communication the device could perform, and what could potentially trigger it, a blacklist approach at the network gateway can never be truly effective.
We don't know, and a lack of knowledge is dangerous.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
For chromebooks where google can't use their own openbios-based stack,
they use heavily modified firmware, where the ME part running on the micro-controller embed in the chipset is reduced to the base minimum necessary to get the chipset running.
Among other, all the juicy bits that are targeted by ME-exploits (half-broken webserver serving as the user-interface, capability to reflash the UEFI/BIOS while the main Intel CPU isn't even powered, VNC-like server with USB-over-network extensions, etc.) are all removed.
(Common, these are *chromebooks*, why to they need tools for Admins doing "lights-out" maintenance ?!?)
In a similar way, the parts of UEFI that run at "negative rings" on the main Intel CPU have also been reduced or removed.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I agree. Supposedly it's built into every Intel chipset, which means they spent money reserving the silicon and firmware real estate to have it there.
Its existence is default, even in low-end chipsets aimed at the consumer market, but 99.99% of the time it's disabled and simply a total waste of money and resources. Honest!
I don't buy it.
The trustworthyness of Intel or Google is not important. The current Intel firmware code is complex, compiled blobs that are closed-source and unknown. The Google solution is much simpler, open-source GO that can be compiled on the fly. The creator of the replacement code can be untrustworthy, provided that code can be audited.
And... why are Intel unwilling to sell a CPU without the ME, when a client like Google - who build 1 million+ machines running their CPUs - don't want it?