5 ms·

INTEL-SA-00075 – AMT Linux Detection and Mitigation Tools

47 points by laamalif 9y ago

ramshorns 9y ago
Looks like it does roughly the same thing as this [1]. I guess it's a tossup between a proprietary program from Intel or a free program on github from the person who found the bug. [1] https://news.ycombinator.com/item?id=14335159 https://news.ycombinator.com/item?id=14335159
- orblivion 9y ago
  I figure Intel already owns my machine. I may as well go with them.
- dfc 9y ago
  For what it is worth I think Maksim Malyutin from Embedi was the person that found the bug. MJG is the author of the check.
  - ramshorns 9y ago
    My mistake. I mistook his blog post discussing it [1] for an initial announcement of it, even though it links to an Intel announcement. https://mjg59.dreamwidth.org/48429.html https://mjg59.dreamwidth.org/48429.html
- a3_nm 9y ago
  The Intel program pops a weird license when you download it, but the files themselves, to my surprise, are not proprietary: they are dual-licensed under the BSD license and GPLv2 license.
pera 9y ago
This is weird: this tool says my laptop is vulnerable, although AMT is disabled. I also tried mjg59's mei-amt-check and it indicated that because my system is unprovisioned it was not vulnerable.
- ccrush 9y ago
  It's probably vulnerable.
- tyingq 9y ago
  There's a second bug that allows a local, non privileged user to provision AMT.
  - pasbesoin 9y ago
    This is the role of Intel's LMS -- Local Manageability Service. As I understand it from having to check for / disable the AMT vulnerability on a Linux machine and then on a Windows 10 machine: With AMT available but unprovisioned, the LMS vulnerability can be used to invoke LMS to provision AMT. Once provisioned, AMT can then be used to exploit the system. Intel's language that I've seen solely refers to LMS in the Windows context. Even with AMT unprovisioned, a Windows machine may well have the LMS service running. Intel's mitigation instructions for the problem describe two steps: 1) Getting AMT unprovisioned; 2) Disabling the LMS service so that it can't be exploited to enable/provision AMT. Step 2) is further complicated in that, in addition to LMS, there is also a "microLMS" service that is an independent substitute for LMS and can or may possibly be used in lieu of it to provision AMT and gain access. I didn't look further, yet, but the bit of description they threw at "microLMS" described it as an "open-source" LMS substitute. Most all the language I saw around LMS described it in the Windows context. I have a somewhat vague niggling in my mind that at least somewhere, I saw a description -- maybe -- of a Linux version or driver in the kernel or whatever. Unless I'm confusing that with the Linux AMT support that is of concern. The open ports in question with regard to this functionality appear to relate to both AMT and LMS. Even if AMT is unprovisioned, LMS may have some of those ports open and ready to communicate. So, after I went through steps to disable AMT -- and LMS, on the Windows 10 PC -- I repeated my scan of the relevant port ranges using nmap, from another machine, to check that they weren't responding. nmap -v -a -p600-699 [ip4 address] and nmap -v -a -p16900-16999 [ip4 address] . -v for verbose, -a for aggressive (why not?), and port ranges -- the last a bit over-broad, for the sake of my aging memory... By the way, on the Windows 10 machine I had to deal with, Intel's vulnerability scanner initially found AMT available but unprovisioned, LMS running, and microLMS not running. After went through Steps 1) and 2), rerunning their vulnerability scanner showed AMT unprovisioned (as before) LMS not running, but now microLMS running. WTF -- why did it apparently kick in upon these changes? The relevant ports as cited here and there in all the news about this, were all unresponsive to nmap scanning. And it was 2 am by that point. But I'm left wondering what microLMS is up to, and whether it's listening on some other port(s). Unfortunately, Windows 10 doesn't take well to nmap -v -a -p- [ip4 address] -- namely, expanding the former scan to encompass all ports, and starts choking the response rate. 2 am, and as I didn't want to wait who knows how long to get through that scan, I shut down the machine and left it, for the night. Anyone else know more about microLMS... Now that I'm remembering and maybe have the energy to look into it, myself? P.S. Since Intel's ME sits before the main processor running the OS and can intercept network packets ahead of it, from the NIC [a], you need to scan for the vulnerable ports from another device on the (local) network. If you are somewhere where you don't have multiple PC's at hand, on an Android phone, the Termux app has nmap 7.40 in its repositories and this works just fine to perform the scan in question. a) It is precisely those packets it intercepts and does not pass on to the OS, that are of interest.
