Intel AMT Checker for Linux | Hacker News Reader

Intel AMT Checker for Linux

github.com

227 pointslaamalif87 comments

Why would Intel insist on being so secretive about their management engine? Is it some kind of competitive advantage for them?

Supposedly, it's useful for management tasks in enterprise environments, but if I were CIO, I think I would ban VPro chips. Who wants ring -3 processes running on their network for which they have no information about?

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.

Documenting it shouldn't alter its effectiveness. I can tell you how AES works and that doesn't compromise anything.

I agree with you. But Intel would have to convince skeptical Hollywood executives of that, who are more inclined to just not let PCs have new content at all, since relatively few people consume TV and movies on PCs to begin with.

Personally, I think the right solution is to not have DRM for music, TV, and movies on PCs, purely for business reasons. What's happening today is that Intel is effectively shipping everyone who buys an x86 CPU a content decryption module, burning goodwill among free software advocates even though fewer than 1% of consumers will ever use the functionality (actually, does anyone use it?) It makes more business sense for consumers to just buy set-top boxes to consume content. It's not like anyone who buys a $450 Core i7 is going to balk at paying $35 for a Chromecast.

> But Intel would have to convince skeptical Hollywood executives of that

Does hollywood have an leverage whatsoever on intel? If intel decided they were removing any and all DRM features hollywood would have no choice but to accept.

No, Hollywood would just not let Intel-based PCs have access to their content. This would lose them zero revenue. As I said, anyone who can afford a $450 Intel CPU can afford a $35 Chromecast.

Hollywood holds all the cards here.

If you tell me how AES works and also give me the key you're using, then you're compromised. DRM relies on giving consumers the decryption key but making it hard for them to figure out how the system works (and sometimes making it hard to isolate the decryption key you've delivered to them).

That's because encryption is based on sound mathematical principles.

DRM is based on "physical access is not complete access", which is different.

It does make people less likely to want to buy the chip with the DRM though.

I don't think it would move the needle in that regard. Dell, Apple, and other large makers would never buy a CPU that isn't going to work with Netflix and other streaming services for anything other than servers and servers is the one case where ME and AMT can make sense.

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

The memory controller isn't running a web server that is accessible to anybody on the LAN.

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?

So, if it says "Error: IOCTL_MEI_CONNECT_CLIENT receive message. err=-1", what does it mean?

Tried it on i5-6260U, should be new enough to have the thing.

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

4.10 is fairly new, and the amt mod is loaded

Cool. thx

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

Maybe the driver isn't loaded?

It is.

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

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.

I got this message on a system which has a Core i7-4510 CPU; this is not on the list of systems with "vPro" technology. I've seen referenced as another name for the vulnerable component --- but given the marketing-spawned confusion around Intel CPU nomenclature, I can easily imagine someone (perhaps me!) getting confused on the point.

Search for "vPro" systems here: https://ark.intel.com/Search/FeatureFilter?productType=proce...

This isn't that helpful because you need a vPro-capable CPU and the proper chipset and AMT firmware to be vulnerable.

God #$%@ing damn it, this is why we can't have nice things. You can do only so much to not get pwned software wise, now you need to be paranoid about the hardware too?!

Going through all Xeon servers is going to be fun tomorrow.

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.

> the baseband chip in your smartphone runs it's own ...

Microkernel

In many if not most cases this kernel would be an L4 implementation.

> OKL4 has been deployed on over 2 billion mobile phones (https://en.wikipedia.org/wiki/Open_Kernel_Labs)

Modern hexagons run a full Linux under L4 also. It seems like the microkernel separation isn't really architected towards security AFAICT, but for running hard real time tasks on the same cores as the rest of the system.

It's comical at this stage.

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.

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

You absolutely need security updates, or your system will be out of date and extra-vulnerable as soon as you plug it in.

Makes a guy wish there was an alternate pathway for getting updates...

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

Good to know, thanks :)

I want to be able to bios disable Intel AMT and AMDs variant of it. This is another bad attack vector. Further i want a simpler boot loader UEFI is bloatware and bad for security as its easy to hide things in those huge prorietary binary blobs.

If anyone get compiling errors with 'timeval tv' being undefined add this to headers #include <sys/time.h>

Thanks, I added that.

It looks like I’m out the news cycle. What is AMT? Why would I need to check for it? Why just in Linux?

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...

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)

