Intel AMT Checker for Linux (opens in new tab)

So secretive because its so vulnerable as any of their shitty low level nonsense features. Would be nice if they just focsed on ipc and efficient throughput instead of making it swiss cheese!

> Why would Intel insist on being so secretive about their management engine?

It includes DRM (Protected Audio/Video Path), for one.

Do you mean secretive about how it works or do you mean secretive about its existence?

There is a driver for it in the Linux kernel source tree.

Looks like it came in maybe around v3.9-rc1?

http://elixir.free-electrons.com/linux/v3.9-rc1/source/drive...

Did any Linux users question what this was at that time?

Is this driver part of the "default" Linux kernel configs?

What if the user compiles their kernel without this driver?

Would that change what could or could not be done by someone accessing the "ME" remotely?

The ME isn't much more secret than, say, the memory controller.

The issues page has a report of the same error (as does my i5-6600) and the author says:

>Ok, I'm /inclined/ to believe that this indicates that the system doesn't implement AMT at all, but I'll try to do some more research.

> Requires that the mei_me driver (part of the upstream kernel) be loaded.

Maybe the driver isn't loaded?

Here is an issue for it: https://github.com/mjg59/mei-amt-check/issues/1

Upgrade your kernel, or build the kernel with the AMT module

Unfortunately, there are too few hardware developers and not enough hardware-awareness, thanks to the good abstraction nowadays. In the modern age, only few software devs cares about the underlying hardware, because it just works. The thing is, software _runs_ on hardware and any bug/backdoor etc in it undermines everything above.

Did you know that the baseband chip in your smartphone runs it's own linux? Or that every SIM card comes with java applications that can communicate with it? I guess not.

Considering how much hardware is required on a modern PC main board, it's really not that surprising that there are backdoors, bugs, or other mechanisms that can be exploited.

If your servers have multiple network ports and you aren't using them all, don't use the first one. Apparently the ME interface is only exposed on the main network interface.

Xeon servers don't have AMT, but you might want to verify that your BMCs are firewalled and fully patched.

It's comical at this stage.

I am tempted to go back to dialup style connectivity. Meaning i disconnect the router from the net unless i absolutely need something online.

Thanks, I added that.

1) Intel ME. ALL Intel x86 processors for a long time have shipped with a second, closed-source processor on the same chip. This is called the Management Engine (ME). This processor has in theory complete control over the other one as well as its own ability to communicate over the network as long as the computer is connected to power even if powered down, with no way to check or control it securely.

2) AMT. These Intel processors may have a service enabled called Active Management Technology (AMT). Intel says that AMT usually comes disabled by default on "consumer" hardware (but Intel is not too specific about what this means, e.g. prebuilt only or CPUs you buy at the store?). AMT is like a remote desktop feature for the CPU. It allows someone to log in remotely and control the computer or diagnose problems, no matter what the "main" processor's state (even powered off).

3) The vulnerability. Suprise, AMT turns out to have a serious security vulnerability that allows a hacker to take control of the PC.

4) Uncertainty. It is difficult, due to Intel's vagueness, to figure out whether one's CPU even has AMT capability and whether it is turned on ("provisioned") by default. This is compounded by the fact that it is turned on or off by the motherboard BIOS settings but there are tons of motherboards from tons of manufacturers and it's not clear which ones support AMT, whether AMT might be provisioned on a motherboard that does not have any menu option regarding AMT, etc. The chances of motherboard manufacturers relasing information about this, let alone patches, for all their motherboards from the past 8 years, seems slim.

4.1) Linux. In particular, Intel has released a handy "detection guide"[1] that only applies to Windows. Macs are presumably "consumer hardware" only, so that mainly leaves Linux users out to dry.

Please correct me if I missed any details above.

[1] https://downloadcenter.intel.com/download/26755

It turns out all(?) Intel CPUs in the last decade has a co-CPU that is always running as long as there is electricity available - even when shut down - that is continuously executing a "management engine" bios program, which your main CPU or OS cannot prevent (in fact, if the ME fails to "check in", the main CPU will automatically shutdown in 30 minutes). And, of course, it turns out there is a remote exploit for it. (The co-CPU intercepts network packets on its own, too, apparently)

This explains what it is and why everyone is (or should be) upset about it: http://www.intel.com/content/www/us/en/architecture-and-tech...

I looked through it first. Not thoroughly enough to spot anything really underhanded, but it seems to be well written code that does stuff like what it claims.

The author is pretty well-known

https://en.wikipedia.org/wiki/Matthew_Garrett

I did at least.

Lenovo lists the X260 as vulnerable to CVE-2017-5689 [0], implying it supports AMT. My X240 definitely has AMT, it would be a bit odd for them to remove it in later generations.

[0] https://support.lenovo.com/us/en/product_security/LEN-14963

When you first set up your Mac, you are asked explicitly whether you want Find My Mac turned on and the Preference to turn it off is then in plain sight in the iCloud preferences. In what way are the two comparable?

Similarly, on an Intel NUC with i5-6260U:

    # git rev-parse HEAD
    9aa755885093fc8ca8c822797a30ed98ffe2e166
    # make
    gcc     mei-amt-check.c   -o mei-amt-check
    # modprobe mei-me
    # ./mei-amt-check -v
    Cannot open /dev/mei: No such file or directory
    # l /dev/*mei*
    /bin/ls: cannot access /dev/*mei*: No such file or directory
    # dmesg |grep -i mei
    #

A little confusing as the program is supposed to show "Intel AMT: DISABLED" 'If run on a system with no AMT'.

Fixed in this commit: https://github.com/mjg59/mei-amt-check/pull/4/commits/4f2fef...

IPMI does not replace MEI. It sits off to the side. Odds are, MEI/AMT is off in your firmware.

From the readme:

  In this state, AMT is not vulnerable to CVE-2017-5689.