5 ms·
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?
by bjt2n3904 10y ago
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?
- biktor_gj 10y agoYes. 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.
- ryanlol 10y agoIt's not entirely clear if this'll be exploitable except in the rather rare scenario where someone has actually set up AMT.
- wiredfool 10y agoI'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.
- amluto 10y agoIIUC 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.
- ams6110 10y agoYour 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.
- wiredfool 10y agoYeah, 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.
- abecedarius 10y agoWhat if I disable AMT in the BIOS setting? Does that make these Windows programs irrelevant?
- ryanlol 10y ago>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.
- Zarathust 10y agoAMT 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=INTEL-SA-00075&languageid=en-fr https://security-center.intel.com/advisory.aspx?intelid=INTE...
- deathanatos 10y agoAre 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.
- erik 10y agoIt 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.
- DKnoll 10y agoThis is a path to DMA, but you can already get DMA from PCIe.
- Clownshoesms 10y ago> 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?
- kuschku 10y agoDefinitely, 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.
- swiley 10y agoDoesn'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.
- wtallis 10y agoYou'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.
- mirimir 10y agoFirst, check your CPU for vPro: https://ark.intel.com/Search/FeatureFilter?productType=processors&VProTechnology=true 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.
- efm 10y agoThe 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.
- mirimir 10y agoThanks. Both "# modprobe -nr mei" and "# modprobe -nr mei_me" report that the module isn't found.
- filomeno 10y agoFrom 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.