Not all Intel CPUs have AMT. Most consumer machines won't have it enabled, it's an enterprise targeted feature.

  > Does this mean every Intel system built since 2008 can be taken over by hackers?
  
  No. Most Intel systems don't ship with AMT. Most Intel systems with AMT don't have it turned on.

From an FAQ by MJG, the author of the tool we are discussing: https://mjg59.dreamwidth.org/48429.html

Your parent is correct. They aren't talking about AMT. They're talking about ME, which IS present in every Intel chip (since 2008-ish)

My grandparent was talking about AMT. That's why the question was 'What is AMT?' I'll edit for clarity though.

This sounds horrible, even though I knew about it before. What are the viable options for other manufacturers or architectures which don't come with this sort of thing, either for desktops or for laptops?

So the mainstream is Intel and AMD. Both are out.

https://libreboot.org/faq.html#intel https://libreboot.org/faq.html#amd

See https://libreboot.org/faq.html#whatcaniuse -- your best bet is older Intel / AMD.

There are some laptops https://www.crowdsupply.com/sutajio-kosagi/novena which are open.

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

> 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.

AMT is software so it's part of the BIOS image, not CPU. AFAIK it only works on "vPro" chipsets (Q series) thanks to Intel's market segmentation.

The ME processor is located in the PCH as far as I know. SoC systems have it all on one die, of course.

Did anyone read that code before using it? :)

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

That alone is not enough, though it helps. Being well-known means a more desirable account to steal, and this is code that must be run as root.

Moreover there is no trivial way to verify that https://github.com/mjg59 is github accout of Matthew Garrett. So all one needs to do is to create account that looks good and most people assume that it's safe.

Obviously I'm not saying that this is the case here. But it might not be the best idea to run whichever github project someone links to under root.

Yep, that's what I thought, too :-D

I tried to find some "Github" link in mjg59.dreamwidth.org pointing to github.com/mjg59, but I don't think there is any.

Definitely, you don't feel comfortable cloning and building a git repo to run it as root :P

> I tried to find some "Github" link in mjg59.dreamwidth.org pointing to github.com/mjg59, but I don't think there is any.

There is one here: https://mjg59.dreamwidth.org/38136.html

I did at least.

I'm shocked to say that the Thinkpad x260 does not have AMT at all.

Shocked not because I think it's a huge conspiracy to control your computer but because I honestly do believe AMT was made with the best intentions of providing a level of theft mitigation for devices. Just like "Find my Mac" from Apple that seems to get very little flack.

I'd be surprised if this meant that my pretty expensive Lenovo Thinkpad X-series lacks theft protection.

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?

i don't think anyone has found a machine yet where AMT is enabled out of the box either

AMT is enabled by default (but not provisioned) on an X220, for example.

sorry, I meant provisioned.

As far as I know (could be wrong) it doesn't even listen to any network ports until its provisioned

