Tag: Matthew Garrett

Matthew Garrett: Firmware security, why it matters and how you can have it

~ hucktech ~ Leave a comment

https://2019.linux.conf.au/schedule/presentation/110/

Installing Coreboot on Lenovo X210

~ hucktech ~ Leave a comment

[…]The other fun thing about it is that none of the firmware flashing protection is enabled, including Intel Boot Guard. This means running a custom firmware image is possible, and what would a ridiculous custom Thinkpad be without ridiculous custom firmware? A shadow of its potential, that’s what. So, I read the Coreboot[1] motherboard porting guide and set to.[…]

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

Lenovo should be giving Matthew a free X210 for this effort:

Matthew Garret on the Linux Kernel Lockdown Patch, and UEFI

~ hucktech ~ Leave a comment

Re: Kernel Lockdown Patch:
https://firmwaresecurity.com/2018/04/04/linus-on-uefi-and-kernel-lockdown-patch/
https://firmwaresecurity.com/2017/10/19/linux-kernel-lockdown-patch/
https://firmwaresecurity.com/2017/04/11/background-for-kernel-lockdown-patch/
https://firmwaresecurity.com/2017/04/05/linux-kernel-lockdown-2/
https://firmwaresecurity.com/2016/11/17/linux-kernel-lockdown/

Matthew Garret of Google has a new blog post that gives some background on this patch, w/r/t UEFI:

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

Matthew on Intel ME security: worst case here is terrible, but unlikely to be relevant to the vast majority of users

~ hucktech ~ Leave a comment

Matthew has an excellent new blog post on recent Intel ME security news.

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

[…]The big problem at the moment is that we have no idea what the actual process of compromise is. Intel state that it requires local access, but don’t describe what kind. Local access in this case could simply require the ability to send commands to the ME (possible on any system that has the ME drivers installed), could require direct hardware access to the exposed ME (which would require either kernel access or the ability to install a custom driver) or even the ability to modify system flash (possible only if the attacker has physical access and enough time and skill to take the system apart and modify the flash contents with an SPI programmer). The other thing we don’t know is whether it’s possible for an attacker to modify the system such that the ME is persistently compromised or whether it needs to be re-compromised every time the ME reboots. Note that even the latter is more serious than you might think – the ME may only be rebooted if the system loses power completely, so even a “temporary” compromise could affect a system for a long period of time. It’s also almost impossible to determine if a system is compromised. If the ME is compromised then it’s probably possible for it to roll back any firmware updates but still report that it’s been updated, giving admins a false sense of security. The only way to determine for sure would be to dump the system flash and compare it to a known good image. This is impractical to do at scale. So, overall, given what we know right now it’s hard to say how serious this is in terms of real world impact. It’s unlikely that this is the kind of vulnerability that would be used to attack individual end users – anyone able to compromise a system like this could just backdoor your browser instead with much less effort, and that already gives them your banking details. The people who have the most to worry about here are potential targets of skilled attackers, which means activists, dissidents and companies with interesting personal or business data. It’s hard to make strong recommendations about what to do here without more insight into what the vulnerability actually is, and we may not know that until this presentation next month.[…]

TPM microconf at 2017 Linux Plumbers Conference

~ hucktech ~ Leave a comment

Matthew Garrett has announced a TPM microconference at the upcoming Linux Plumbers Conference:

I’m pleased to say that after the success last year, there will be another TPM microconference at this year’s Linux Plumbers Conference. The current schedule has this taking place on Wednesday the 13th of September, so just under 4 weeks from now. We have a list of proposals for discussion at http://wiki.linuxplumbersconf.org/2017:tpms but please feel free to add more! I intend to finalise the schedule by the end of next week, so please do so as soon as you can. For those of you who weren’t there, the Linux Plumbers conference is an event dedicated to bringing together people working on various infrastructural components (the plumbing) of Linux. Microconferences are 3 hour long events dedicated to a specific topic, with the focus on identifying problems and having enough people in the room to start figuring out what the solutions should be – the format is typically some short presentations coupled with discussion.

From James Bottomley’s comments on the LPC entry on this microconf:

Following on from the TPM Microconference last year, we’re pleased to announce there will be a follow on at Plumbers in Los Angeles this year. The agenda for this year will focus on a renewed attempt to unify the 2.0 TSS; cryptosystem integration to make TPMs just work for the average user; the current state of measured boot and where we’re going; using TXT with TPM in Linux and using TPM from containers.

http://wiki.linuxplumbersconf.org/2017:tpms

http://www.linuxplumbersconf.org/2017/trusted-platform-module-microconference-accepted-into-the-linux-plumbers-conference/

