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

Wow. A _remotely_ exploitable Intel firmware vulnerability? You don't see one of those every day. My instinctive reaction is that this is ridiculously serious, although I'd need to see the full technical details.

It's worth noting that the reference to "system privileges" being attained likely refers to something much more privileged than we would normally ascribe to "system privileges". Normally, "system privileges" would mean something SYSTEM on Windows or root on Linux. In the event of "system privileges" in the management component, remember that the main CPU is a slave to this thing.

Something Richard Stallman, among others, was sounding alarm bells for years.

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.


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

Exactly, any tool/service/software installed and running on a system is a potential vector of exploitation.

There's a reason you want to keep the amount of softwares installed on a critical system, other than performance.

It was predictable, and I'm certain predicted by many.

These AMTs/MEs/whatever they call them are full-blown computers with non-trivial firmware/software. The question is: do Intel and AMD put all that much effort into making that secure? (That's quite aside from the possibility of intentional backdoors, which one would think would be reasonably secure so that only NSA and friends could use them.) The answer is "almost certainly not enough effort". This sort of device calls for using Coq or similar provably correct software construction -- it is much too critical to do otherwise if you're going to make it impossible to disable these things.

I guess we just have to filter these ports for a while now -- a big hammer for a big problem.

It's also time for customers to insist on these things being off by default.

The equivalent of ring -2 privilege. Below the OS or hypervisor level.

The intel remote control firmware is a rootkit that lives on many many systems for which the full features and capabilities of, along with all vulnerabilities, are kept as trade secrets.

That would actually be Ring -3!

"Traditionally", Ring -1 is the Hypervisor your kernel is running in, -2 is code running in SMM (e.g. BIOS USB legacy support code), and -3 is the firmware on your physical system (chipsets, hard drive firmware, etc).

The main CPU is no longer the "main" CPU. And before you ask, no you can't run your instructions on the real "main" CPU. Whose computer is it now? I went to Linux because of Sierra and things like Windows unavoidable "instrumentation" (whose OS is it?). Now Intel hardware is putting off that "you don't actually control me" vibe :(

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