Ah, then yes, it seems, and you should be right (at least in principle - I'm not sure, either) with regards to network ports. (I've done some light scanning out of curiosity, but that's only anecdotal...)

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

My X230 does as well.

Hmm, I ensured the mei driver was loaded (lsmod confirms it), but I get: "Cannot open /dev/mei: No such file or directory"

dmesg shows: "[ 18.233688] mei_me 0000:00:16.0: Device doesn't have valid ME Interface [ 18.233700] mei_me 0000:00:16.1: Device doesn't have valid ME Interface"

So I'm guessing I'm not vulnerable. I suppose Supermicro replaced it with their own IPMI interface.

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

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'.

OK, with commit a4d8fca4d18e1ae896b0305a53e152b568596bc1 (still after running modprobe mei_me) it is saying:

    Unable to find a Management Engine interface - run sudo modprobe mei_me and retry.
    If you receive the same error, this system does not have AMT

(Sounds good)

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

"Intel AMT: ENABLED, AMT is unprovisioned". Does that mean AMT is still potentially vulnerable to attacks from user/kernelspace?

From the readme:

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

Thanks! Missed this part. Also, do you think it's a good idea to keep it in this state as opposed to updating in case Intel's new patches lock AMT down even further? This is the pattern I saw with Sony once - groups of users not updating their consoles because via exploiting it they could get more control over it.

You should be able to disable it in the BIOS. If you're not going to use it, I'd suggest disabling it. You could always reenable it later, should you find a need for it.

I have no BIOS option at all for this, yet it’s enabled and provisioned. What do I do?

Well, firstly, don't connect your machine to networks you don't trust the members of :)

If your machine's manufacturer still supports the device, check if they have any firmware updates available. Hopefully they will have recent updates that include a fix for the AMT authn issue.

If you want to disable it, Intel has provided a mitigation guide which has instructions on disabling LMS (which AMT is part of): https://downloadmirror.intel.com/26754/eng/Intel-SA-00075%20.... I've not had to follow it myself, good luck if you do :)

I'm just repeating stuff I've read from MJG, take a look at his FAQ around this issue: https://mjg59.dreamwidth.org/48429.html

The machine is self-assembled, and the motherboard manufacturer doesn’t provide updates.

I don’t run windows, though.

> Well, firstly, don't connect your machine to networks you don't trust the members of :)

I’ve already had issues with the intel card, so I’m running on a RealTek ethernet card for now anyway. But that’s no long term solution.

Now I’m curious how a self-assembled computer got into the provisioned state.

That’s an interesting question, isn’t it? Even more, how AMT was enabled in the first place, if the UEFI has no option for it.

And I’ve had massive issues with AMT before – for some reason, on Linux, the ME would force a reset of the network connection every 90 seconds (which is why I use an ancient realtek network card currently).

Possible explanations include bad defaults in the UEFI, a store sending me a used part instead of a new part, etc. If we go into conspiracy territory, NSA TAO interception would also be on the table. Very unlikely, though.

Is disabling always possible? I don’t find UI to disable in recent Lenovo ThinkStation BIOS even though I’ve seen such option previously in ThinkPad BIOS.

Intel has provided a mitigation guide that goes through how to disable LMS (local manageability services), which AMT is a part of. Take a look: https://downloadmirror.intel.com/26754/eng/Intel-SA-00075%20...

I meant disabling the ME-side stuff from BIOS. That’s for disabling the Windows-side component.

I disabled it in bios on my Lenovo T450s back when this was first reported and the tool reports...

Intel AMT is present AMT is unprovisioned

So disabling it puts it in the same state.

"Error: Management Engine refused connection. This probably means you don't have AMT"

$ ls /dev/mei0 -lh

crw------- 1 root root 246, 0 May 15 21:02 /dev/mei0

Is there a way to completely remove AMT ?

> Intel AMT: ENABLED > AMT is unprovisioned

Think I'd be alright even if it were provisioned as the ethernet port on this Dell Precision laptop got fried during a lightning storm last year (i.e. from reports I've read a wired connection is needed for the exploit to work). Then again, better to know AMT isn't provisioned than to rely on third party reporting.

I remember early word during this AMT debacle was that there were certain conditions in which AMT could be remotely provisioned. Were those statements false? Is Enabled/unprovisioned completely safe?

I'm running VMware on a whitebox with a H87 chipset and vPro capable processor. MEI shows up in dmesg.

Has anyone else checked their VMware box accordingly?

Reply on news.ycombinator.com