Travis Goodspeed has a tweet pointing out a blog post by lcamtuf on fuzzing using Intel Edison hardware:
http://lcamtuf.coredump.cx/edison_fuzz/
This is an EXCELLENT article.
Category: Uncategorized
John Kim: The Art of Debugging
Vincent Zimmer pointed out a new blog post on debugging:
So many areas of software are so much easier if you are good at debugging, it is sad how most people are bad at it.
Dodgy Coder on modern fuzzers
Dodgy Coder posted a new blog post on fuzzing.
Not specifically firmware-centric, but firmware could use a lot more fuzzing. If you haven’t looked at KLEE+S2E+Avatar+QEMU, check it out! 🙂 Intel is apparently using fuzzing to help test UEFI’s SMM:
Matthew Garrett’s new Linux fork
Matthew Garrett posted a blog bout leaving the Linux kernel community as a volunteer.
Excerpt from that blog:
Reaction to Sarah’s post about leaving the kernel community was a mixture of terrible and touching, but it’s still one of those things that almost certainly won’t end up making any kind of significant difference. Linus has made it pretty clear that he’s fine with the way he behaves, and nobody’s going to depose him. That’s unfortunate, because earlier today I was sitting in a presentation at Linuxcon and remembering how much I love the technical side of kernel development. “Remembering” is a deliberate choice of word – it’s been increasingly difficult to remember that, because instead I remember having to deal with interminable arguments over the naming of an interface because Linus has an undying hatred of BSD securelevel, or having my name forever associated with the deepthroating of Microsoft because Linus couldn’t be bothered asking questions about the reasoning behind a design before trashing it.
He also notes that “I’m doing a kernel. It won’t be big and professional like Linux.” It already has one commit:
kexec/uefi: copy secure_boot flag in boot params across kexec reboot
Kexec reboot in case secure boot being enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. In this state, the system is missing the protections provided by secure boot. Adding a patch to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot.
More Information:
http://mjg59.dreamwidth.org/38136.html
https://github.com/mjg59/linux
https://github.com/mjg59/linux/commit/4980702888a73e0fd4b48ef6f6683345011aa3a6
https://twitter.com/mjg59/
http://arstechnica.com/information-technology/2013/02/linus-torvalds-i-will-not-change-linux-to-deep-throat-microsoft/
Firmware Summit results
Al Stone of Red Hat posted a summary of the recent Firmware Summit that took place at the recent Linaro Connect event.
There’s a discussion on the state of ACPI on ARMv8, and Linux support. “So, please tell Linaro if there is something needed from the ACPI spec. Call, write or send carrier pigeons, just let us know.”
There is a discussion on ACPI’s _DSD and Device Properties. A new dsd@acpica.org mailing list has been setup to help. A new repo of information — on how to submit, approve, and use device properties in a community approved manner:
https://github.com/ahs3/dsd/tree/v-next/documentation
https://lists.acpica.org/mailman/listinfo/dsd
Matthew Garret wrote a document on Secure Boot:
https://lists.linaro.org/pipermail/fw-summit/2015-September/000170.html
I omitted a few items from the workshop’s notes. Read the full status here:
https://lists.linaro.org/pipermail/fw-summit/2015-October/000173.html
Trustworthy Computing Group update
TCG’s monthly newsletter came out today. Here are a few highlights:
TCG’s Stefan Thom has an article on the IoT security implications of remote firmware updates:
http://www.trustedcomputinggroup.org/media_room/news/404
TCG has announced a new liaison relationship with the Industrial Internet Consortium (IIC), related to Industrial IoT security and trust:
http://www.trustedcomputinggroup.org/media_room/news/405
TCG’s TPM 2.0 Library Specification was approved as a formal international standard under ISO/IEC. The specification was submitted to the ISO/IEC JTC 1 by the TCG following the JTC 1 Publicly Available Specification (PAS) Transposition process.
http://www.trustedcomputinggroup.org/media_room/news/392
TCG has a few specs for public review:
* TCG PC Client Specific Platform Firmware Profile for TPM 2.0 Systems Revision 1.0 Version 21
* TPM 2.0 Mobile Common Profile Family 2.0 Level 00 Revision 29
* TCG Storage Opal Integration Guidelines, Version 1.00 Revision 1.14
* TCG Trusted Network Communications Server Discovery and Validation Version 1.0, Revision 19
http://www.trustedcomputinggroup.org/resources/specifications_in_public_review
More information:
UEFI HTTP Boot whitepaper available
A few weeks ago the Tianocore project added a whitepaper on UEFI 2.5’s HTTP Boot:
http://www.tianocore.org/news/2015/09/17/HTTP-BOOT.html
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers
http://sourceforge.net/projects/edk2/files/General%20Documentation/
http://www.tianocore.org/news/feed.xml
If you were looking for instructions on how to setup Tianocore’s HTTP boot feature, on Windows-based systems, this document is for you!
I could be wrong, but I don’t think the TLS API has been added to Tianocore yet, so there is no HTTPS, only HTTP.
(Looking at the above SourceForge URL, it appears the Packaging Tool document was also recently updated, but not sure of the details.)
HTC finds monthly security Android updates unrealistic
Google recently started providing monthly updates to their Nexus devices, and some carriers are also following. As a few Android news sites are reporting, HTC is not following this monthly update model.
HTC notes monthly security updates for StageFright are “unrealistic”
I am constantly amazed at how badly carriers are w/r/t providing updates, some offer none.
Windows 10’s Compact OS feature
Anandtech and other sites have information about Windows 10’s Compact OS feature.
Image from TechNet blog:
Excerpt from MSDN:
Windows 10 includes tools to help you use less drive space. You can now compress the files for the entire operating system, including your preloaded desktop applications. Compact OS lets you run the operating system from compressed files (similar to WIMBoot in Windows 8.1 Update 1), and single-instancing helps you run your pre-loaded Windows desktop applications in compressed files. The new processes helps maintain a small footprint over time by using individual files, rather than combining them in a WIM file. Compact OS installs the operating system files as compressed files. Compact OS is supported on both UEFI-based and BIOS-based devices. Unlike WIMBoot, because the files are no longer combined into a single WIM file, Windows update can replace or remove individual files as needed to help maintain the drive footprint size over time.
More information:
http://www.anandtech.com/show/9676/windows-10-feature-focus-compactos
http://www.windowscentral.com/how-reduce-windows-10-footprint
https://msdn.microsoft.com/en-us/library/windows/hardware/dn940129%28v=vs.85%29.aspx
http://blogs.technet.com/b/mniehaus/archive/2015/09/16/windows-10-reducing-the-disk-footprint.aspx
fuzzing tool: afl
Hanno Böck has an article on LWN.net on the fuzzing tool afl, American Fuzzy Lop, created by Michał Zalewski of the Google security team:
AFL is a powerful fuzzer, and the above article is a good introduction. There are some more extensive tutorials on afl site, as well as the Fuzzing Project site. Hanno created the Fuzzing Project, which uses FOSS fuzzers to find and fix defects in core FOSS projects. Besides afl, there’s a Python attempt at a version, for those that prefer Python.
http://lcamtuf.coredump.cx/afl/
http://jwilk.net/software/python-afl
https://fuzzing-project.org/tutorials.html
(I wish there was more widespread usage of AFL in coreboot, tianocore, U-Boot, SeaBIOS, especially now that SMM is inside OVMF now…)
Nikolaj on UEFI security, part 6!
Nikolaj has released the 6th in his series on UEFI security!
http://habrahabr.ru/post/268135/
There’s also a bit of post-article discussion on researcher history on his Twitter feed:
libSboot: Secure Boot for U-Boot
Teddy Reed wrote libSboot 3 years ago, and I am just noticing it. 😦 This “Secure Boot” is different than the UEFI definition/implementation, and is U-Boot-specific. Excerpting the readme:
libSboot provides an example ‘Secured Boot’ for U-Boot and a U-Boot Second Phase Loader (SPL). libSboot attempts to define an example of how a platform can measure a pre-OS boot environment, thus providing a capability to ensure that a libSboot-enforced OS is only loaded in an owner-authorized fashion. A ‘Secure Boot’ concept is a common means to ensure platform security and integrity; understand that there are many implementations of a ‘Secure Boot’. libSboot uses a TPM v1.2 to implement a secure boot using a static root of trust measurement (SRTM). The static adjective implies a ‘read-only’ attribute, meaning libSboot expects its initialization to occur from ROM code. During this initialization libSboot performs a TPM_Start, TPM_SelfTest and checks that the TPM is neither deactivated nor disabled. The TPM must have its NVRAM locked, meaning access control is enforced. Initialization then checks each PCR used to measure the pre-boot environment and verifies they are reset. Finally Physical Presence is asserted to satisfy NVRAM read/write permissions.
https://github.com/theopolis/sboot
https://github.com/theopolis/u-boot-sboot
http://www.trustedcomputinggroup.org/community/2013/03/securing_embedded_devices_with_the_tpm__a_schmoocon_talk
http://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html
verifyBoot: check MBR for changes since last boot
A few years ago, Naja Melan wrote a verifyBoot. Excerpt of readme:
verifyBoot helps you to automate the process of checking if your MBR and a partition have not changed. verifyBoot makes sha256 hashes, first of the entire partition, then of your MBR and every file individually on the partition to help to find out what has changed. Nowadays it has become reasonably trivial to have linux installed on an encrypted partition using dmcrypt or other encryption software. The usual procedure for system start-up implies for the bios to load the MBR of the boot device or the boot sector of a partition which then loads grub. Grub will load the kernel which will then take care of further booting and decryption of the encrypted system partition. The problem with this approach is that everything in the “/boot” partition is not encrypted, facilitating a rootkit attack. An attacker could make the user run a process with the required privileges before or during a moment when the boot-medium gets plugged into the running operating system. This would allow them to place a rootkit, but also to access to the unencrypted data which would probably be what’s at stake here in the first place, so this is not a very interesting scenario when considering the threat of a rootkit. The second option an attacker has when they can’t convince the user to run a rogue process is is to get physical access to the boot-medium. Since “/boot” is not encrypted, they can easily install a rootkit compromising everything on the system as soon as the user provides their pass-phrase. It is possible to considerably raise the bar of such an attack by installing one’s boot partition on a usb-stick that one carries at all time. This makes it hard for an attacker to obtain the unencrypted boot partition to compromise it. What do you do however when you go swimming, or when you get arrested or if you forget your usb stick somewhere. You could no longer be a 100% sure it wasn’t compromised. After you have been separated from your boot medium you should verify that it hasn’t changed. This is where verifyBoot comes in. It helps you to automate that process of verification. Note that you will need a safe system to run the verification test from. This could be a verified live system that you obtain from a trusted source for example. If the boot system has changed you will need to create a new one from a trusted system or use an encrypted backup copy to restore your boot partition before booting from it.
It is tied to MBR, and doesn’t work with GPT. It isn’t perfect, but it helps BIOS/MBR users with some vulnerability detection. It also seems like a feature the kernel should have…
Linux kernel signing history
Rebecca Shapiro has posted an article, “A History of Linux Kernel Module Signing“, introductory paragraph excerpted below:
This article was originally written back in 2014 to accompany the talk I gave at Shmoocon called “The History of Linux Kernel Module Signing”. It is a discussion of various Linux kernel module signing implementations while highlighting some of the motivating factors behind various design decisions. I decided it was about time to publish this write up, so here it is. I have not found kernel module signing implementations outside of those created by Red Hat and by the mainstream Linux developers so there may be other flavors of Linux module signing that I do not mention here. The information I present here is based on Linux developer mailing lists and source code I have found. I do not have an insider perspective of the implementation decisions. If you want the ground truth, you should go talk to those developers who are a part of the narrative I present here.
Full article:
http://www.cs.dartmouth.edu/~bx/blog/2015/10/02/a-history-of-linux-kernel-module-signing.html
Looking just at UEFI Secure Boot issues with Linux driver signing, Linux distros do vary in their strength, I wish someone would gather data about this behavior for the mainstream distros.
new efi_capsule_loader Linux kernel interface from Intel
Hock Leong Kweh of Intel posted a patch to the Linux kernel which exposes a new UEFI capsule update interface. Some excerpts from the patch:
efi: a misc char interface for user to update efi firmware
Introducing a kernel module to expose capsule loader interface (misc char device file note) for user to upload capsule binaries. This option exposes a loader interface “/dev/efi_capsule_loader” for user to load EFI capsule binary and update the EFI firmware through system reboot. It expose a misc char interface for user to upload the capsule binary and calling efi_capsule_update() API to pass the binary to EFI firmware. The steps to update efi firmware are:
1) cat firmware.cap > /dev/efi_capsule_loader
2) reboot
Any failed upload error message will be returned while doing “cat” through Write() function call. Tested the code with Intel Quark Galileo platform. This patchset is created on top of Matt’s patchset:
1.)https://lkml.org/lkml/2014/10/7/390 “[PATCH 1/2] efi: Move efi_status_to_err() to efi.h”
2.)https://lkml.org/lkml/2014/10/7/391 “[PATCH 2/2] efi: Capsule update support”
See the linux-kernel/linux-efi/linux-fsdevel list archives for the patch (gmane.org is down for me currently, hope it returns…):
http://dir.gmane.org/gmane.linux.kernel.efi
http://vger.kernel.org/majordomo-info.html
UEFItool 0.21.2 released
UT 0.21.2 (18 additions and 8 deletions)
– fixed a bug with tailed files extraction and replacing (#35)
– fixed a bug with wrong source of padding after all Intel image regions (#34)
https://github.com/LongSoft/UEFITool
https://github.com/LongSoft/UEFITool/commit/388dd2509358997e81f36f5fea6e406ce202cf1b
QubesOS 3.0 released
Qubes released 3.0 today! Joanna Rutkowska posted a blog entry on it today. This release is dedicated to the memory of Caspar Bowden, a pioneer in privacy. Excerting Joanna’s anouncement of some of 3.0’s features:
Qubes is now based on what we call Hypervisor Abstraction Layer (HAL), which decouples Qubes logic from the underlying hypervisor. This will allow us to easily switch the underlying hypervisors in the near future, perhaps even during the installation time, depending on the user needs (think tradeoffs between hardware compatibility and performance vs. security properties desired, such as e.g. reduction of covert channels between VMs, which might be of importance to some users). More philosophically-wise, this is a nice manifestation of how Qubes OS is really “not yet another virtualization system”, but rather: a user of a virtualization system (such as Xen).
We upgraded from Xen 4.1 to Xen 4.4 (now that was really easy thanks to HAL), which allowed for: 1) better hardware compatibility (e.g. UEFI coming soon in 3.1), 2) better performance (e.g. via Xen’s libvchan that replaced our vchan). Also, new Qubes qrexec framework that has optimized performance for inter-VM services.
We introduced officially supported Debian templates.
We integrated Whonix templates, which optimize Tor workflows for Qubes.
The work on 3.1 is underway, with some features planned, including UEFI support, Live USV edition, and a management/pre-configuration stack.
Full announcement:
http://blog.invisiblethings.org/2015/10/01/qubes-30.html
EFI support ticket:
https://github.com/QubesOS/qubes-issues/issues/794
OpenPOWER architecture platform reference doc available
Stewart Smith posted information about public availability of the OpenPOWER Foundation’s PAPR (Power Architecture Platform Reference) document:
PAPR is the Power Architecture Platform Reference document. It’s a short read at only 890 pages and defines the virtualised environment that guests run in on PowerKVM and PowerVM (i.e. what is referred to as ‘pseries’ platform in the Linux kernel). As part of the OpenPower Foundation, we’re looking at ensuring this is up to date, documents KVM specific things as well as splitting out the bits that are common to OPAL and PAPR into their own documents.
Blog URL:
Document URL:
https://members.openpowerfoundation.org/document/dl/469
The document appears to be dated March 2015. There are lots of ‘firmware’ references in it! I couldn’t find any other information about this document from the openpowerfoundation.org web site. However, there are two other OpenPOWER specs under public review, due mid-month:
http://openpowerfoundation.org/technical/technical-documents-public-review/
European agreement for Absolute and Lenovo
The Canadian ISV/IHV Absolute Software Corporation is working with the European branch of the Chinese OEM Lenovo, to apply CompuTrace — now called Absolute(R) — silicon/firmware-level tracking technology within Europe. Excerpt of press release:
Absolute Collaborates with Lenovo EMEA to Introduce European Factory Activation
Absolute Software Corporation, the industry standard for persistent endpoint security and data risk management solutions, today announced the Company has entered into an agreement with Lenovo EMEA to introduce European factory activation of Absolute Data & Device Security (DDS) (formerly Absolute Computrace). Under this agreement, Lenovo EMEA will incorporate the automated deployment of Absolute DDS, (which will trigger the activation of Persistence technology by Absolute) through Lenovo’s Imaging Technology Center for its European customers. As part of this factory image, customers can opt to load and activate Absolute DDS onto all of their Lenovo devices before shipment.
“Many of our enterprise customers want their Lenovo devices to be protected while in transit. By installing Absolute DDS and activating Persistence technology, our customers will be able to secure these endpoints before they leave the factory,” said Stefan Larsen, EMEA business development manager, Lenovo. “This agreement also allows our customers to reduce the resources spent on configuring and imaging devices, without compromising best-in-class security.”
“Lenovo’s Imaging Technology Center delivers a customized, out-of-the-box experience for its enterprise customers,” said Geoff Haydon, chief executive officer, Absolute. “We are excited to expand our participation in this program to Lenovo customers in Europe. This agreement represents a tremendous opportunity for us to strengthen our position in the region.”
More information:
So, some of Lenovo’s enterprise customers are concerned about new computers being stolen or otherwise manipulated before they leave the factory? Who can attack OEM systems at this point in the system? Is this just an issue for Lenovo, or do other OEM’s enterprise customers also have this kind of concern? How does this new Absolute/Lenovo change impact attacker’s ability to attack system before the hardware comes to Europe and Persistence technology gets activated?
I wish OEMs would give me the OPTION to have this feature, not presume all of their systems are sold to enterprises. I wish someone would maintain a list of modern CompuTrace-free systems, for non-enterprise citizens who don’t want it installed, as it is useless, since CompuTrace is only available to enterprises. It seems that their compatibility lists include nearly all modern OEM systems. Hmm, does Purism or Novena have it? Did the old Thinkpads — that are being refurbished with Libreboot and resold by 2 companies– have it?
microcode update tool for Intel Broadwell systems
There’s a new firmware-related github-hosted project out there, as of the last hour: bdw-ucode-update-tool by Benjamin Woodruff:
Broadwell μcode Update Installer: Intel i5-5675C, i7-5775C, and i7-5700HQ microcode updates extracted from MSI’s UEFI updates, along with a tiny zero-dependency install script for Linux users. Intel’s late Broadwell chips shipped with a whole slew of stability issues, causing Machine Check Exception kernel panics on Linux and BSODs on Windows. While Intel hasn’t directly distributed any new microcode updates since January, they’ve apparently distributed updates to some motherboard vendors. Until Intel updates the downloads on their site, I’ve extracted the updates from MSI’s firmware, using a custom python script. I don’t use Windows however, so I’ve only personally verified the first case. I also don’t have installation instructions for Windows, as I don’t know how to install custom microcode updates on Windows. […]
Interesting solution… IMO, it sounds like Intel should be solving this directly, not forcing end-users obtain it from other IBV’s blobs. 🙂 I wish there was a tool that could tell me if a system had the latest microcode from the vendor, and how I could check if the vendor had updates available.
More information:
https://github.com/bgw/bdw-ucode-update-tool
Firmware Security 
You must be logged in to post a comment.