INTEL-SA-00075 – AMT Linux Detection and Mitigation Tools (opens in new tab)

https://mjg59.dreamwidth.org/48429.html

I don't have `ls` colorization enabled on this laptop, so I didn't immediately notice the binaries next to the source code; the first thing I noticed was the Makefile. So I just ran "make" to see what would happen.

By the time make was done my eyes had noticed the two different tools - and the fact that only one of them had rebuilt. So I freaked out, probably completely unnecessarily.

Essentially what I was thinking was, why is the unprovisioning tool binary that got copied into the distribution newer than the associated source code? How does that work?

The only scenario I can come up with is that a build server was mounted via NFS to the developer machine that prepared the source code, and the local machine's clock was a bit fast. If gcc was being run on the build server, that would produce an binary older than source.

However that does not explain why only the unprovisioning tool was affected in this way, and not the discovery tool (binaries are supplied for both).

Honestly, I'm probably barking up the wrong tree, and I kind of feel silly for posting the comment in the first place. I just wonder, that's all - it makes sense for the discovery tool to remain untouched, with the mitigation tool (the "off" switch) to be tinkered with (somehow).

As for what I'm implying, the worst-case scenario would be some kind of situation where the supplied binary version of tool "all bit completely" disables AMT, somehow leaving one tiny thing in a state where some later process can silently re-enable everything, or otherwise get access to the system. Maybe. Somehow. I have no idea.

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.