> If you reboot you should see a brief firmware splash mentioning the ME. Hitting ctrl+p at this point should get you into a menu which should let you disable AMT.

my Lenovo T450s's vPro/AMT setup menu (MEBx) requires a password from me. The default password ("admin") won't work -- which is wonderful, as I have no idea how to reset it. Yaey.

Try P@ssw0rd

I almost downvoted you until I realized you're you. It's seriously that?

>Intel® Setup and Configuration Software (Intel® SCS) Deployment Guide [0]

>5. Select Unconfigure this system using admin password, enter the admin password (P@ssw0rd) and click the Next button.

I can just imagine the conversation that lead to this:

"Johnson! This password doesn't meet our corporate password policy of having digits and symbols."

"But... but this is the default password. It's publicly available and is not supposed to provide any security."

"I don't care what your excuse is. Change it right now.

[0] http://www.intel.com/content/www/us/en/software/scs-deployme...

Ah geez. Time to create a competent chip manufacturer. Anyone got a spare US sized military budget?

To be fair, this thread wouldn't exist if it were absolutely trivial. ;)

On mine, there is an option to permanently disable AMT in the BIOS. I have enabled it a long time ago. Is it enough?

Also, you may need to go into BIOS/UEFI setup and enable an option along the lines of "Enable Intel ME Setup Hotkey" - at least this was needed on my Toshiba Tecra before I could use the Ctrl+P menu.

I don't trust Lenovo anymore. Far too many shenanigans like these from them. It wouldn't surprise me if they do it on purpose for the Chinese government. Also, the last Lenovo I bought, kind of fell apart in 2 years, so there's that, too.

Right, they've been caught several times now. How many didn't get publicized?

http://thehackernews.com/2015/08/lenovo-rootkit-malware.html

https://www.us-cert.gov/ncas/alerts/TA15-051A

etc.

What model? I've been buying used Thinkpads as of late (all Lenovo) and while I do see a slow quality down-ramp, even the newest are more robust than a similar Asus.

When it comes to x86-64, everything is back-doored, make no bones about it. If you want something less insecure, go get a T400 and libreboot it, or buy an SBC that can run with no blobs.

You could try removing any batteries on your board and drain the remaining current to ground. It should reset all bios settings.

Firmware settings are usually in flash these days, so they'll persist even if there's no charge.

Say you had an afflicted machine on the public internet, but completely firewalled in terms of IP, is this exploitable? I'm still not clear on how it happens.

Edit: Sorry read a bit deeper. Presumably this has to be enabled in the bios, but O/S level firewall won't help. Ack.

Firewalled at which stage? OS-level firewalling will do nothing, but if your border is rejecting packets for port 16992 then only people on your local network will be able to attack you.

Is there any reliable way to test this over the internet if I have a machine which I currently can't physically access?

Am I safe if it doesn't connect with telnet on 16992?

Thanks. Didn't realize there's another big thread, will have a read.

Was curious, it's this one: https://news.ycombinator.com/item?id=14237266

Sorry for not linking it, was in a rush.

Not at all a problem.

Is it true these packets are HTTP requests full of XML, i.e., SOAP? Do they use HTTPS on ports 16994 and 16995?

To avoid a crash, users can mount potentially malicious filesystems in userspace, i.e. users can run kernel drivers like ffs outside of the kernel. This feature comes from a non-Linux kernel. I have read this may be able to work on Linux too but I have never tried it.

Here is a script which speaks the AMT lingo: https://github.com/wentasah/amtterm/blob/master/amttool

It's clearly using SOAP, and looks like you can choose between HTTPS or HTTP.

> To avoid a crash, users can mount potentially malicious filesystems in userspace, i.e. users can run kernel drivers like ffs outside of the kernel. This feature comes from a non-Linux kernel. I have read this may be able to work on Linux too but I have never tried it.

Linux has FUSE for this, but...

- A lot of filesystems don't have FUSE drivers. You can't use the same kernel-mode drivers in userspace. In fact, off the top of my head, the only filesystem with both kernel-mode and userspace drivers is ZFS.

- It just reduces the threat, it doesn't eliminate it. There's no guarantee whatsoever that the FUSE kernel-side shim is invulnerable to bad inputs, though hopefully it's been audited. Something that never touches the kernel would still be preferable.

> which probably means it's possible to use a malformed filesystem to get arbitrary code execution in the kernel.

I'll concede that there are some older vulns allowing that, but if you meant for a reasonably up-to-date Linux or Win7+ system: reference needed.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4913, for instance?

Thanks - didn't hear about that one.

Filesystems are basically parsers that were only originally tested against well-formed input. Upstream Linux developers will happily tell you that you shouldn't allow untrusted users to mount filesystems (or trusted users to mount untrusted filesystems…), but unfortunately that's not really an option in the real world.

Well, for the past 4+ years "arbitrary kernel code execution through mounting a malformed FS" has been considered a major security issue, and a lot of effort does go into finding and fixing stuff like that through fuzzing, code audits, static analysis, etc (for both Linux and Windows). I think it is fair to say that this class of vulns is declining in frequency, with the rate of discovery having peaked somewhere within 2008-2012.

Eh. Bugs get fixed as they're found, but I don't see much evidence of it being taken into consideration when adding new code (in Linux, at least - it wouldn't surprise me if Windows were better in this respect)

Yeah, that is right. A bug can only be fixed once it has been found.. the question now is whether the rate of bugs found is greater than the rate of insertion of new bugs (which I guess is proportional to the number of new lines of code). If not the future is going to be terrible.. :D

If the attacker just provides a file system that contains setuid shells or unsecured device files, that's not really a bug and not remotely exploitable. But it's still a vulnerability.

Hopefully filesystems mounted by normal users will have nosuid,nodev enforced (whoever is responsible for this these days, policykit??). Please tell me I'm correct...

If I have AMT enabled on systems that never leave my network and no ports are forwarded through my firewall this should not be a problem. It could be a problem if someone found a bug in my router and got through the router but I'd be more concerned about iot devices than AMT on a couple desktops.