Full text of Matthew’s email:
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

Intel AMT, continued

~ hucktech ~ Leave a comment

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.

https://github.com/mjg59/mei-amt-check

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
https://sourceforge.net/projects/openamt/

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

Linux Kernel lockdown

~ hucktech ~ Leave a comment

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:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-lockdown
http://vger.kernel.org/majordomo-info.html

Matthew Garrett on Linux boot security

~ hucktech ~ Leave a comment

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.

https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time

 

Help fund Matthew’s Patreon IoT reviews

~ hucktech ~ Leave a comment

I just learned about patreon.com. Matthew Garrret is listed on Patreon, hoping for donations to help review IoT devices. Please help fund Matthew, if you have the ability. Thanks!

https://www.patreon.com/mjg59

Why Matthew is on Patreon
There’s a growing number of Internet of Things devices on the market, from smart lightbulbs through smart coffee makers to smart air fresheners. You plug them all into your network and you communicate with them via your phone. At first glance they may seem like unnecessary toys, but there are many real ways they can improve lives. Smart switches can be an important assistive technology. Internet connected cameras can help people’s sense of security. Heart monitors can aid the design of an appropriate fitness regime. But how secure are they? When you plug in that smart switch, are you actually allowing attackers to gain access to your home network? Is your baby monitor happily streaming the interior of your house to anyone who asks it to? Are your lightbulbs secretly intercepting your website login details? Are your health details accessible to the entire internet? I’m a full time security developer with an extensive experience of embedded hardware and reverse engineering, and I’ve been using that to review devices. The results so far have not been positive – most devices I’ve investigated have been horribly insecure, and in one case my review caused the seller to pull the product. I’d love to carry on making reviews and helping customers make informed choices about whether they’re taking a risk by plugging in one of these smart devices, but these aren’t cheap. This is where you come in. Making a small donation means that I can keep buying devices and reviewing them. You won’t get anything special in return other than a link to the review – security information shouldn’t be restricted to people who pay for it. But it will make it easier for people to know whether there are obvious and terrible security issues with a product, and that’s good for everyone.

Matthew on x86 boot security

~ hucktech ~ Leave a comment

Apple has a lot of work to do, but they just hired LegbaCore, so they should be able to improve.

Linux has a lot of work to do, to catch up to Windows. Luckily there are people like Matthew working on it.

OEMs/Intel has a lot of work to do: they should be working to build the Stateless Laptop that ITL has proposed.

http://mjg59.dreamwidth.org/39339.html

Hardware/Firmware security at CCC!

~ hucktech ~ Leave a comment

There are likely other presentations at CCC that’re worth attending, but here are two that you MUST ATTEND, if you’re going to CCC:

Joanna Rutkowska
Towards (reasonably) trustworthy x86 laptops
Can we build trustworthy client systems on x86 hardware? What are the main challenges? What can we do about them, realistically? Is there anything we can? In the first part we will take a look at the security problems we encounter on modern Intel-based x86 systems, specifically on laptops. In the second part we will discuss how most (all?) of these problems could be addressed, with just minimal hardware modifications realizable by laptop OEMs.

Matthew Garrett
Beyond Anti Evil Maid: Making it easier to avoid low-level compromise, and why you’ll still lose
In 2011, Joanna Rutkowska unveiled an easy-to-use tool for mitigating many attacks on system boot chains by using the TPM – the Anti Evil Maid. Unfortunately the implementation was difficult to incorporate into normal system boot in a secure manner – anybody able to observe a user could recreate the secret. This presentation describes a method to allow systems to prove their identity to the user without making it trivial for attackers to mimic a secure boot and extract secrets from the user, and why the state of modern hardware means this may still not be enough. A correctly implemented Trusted Boot solution makes it possible for systems to prove to other systems that they have booted with the expected boot chain. The Anti Evil Maid technique took advantage of this to encrypt a secret with the TPM in such a way that a system whose firmware or bootloader had been compromised would no longer be able to decrypt that secret. Unfortunately, the use of a static secret makes it easier for an attacker to mimic a good boot – as a result, a sufficiently motivated attacker could circumvent Anti Evil Maid and convince the user that a compromised system was in a good state. This presentation describes the use of shared trust between the system and another device, making it significantly more difficult for an attacker to mimic a trusted boot. It includes a description of the implementation of Trusted Boot support in Free operating systems on modern UEFI systems, how this can be tied into sharing trust between multiple devices and the limitations that may still permit state-level actors to compromise these techniques.

https://events.ccc.de/congress/2015/
https://events.ccc.de/congress/2015/Fahrplan/events/7352.html
https://events.ccc.de/congress/2015/Fahrplan/events/7343.html