i336_ 9y ago
Something security-related to keep in mind (TL;DR at end): Directory state after initial unpack (becomes important in a minute): -rwxr-xr-x 1 i336 users 19K May 13 10:43 INTEL-SA-00075-Discovery-Tool -rw-r--r-- 1 i336 users 27K May 13 10:57 INTEL-SA-00075-Discovery-Tool.c -rwxr-xr-x 1 i336 users 15K May 13 10:44 INTEL-SA-00075-Unprovisioning-Tool -rw-r--r-- 1 i336 users 16K May 13 10:42 INTEL-SA-00075-Unprovisioning-Tool.c -rw-r--r-- 1 i336 users 187 May 13 10:42 Makefile Build: $ cd INTEL-SA-00075-Discovery-Unprovisioning-Tool-Engineering-Release $ make gcc -I../../usr/include INTEL-SA-00075-Discovery-Tool.c -o INTEL-SA-00075-Discovery-Tool strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool $ OK; wipe and do it again: $ rm INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool $ make gcc -I../../usr/include INTEL-SA-00075-Discovery-Tool.c -o INTEL-SA-00075-Discovery-Tool gcc -I../../usr/include INTEL-SA-00075-Unprovisioning-Tool.c -o INTEL-SA-00075-Unprovisioning-Tool strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool $ Wait - why did the unprovisioning tool only get compiled on the second build? Because the binary for the unprovisioning tool is two minutes NEWER than the source code, as shown in the directory listing. The binary for the discovery tool is older than the source (as normal). Objectively it's 50/50 as to whether this is meaningless noise or something hidden. Of course everything points toward the former, but I thought I'd leave this here just in case. It's worth noting that an independent security company rapidly found (and announced) the vulnerability after the initial undisclosed CVE. So if it was that easy, this vulnerability has clearly been known about in various circles for a while. It's also worth noting that the build process strips the binary, which is arguably unnecessary, but is a nice way to explain why there are no debug symbols in the provided binaries. Again, I trust Intel and can easily talk this away as the inanites of bureaucracy and management and deadlines, but my "hmmm" sense is tingling nonetheless.
- orblivion 9y ago
  I'm not even sure what you're implying. EDIT: Is it that we should build it ourselves, and not trust the binaries? EDIT 2: Well, whatever it is, I moved away the binaries and just built it again myself. It was trivial; just type `make` and it's instantly there. (I guess you need gcc and stuff)
orblivion 9y ago
Thankfully it comes from an https connection on downloadmirror.intel.com. But there's no md5 sha1sum or sha256sum posted anywhere else. For whatever it's worth this is what I got: INTEL-SA-00075-Linux-Detection-and-Mitigation-Tools-v1.1.zip md5: a4645f80a0d573a8345545954d8da8ed sha1: 600ca16f9530dd9069b42e9696b0ea772eb059f0 sha256: 808620dd939bd3011c689eb8f4f56d92195159fd5cab570dd86598c68dd7ec63

47 points by laamalif 9y ago

Looks like it does roughly the same thing as this [1]. I guess it's a tossup between a proprietary program from Intel or a free program on github from the person who found the bug. [1] https://news.ycombinator.com/item?id=14335159 https://news.ycombinator.com/item?id=14335159

orblivion 9y ago
I figure Intel already owns my machine. I may as well go with them.
dfc 9y ago
For what it is worth I think Maksim Malyutin from Embedi was the person that found the bug. MJG is the author of the check.
- ramshorns 9y ago
  My mistake. I mistook his blog post discussing it [1] for an initial announcement of it, even though it links to an Intel announcement. https://mjg59.dreamwidth.org/48429.html https://mjg59.dreamwidth.org/48429.html
a3_nm 9y ago
The Intel program pops a weird license when you download it, but the files themselves, to my surprise, are not proprietary: they are dual-licensed under the BSD license and GPLv2 license.

pera 9y ago

This is weird: this tool says my laptop is vulnerable, although AMT is disabled. I also tried mjg59's mei-amt-check and it indicated that because my system is unprovisioned it was not vulnerable.

