Intel AMT, continued

Matthew Garrett has a new tool to check for AMT on Linux:

If AMT is enabled and provisioned and the AMT version is between 6.0 and 11.2, and you have not upgraded your firmware, you are vulnerable to CVE-2017-5689. Disable AMT in your system firmware.


A little bird told me some info about Intel AMT and Linux:

* Some BMC/IPMI devices also listen on port 623 because they support the same asf-rmcp protocol. So if you are using nmap to scan networks you may see false positives from these devices.

* The Intel OpenAMT tool can be used on Linux to determine if AMT is enabled. The procedure is something like:
  * build with: ./configure;make
  * on the system to test, load the mei modules with: modprobe mei-me
  * run the src/lms binary (only uses standard libraries, no need to ‘make install’)
  * check daemon.log, not enabled should be something like “LMS: Cannot connect to Intel AMT via MEI driver”
  * clean up by killing the running lms process, removing the lms binary, and unloading the mei modules: rmmod mei-me mei

* On Linux, blacklisting the mei-me/mei modules will prevent local access to AMT, but doesn’t help if it’s already enabled.


Matthew Garrett leaves CoreOS, joins Google

Matthew Garrett is leaving CoreOS and has gone to Google!




Linux Kernel lockdown

David Howells of Red Hat submitted a 16-part patch to the Linux-(Security,EFI,Kernel) mailing lists, with an interesting security patch for the Linux kenel. The patch includes contributions from: David Howells, Josh Boyer, Kyle McMartin, Matthew Garrett, and Dave Young. Quoting the patch announcement:

These patches provide a facility by which a variety of avenues by which userspace can feasibly modify the running kernel image can be locked down. These include:

* No unsigned modules and no modules for which can’t validate the signature.
* No use of ioperm(), iopl() and no writing to /dev/port.
* No writing to /dev/mem or /dev/kmem.
* No hibernation.
* Restrict PCI BAR access.
* Restrict MSR access.
* No kexec_load().
* Certain ACPI restrictions.
* Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot status, provided the shim isn’t insecure.  The lock-down can be lifted by typing SysRq+x on a keyboard attached to the system. They are dependent for some EFI definitions on the keys-uefi branch.

Copy secure_boot flag in boot params across kexec reboot
Add the ability to lock down access to the running kernel image
efi: Get the secure boot status
efi: Lock down the kernel if booted in secure boot mode
efi: Disable secure boot if shim is in insecure mode
efi: Add EFI_SECURE_BOOT bit
hibernate: Disable when the kernel is locked down
acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
Add a sysrq option to exit secure boot mode
kexec: Disable at runtime if the kernel is locked down
PCI: Lock down BAR access when the kernel is locked down
x86: Lock down IO port access when the kernel is locked down
ACPI: Limit access to custom_method when the kernel is locked down
asus-wmi: Restrict debugfs interface when the kernel is locked down
Restrict /dev/mem and /dev/kmem when the kernel is locked down
x86: Restrict MSR access when the kernel is locked down

More information:


Matthew and James on IoT security

Matthew Garret and James Bottomley have two blog posts out on IoT security.

I have nearly given up on IoT security, there is so much new IoT vulnerabilities in the news each day. 😦


Home Automation: Coping with Insecurity in the IoT


Matthew Garrett on Linux boot security

Amber Ankerholz wrote an article for Linux.com on the Linux boot-time security presentation that Matthew Garrett recently gave at the Linux Security Summit. In addition to the article, the video of the presentation is also available.




Purism announces advisory board

Purism announces advisory board, and one of the members is Linux firmware security expert Matthew Garrett, which is good news: