Hacker News Reader

Comment by bjt2n3904 | Hacker News Reader

The tools they listed are windows executables.

Am I vulnerable to this on a Linux System? If so, any way to assess vulnerability, and patch things?

Yes. This affects the management engine, an independent firmware that runs in your system wether it runs linux, windows BSD. It is still running even if your computer is off (in fact, one of its capabilities is to turn it on remotely).

Edit to add: independent of what Intel might say about this (given it seems it has taken 5 years to disclose this and 5 major firmware versions I won't trust too much what they say about consumer pcs not being affected). Check if your cpu and motherboard support AMT and if it is enabled. All workstations I've worked with have it, but there are a lot of machines that have it disabled by default unless you specifically turn it on. So, you might be affected if you have a "supported" processor and (I guess) an Intel NIC onboard and wired, and remote capabilities enabled.

What if I disable AMT in the BIOS setting? Does that make these Windows programs irrelevant?

I'm mostly interested in if servers with ipmi (supermicro in particular) are vulnerable, and to what degree. If it's the network with the ipmi ports, that's one thing, but if it's public facing...

Much stuff is going to be hitting fans.

IIUC the SuperMicro BMC is different software on a separate third-party chip. So it's reasonably likely to be vulnerable, but not to this particular vulnerability.

Your IPMI should be on a private management network, at least. If you haven't done that, I hope you at least changed the default password.

Yeah, that's pretty easy on this generation. But there was a previous generation where the IPMI piggybacked on one of the main NICs, where it was a lot easier to accidentally expose that to unfriendly traffic.

It's not entirely clear if this'll be exploitable except in the rather rare scenario where someone has actually set up AMT.

AMT seems to depend on vPro, which is not present on most "desktop" cpus. There is a more technical security advisory here : https://security-center.intel.com/advisory.aspx?intelid=INTE...

Are you sure? Both my ThinkPad (personal) and my MBP (work) appear to be affected; they report CPU models that, when I look that model up in Ark, Intel says has the vPro technology.

It seems that for network management vPro needs a compatible CPU, motherboard chipset, and a Intel ethernet controller. So in theory Macs are safe from remote exploitation?

What will really be interesting to see is if this is exploitable via PCIe for local privilege escalation on consumer processors with vPro.

> It seems that for network management vPro needs a compatible CPU, motherboard chipset, and a Intel ethernet controller. So in theory Macs are safe from remote exploitation?

If that's the case, that sounds to me like there is special code in the Intel NIC firmware to allow/forward/do things with these packets?

Definitely, and this is not a conspiracy.

The ME is used for the WoL and EEE features of the Intel NICs.

(EEE is Intel's energy efficient ethernet, allowing it to keep TCP sockets open even if the main processor is asleep).

Additionally, the ME builds its own network connections.

It's also why I stopped using any and all Intel NICs, they ended up resetting every few seconds if the ME was partially disabled.

I think we need to remove the word 'conspiracy' from the English language, it's been abused too well by propaganda.

I thought I might be safe with an APU-2 device as a firewall (AMD chip, don't know if they have the same arrangement with the five-eyes), but Intel NICs.

Guess the motto is, use paper and lead pencils for anything really important. And turn wifi off.

These scumbags are actively ruining computing. Cars, bridges, infrastructure... can't these warhawks pick on something else?

Then you get the NSA, the ASD, the rest of the clowns coming in and ruining it, and what is the point? Are we all just fighting each other in an ape war?

I thought we were better.

This is a path to DMA, but you can already get DMA from PCIe.

The list of Intel CPU's with vPro:

https://ark.intel.com/Search/FeatureFilter?productType=proce...

AMT is a part of the vPro management suite. All 3500 of our desktops had AMT at the school I worked at. They did not, however, have vPro. Having it was as simple as paying extra per machine. I would guess that it's in all of their CPUs, just disabled at different levels depending on the OEM and the system you order. Typically, you will not find this enabled on consumer desktops / laptops, but a lot of the business ones at least come with AMT, even if vPro does not.

First, check your CPU for vPro: https://ark.intel.com/Search/FeatureFilter?productType=proce...

Then look for the MEI controller: # lspci | grep "MEI"

I have a CPU without vPro, but a chipset that supports MEI.

But then, I bought the best CPU available without vPro.

The Linux kernel modules are mei_me and mei. To check: modprobe -nr mei_me mei #dry run modprobe -r mei_me mei #to unload the module This will not persist across reboots.

There is also a lms package.

I don't know whether any of this is required for a remote exploit, or if it's only needed for local escallation.

Thanks.

Both "# modprobe -nr mei" and "# modprobe -nr mei_me" report that the module isn't found.

From my understanding, this exploit can work regardless of the operating system. I mean, if this Intel hardware can get network packets without the operating system being aware, then not having those modules loaded won't help.

Correct. This is only to close the local exploit route.

Right. And in my case, also no vPro on the CPU.

>Am I vulnerable to this on a Linux System?

Probably, but there's not much info out yet so it's rather difficult to comment on exploitability.

Doesn't intel provide firmware that can be downloaded from kernel.org? If this is included in that you can A) wait for it to be available there and recompile your kernel or B) wait for your distro maintainer to update your kernel.

If you load firmware from userspace you can probably just put it in the directory the firmware helper searches.

You're possibly thinking of microcode for the x86 CPU.

This vulnerability is in code running on an entirely different processor that resides in the PCH on the motherboard and is initialized from the flash ROM on the motherboard long before any OS boots on the x86 CPU.

Reply on news.ycombinator.com