ccrush 9y ago
It's probably vulnerable.
tyingq 9y ago
There's a second bug that allows a local, non privileged user to provision AMT.
- pasbesoin 9y ago
  This is the role of Intel's LMS -- Local Manageability Service. As I understand it from having to check for / disable the AMT vulnerability on a Linux machine and then on a Windows 10 machine: With AMT available but unprovisioned, the LMS vulnerability can be used to invoke LMS to provision AMT. Once provisioned, AMT can then be used to exploit the system. Intel's language that I've seen solely refers to LMS in the Windows context. Even with AMT unprovisioned, a Windows machine may well have the LMS service running. Intel's mitigation instructions for the problem describe two steps: 1) Getting AMT unprovisioned; 2) Disabling the LMS service so that it can't be exploited to enable/provision AMT. Step 2) is further complicated in that, in addition to LMS, there is also a "microLMS" service that is an independent substitute for LMS and can or may possibly be used in lieu of it to provision AMT and gain access. I didn't look further, yet, but the bit of description they threw at "microLMS" described it as an "open-source" LMS substitute. Most all the language I saw around LMS described it in the Windows context. I have a somewhat vague niggling in my mind that at least somewhere, I saw a description -- maybe -- of a Linux version or driver in the kernel or whatever. Unless I'm confusing that with the Linux AMT support that is of concern. The open ports in question with regard to this functionality appear to relate to both AMT and LMS. Even if AMT is unprovisioned, LMS may have some of those ports open and ready to communicate. So, after I went through steps to disable AMT -- and LMS, on the Windows 10 PC -- I repeated my scan of the relevant port ranges using nmap, from another machine, to check that they weren't responding. nmap -v -a -p600-699 [ip4 address] and nmap -v -a -p16900-16999 [ip4 address] . -v for verbose, -a for aggressive (why not?), and port ranges -- the last a bit over-broad, for the sake of my aging memory... By the way, on the Windows 10 machine I had to deal with, Intel's vulnerability scanner initially found AMT available but unprovisioned, LMS running, and microLMS not running. After went through Steps 1) and 2), rerunning their vulnerability scanner showed AMT unprovisioned (as before) LMS not running, but now microLMS running. WTF -- why did it apparently kick in upon these changes? The relevant ports as cited here and there in all the news about this, were all unresponsive to nmap scanning. And it was 2 am by that point. But I'm left wondering what microLMS is up to, and whether it's listening on some other port(s). Unfortunately, Windows 10 doesn't take well to nmap -v -a -p- [ip4 address] -- namely, expanding the former scan to encompass all ports, and starts choking the response rate. 2 am, and as I didn't want to wait who knows how long to get through that scan, I shut down the machine and left it, for the night. Anyone else know more about microLMS... Now that I'm remembering and maybe have the energy to look into it, myself? P.S. Since Intel's ME sits before the main processor running the OS and can intercept network packets ahead of it, from the NIC [a], you need to scan for the vulnerable ports from another device on the (local) network. If you are somewhere where you don't have multiple PC's at hand, on an Android phone, the Termux app has nmap 7.40 in its repositories and this works just fine to perform the scan in question. a) It is precisely those packets it intercepts and does not pass on to the OS, that are of interest.

i336_ 9y ago

Something security-related to keep in mind (TL;DR at end): Directory state after initial unpack (becomes important in a minute): -rwxr-xr-x 1 i336 users 19K May 13 10:43 INTEL-SA-00075-Discovery-Tool -rw-r--r-- 1 i336 users 27K May 13 10:57 INTEL-SA-00075-Discovery-Tool.c -rwxr-xr-x 1 i336 users 15K May 13 10:44 INTEL-SA-00075-Unprovisioning-Tool -rw-r--r-- 1 i336 users 16K May 13 10:42 INTEL-SA-00075-Unprovisioning-Tool.c -rw-r--r-- 1 i336 users 187 May 13 10:42 Makefile Build: $ cd INTEL-SA-00075-Discovery-Unprovisioning-Tool-Engineering-Release $ make gcc -I../../usr/include INTEL-SA-00075-Discovery-Tool.c -o INTEL-SA-00075-Discovery-Tool strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool $ OK; wipe and do it again: $ rm INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool $ make gcc -I../../usr/include INTEL-SA-00075-Discovery-Tool.c -o INTEL-SA-00075-Discovery-Tool gcc -I../../usr/include INTEL-SA-00075-Unprovisioning-Tool.c -o INTEL-SA-00075-Unprovisioning-Tool strip INTEL-SA-00075-Discovery-Tool INTEL-SA-00075-Unprovisioning-Tool $ Wait - why did the unprovisioning tool only get compiled on the second build? Because the binary for the unprovisioning tool is two minutes NEWER than the source code, as shown in the directory listing. The binary for the discovery tool is older than the source (as normal). Objectively it's 50/50 as to whether this is meaningless noise or something hidden. Of course everything points toward the former, but I thought I'd leave this here just in case. It's worth noting that an independent security company rapidly found (and announced) the vulnerability after the initial undisclosed CVE. So if it was that easy, this vulnerability has clearly been known about in various circles for a while. It's also worth noting that the build process strips the binary, which is arguably unnecessary, but is a nice way to explain why there are no debug symbols in the provided binaries. Again, I trust Intel and can easily talk this away as the inanites of bureaucracy and management and deadlines, but my "hmmm" sense is tingling nonetheless.

orblivion 9y ago
I'm not even sure what you're implying. EDIT: Is it that we should build it ourselves, and not trust the binaries? EDIT 2: Well, whatever it is, I moved away the binaries and just built it again myself. It was trivial; just type `make` and it's instantly there. (I guess you need gcc and stuff)

orblivion 9y ago

Thankfully it comes from an https connection on downloadmirror.intel.com. But there's no md5 sha1sum or sha256sum posted anywhere else. For whatever it's worth this is what I got: INTEL-SA-00075-Linux-Detection-and-Mitigation-Tools-v1.1.zip md5: a4645f80a0d573a8345545954d8da8ed sha1: 600ca16f9530dd9069b42e9696b0ea772eb059f0 sha256: 808620dd939bd3011c689eb8f4f56d92195159fd5cab570dd86598c68dd7ec63