Hacker News new | past | comments | ask | show | jobs | submit login

And yet here we are, unable to properly deactivate "features" such as Intel ME.



... Here we are, with an exploit that only affects people that enabled a remote management feature. If Intel had made this an optional addon that required a physical switch to enable, approximately the same number of people would be affected today, since it requires provisioning. It's not like every Intel system is silently waiting for an exploit payload.


Pretty much every large company running Intel hardware on professional desktops will have AMT on. It's pretty much SOP unless you really like site visits.

That's a lot of computers worldwide.


... And those companies would turn on the feature or get an equivalent third party system with the same attack surface. This doesn't seem to affect anyone that is against AMT.


You can't really easily opt-out of ME, which is the real problem. The fact that AMT has sprung a leak was only a matter of time but I'd rather not have the whole ME business.


Is there any reason KVM/IP is not a viable solution for remote management?

Remote access to DMA capability is just batshit insanity.


This works even absent an OS. In fact, that's the whole idea.


I read about this a while ago. Apparently Intel's Management Technology which is built into like every Intel CPU now listens directly on the network interface so it can still send/receive data in case the OS is borked. It hooks in at ring 0. Like a rootkit the OS can't see.


It's common in the datacenter to come across motherboards with a switched eth0, with the BMC behind one leg and the user system behind another. You don't have to get that creative to get IPMI out of a machine when the OS is hosed -- to be honest, I think that is what you're actually thinking of, because "hook[ing] in on ring 0" is difficult to imagine working. You'd need driver awareness for when the management plane wants to transmit, at the least.


It's not just Intel that does it. HP Storage solutions use iLO which is pretty much the same thing for SANs.


Not just SANs, pretty much their entire product line. iLO is a very common IPMI deployment at companies with HPe gear, which is a number of very large ones.


> This works even absent an OS. In fact, that's the whole idea.

It's still an OS, it's just not on the hard drive.

The real issue is that we don't have the source code for it and only the OEM can patch security vulnerabilities -- or not.


[flagged]


It's pretty much standard at large companies to never bother running the installer on the machine (if it even has one and isn't procured without an OS) they bought but instead to use a provisioning tool to re-image the machine before it first gets booted. Think of it as a DRAC card with some fancy tricks in a regular desktop (or laptop) and without occupying much space or a slot.


AMT includes KVM/IP.


> only affects people that enabled a remote management feature.

The AMT can't be completely disabled, so people might not have to explicitly enable it to be vulnerable to AMT exploits.

> It's not like every Intel system is silently waiting for an exploit payload.

It's not like it's Intel makes it easy to navigate their CPU and motherboards feature set. Manufacturers are also known to do a bad job on their BIOS/EFI. And given that the computers most likely to be vulnerable are those most likely to be used by businesses and professionals, the damage potential is pretty staggering. But yeah, netbooks are probably safe.


It looks like this also affects systems where the feature is not enabled, but for "local" attackers. Does that mean exec as "www-data" or "nobody" accounts (what about VMs?). Making every little wordpress plugin vulnerability into a CPU-rooting hack?


From what we can see so far, potentially more the latter than the former.


Hey Michael, that's pretty amazing you have audited an encrypted and closed source binary from Intel to discover each Intel chip doesn't listen for an exploit payload. Would you mind sharing the keys you used to decrypt the firmware or the techniques you used to dissemble the binary back to the source code?


Don't cry man, at least I feel quite confident that these backdoors are efficiently NOBUS




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: