An update to this:
Intel has updated bits for NUC users:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00057&languageid=en-fr
Category: Uncategorized
ME Cleaner
ME Cleaner: A cleaner for Intel ME (Management Engine) images.
This tools removes any unnecessary partition from an Intel ME firmware, reducing its size and its ability to interact with the system. It should work both with Coreboot and with the factory BIOS. Currently this tool:
* Scans the FPT (partition table) and checks that everything is correct
* Removes any partition entry (except for FTPR) from FPT
* Removes any partition except for the fundamental one (FTPR)
Teddy Reed’s intro to ARM-TF, OP-TEE, and ARM UEFI
“This is a walkthrough for flashing custom ARM Trusted Firmware, OP-TEE, and the ARM UEFI Platform code on the Hikey board. Custom means code we’ve built it on our development machine, we’re not making any changes to these reference implementations just yet.[…]”
https://prosauce.org/blog/2016/11/25/hands-on-introduction-to-arm-firmware-using-the-hikey
Lenovo UEFI patches and Microsoft Patch Tuessday
InfoWorld has an article about Microsoft changing it’s patch schedule, along with multiple UEFI patches from Lenovo:
Limitations of Android N encryption
The limitations of Android N Encryption
Over the past few years pixelphonewe’ve heard more about smartphone encryption than, quite frankly, most of us expected to hear in a lifetime. We learned that proper encryption can slow down even sophisticated decryption attempts if done correctly. We’ve also learned that incorrect implementations can undo most of that security. In other words, phone encryption is an area where details matter. For the past few weeks I’ve been looking a bit at Android Nougat’s new file-based encryption to see how well they’ve addressed some of those details in their latest release. The answer, unfortunately, is that there’s still lots of work to do. In this post I’m going to talk about a bit of that. […]
UK National Cyber Security Center and firmware
Getting a grip on firmware
Firmware security research project
If you’re reading this, you’re probably already aware of the importance of keeping your devices’ software up to date and securely configured. But do you treat your firmware in the same way? Have you ever asked yourself what would happen if the firmware on any of your devices was compromised? Would you even know if your smartphone or tablet’s firmware had been hacked? We are planning a thorough investigation of how best to securely manage and configure firmware. This blog post outlines the thinking behind the project. […]
https://www.ncsc.gov.uk/blog-post/getting-grip-firmware
Vincent on coreboot/FSP/PI/TPM/UEFI/more
Vincent Zimmer has a new blog post with *many* topics: the new PI spec, FSP, coreboot, TPM, and a summary of the Seattle UEFI plugfest.
http://vzimmer.blogspot.com/2016/11/conferences-forums-and-writings.html
Symbolic Execution of SMM
Slides are available from Zero Nights on the symbolic execution project for SMM. I am hoping that this gets open-sourced eventually!
OnChip has RISC-V on CrowdSupply
Andrew Back posted a message on the Open Source Hardware list, noting that OnChip has a RISC-V chip on CrowdSupply.
“The fully open source RISC-V based 32-bit microcontroller, Open-V, is now crowdfunding on Crowd Supply:
https://www.crowdsupply.com/onchip/open-v
http://oshug.org/pipermail/oshug/2016-November/000575.html
http://www.onchipuis.io/
.
coreboot at 33rd Chaos Communications Congress
coreboot will be at 33C3, the 33rd Chaos Communications Congress, happening in December in Germany.
https://twitter.com/coreboot_org/status/799282822875848704
https://events.ccc.de/congress/2016/wiki/Assembly:Coreboot
DHS guidance on securing the IoT
InfoSecurity Magazine has a story about DHS’s new guidance on IoT security. It looks like the DHS documents came out mid-November.
http://www.infosecurity-magazine.com/news/us-government-releases-new-iot/
https://www.dhs.gov/securingtheIoT
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:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-lockdown
http://vger.kernel.org/majordomo-info.html
Intel NUC’s Vulnerable to SMM Exploit
A new Intel Security Center advisory:
Intel® Branded NUC’s Vulnerable to SMM Exploit
Intel ID: INTEL-SA-00057
Product family: Intel® NUC Kits
Impact of vulnerability: Elevation of Privilege
Severity rating: Important
Original release: Oct 03, 2016
Last revised: Nov 15, 2016
Intel is releasing updated BIOS firmware for a privilege escalation issue. This issue affects Intel® NUC Kits listed in the affected products section below. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable BIOS to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Intel highly recommends updating the BIOS of all Intel® NUC’s to the recommended BIOS or later listed in the table of affected products. Intel would like to thank Security Researcher Dmytro Oleksiuk for discovering and reporting this issue.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00057&languageid=en-fr
CHIPSEC v1.2.5 published!
This version has Python.org-based packaging, which I think was originally introduced by the GRR fork of CHIPSEC. This means you can do “pip install chipsec” on some systems. It will require a compiler toolchain to build and install the kernel driver, which is a bit more than you’d expect from a normal pip Python package install… 🙂
Unclear of all the other changes yet:
Google use of GRR, including CHIPSEC
“Firmware Biopsy: Enterprise Infrastructure Protection”
is a talk on use of CHIPSEC in Google Rapid Response (GRR). Click on the URL in the below tweet for the presentation from Ruxcon:
Linux 4.10 UEFI changes
Matt Fleming posted UEFI changes for Linux 4.10 kernel.
Folks, please pull the following v4.10 material. There isn’t a huge amount of stuff here. The biggest change is the EFI dev path parser code from Lukas to get thunderbolt working on his macbook.
* Fix an allocation bug in the generic EFI libstub where alignment and adjusted size isn’t taken into account – Roy Franz
* Update the EFI MAINTAINERS entry to include ARM and arm64 files and directories – Ard Biesheuvel
* Add new feature to seed the RNG from the stashed value returned by EFI_RNG_PROTOCOL in EFI stub and wire up for ARM/arm64 – Ard Biesheuvel
* Retrieve Apple device properties from within the EFI stub to fully support thunderbolt devices on Apple Macbooks – Lukas Wunner
More details on the Thunderbolt patch:
thunderbolt: Use Device ROM retrieved from EFI:
Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is empty with uid 0x1000000000000. (Apple started factory-burning a unit- specific DROM with Thunderbolt 2.) Instead, the NHI EFI driver supplies a DROM in a device property. Use it if available. It’s only available when booting with the efistub. If it’s not available, silently fall back to our hardcoded DROM. The size of the DROM is always 256 bytes. The number is hardcoded into the NHI EFI driver. This commit can deal with an arbitrary size however, just in case they ever change that. Background information: The EFI firmware volume contains ROM files for the NHI, GMUX and several other chips as well as key material. This strategy allows Apple to deploy ROM or key updates by simply publishing an EFI firmware update on their website. Drivers do not access those files directly but rather through a file server via EFI protocol AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818. The NHI EFI driver amends that file with a unit-specific uid. The uid has 64 bit but its entropy is much lower: 24 bit represent the model, 24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI driver obtains the serial number via the DataHub protocol, copies it into the DROM, calculates the CRC and submits the result as a device property. A modification is needed in the resume code where we currently read the uid of all switches in the hierarchy to detect plug events that occurred during sleep. On Thunderbolt 1 root switches this will now lead to a mismatch between the uid of the empty DROM and the EFI DROM. Exempt the root switch from this check: It’s built in, so the uid should never change. However we continue to *read* the uid of the root switch, this seems like a good way to test its reachability after resume.
http://vger.kernel.org/majordomo-info.html
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next
EBC Debugger added to EDK2
Pete Batard has added EBC Debugger support to the EDK2 project! As I understand it, there was EBC Debugger support in the original EDK project, but it was not carried forward into the EDK2 project, so this is great news! It sounds like this initial patch will need to go through an iteration or two, so hold off until the dust settles…
“The EBC Debugger, which was present in Tianocore, is an invaluable tool for EBC development. This patch adds it back into the EDK2, allowing, for instance, the compilation of an AARCH64 EBC debugger. […]”
EBC is a bytecode and VM that is widely used, yet barely understood by most, including security researchers. While EBC was initially an Intel-centric technology, only supporting their Itaniaum, x86, and x64 processors, and only available from their commercial-only Intel C Compiler, these days ARM is also targetting EBC support. I’m unclear about ARM’s EBC compiler options, perhaps only via their commecial-only compiler? I hope someone gets EBC support into an open source C compiler codebase, like clang or GCC.
More information:
https://github.com/pbatard/EbcDebugger/commit/906e87ed6ceab1c361ba6f681bef48179baf549e
https://github.com/pbatard/edk2/tree/EBCDebugger
http://www.uefi.org/node/550
https://github.com/tianocore/edk/tree/master/Sample/Universal/Ebc/Dxe
https://sourceforge.net/projects/efidevkit/files/Documents/EBC%20Debugger%20User%20Manual.pdf/download
https://lists.01.org/mailman/listinfo/edk2-devel
OpenPOWER code added to FWTS
Deb McLemore of IBM has submitted multiple updates to FWTS, the FirmWare Test Suite, adding a lot more support for OpenPOWER OPAL firmware.
opal: pci_info: Add OPAL PCI Info validation
opal: mem_info: Add OPAL MEM Info validation
opal: cpu_info: Add OPAL CPU Info validation
devicetree: dt_sysinfo: Add OPAL firmware version checks
olog: olog.json: Update OPAL skiboot errors to check on olog scan
There is a lot of useful diagnostic information in this code, example:
“You are running in manufacturing mode. This mode should only be enabled in a factory during manufacturing.”
More information:
https://lists.ubuntu.com/mailman/listinfo/fwts-devel
Joanna announces codehash.db, a software/firmware code hash database
Joanna Rutkowska of Invisible Things Lab posted a message to the Secure Desktops list, announcing a new public hash database for software and firmware! lightly-edited announcement below, see the list archive for full announcement:
Introducing a public db for software and firmware hashes:
I’ve recently created this simple repo which is an attempt to somehow addresses a problem of software and firmware “verifiability” (the word is somehow loaded, hence in quotation marks). I imagine that once more and more vendors, such as e.g. Tails or Subgraph, or secure messenger app devs, or various firmware projects (coreboot, Trezor, OpenWRT, etc) agreed to stick to this format, we could expect each of them to submit hashes + signatures with each new release of their software. These hashes would then be subsequently verified and submitted by other witnesses. Each person or organization will be free to host a repo similar to the one above, only with the “proofs” from the select witness they consider somehow trusted or meaningful.
https://github.com/rootkovska/codehash.db
https://secure-os.org/cgi-bin/mailman/listinfo/desktops
(Now if OEMs and IBVs would only publish their golden image hashes, including after each update….)
OpenCIT 2.2 released
Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.
New Features in 2.2:
– TPM 2.0 support.
+ Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
+ Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
+ Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256. SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
+ The CIT Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version. This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
+ Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
+ TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
+ TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.
For more information, see the full announcement on the oat-devel@lists.01.org mailing list.
Firmware Security 
You must be logged in to post a comment.