Xavier1994 has created a new UEFI security tool!!
If you can’t read Python or Chinese, you’ll need some help understanding what it does. 🙂
Category: Uncategorized
Open Hardware Summit announced
The first Open Source Hardware Europe Summit has been announced!
What: Open Hardware Europe Summit
When: 19.-29. May 2016
Where: Vienna, Austria
http://openhardware.me/
during the
http://codedcultures.com/
More information:
http://lists.oshwa.org/pipermail/discuss/2016-April/001736.html
IBM research on USB eavesdropping attacks
IBM Research has new research on USB attacks and an “UScramBle” implementation for Linux:
USB Eavesdropping Attacks
Attacks that leverage USB as an attack vector are gaining popularity. While attention has so far focused on attacks that either exploit the host’s USB stack or its unrestricted device privileges, it is not necessary to compromise the host to mount an attack over USB. This paper describes and implements a USB sniffing attack. In this attack a USB device passively eavesdrops on all communications from the host to other devices, without being situated on the physical path between the host and the victim device. To prevent this attack, we present UScramBle, a lightweight encryption solution which can be transparently used, with no setup or intervention from the user. Our prototype implementation of UScramBle for the Linux kernel […]
Intel acquires Yogitech for IoT security
As reported by multiple news sites, Intel has acquired Yogitech, to help with IoT security:
https://newsroom.intel.com/editorials/blog-intel-acquires-yogitech-for-iot-functional-safety/
http://www.zdnet.com/article/intel-buys-yogitech-aims-to-bolster-iot-safety-efforts/
Quanta LTE routers vulnerable
Pierre Kim has a new detailed blog post on Quanta router firmware vulnerabilities:
Multiple vulnerabilities found in Quanta LTE routers (backdoor, backdoor accounts, RCE, weak WPS …)
Quanta Computer Incorporated is a Taiwan-based manufacturer of electronic hardware. It is the largest manufacturer of notebook computers in the world. The Quanta LTE QDH Router device is a LTE router / access point overall badly designed with a lot of vulnerabilities. It’s available in a number of countries to provide Internet with a LTE network. The summary of the vulnerabilities is: [list of about 20 items omitted for space]. A personal point of view: at best, the vulnerabilites are due to incompetence; at worst, it is a deliberate act of security sabotage from the vendor. Not all the vulnerabilities found have been disclosed in this advisory. Only the significant ones are shown. Note: This firmware is being used by other Quanta CPEs. From the /usr/www/js/ui/qdisplay.js file, the vulnerable firmware seems to be used in several routers: [list omitted]. The routers are still on sale and used in several countries. Due to lack of communication of the vendor, the specific list of affected countries is unknown. However, we assume the affected firmware is used at least in some Arabic speaking countries as the Help files are written in English, French, Chinese and Arabic (See http://192.168.1.1/help_ar.html). Due to lack of security patches provided by the vendor, the vulnerabilities will remain unpatched. Details […]
FreeBSD 10.3 released
Marius Strobl announced FreeSD 10.3, with changes to UEFI, amongst other updates and new features. An excerpt of the highlights listed in the announcement:
* The UEFI boot loader received several improvements: It now follows /boot/config and /boot.config files, multi-device boot support works and command line arguments are parsed. Additionally, its framebuffer driver has been enhanced with GOP (Graphics Output Protocol) and UGA (Universal Graphics Adapter) handling, allowing to set the current graphics mode on systems using one of these methods. Moreover, ZFS boot capability has been added to the UEFI boot loader, including support for multiple ZFS Boot Environments (BEs), e. g. those provided by sysutils/beadm.
* The bsdinstall(8) utility has been updated to allow for creating root-on-ZFS installations on UEFI-based systems in automatic mode.
* The mkimg(1) utility has been updated to support NTFS file systems in both GPT and MBR partitioning schemes.
* And much more …
More information:
https://www.FreeBSD.org/releases/10.3R/relnotes.html
https://www.FreeBSD.org/releases/10.3R/errata.html
https://www.FreeBSD.org/releases/10.3R/signatures.html
https://www.FreeBSD.org/releases/10.3R/announce.asc
ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/
ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.3-RELEASE/
https://www.FreeBSD.org/releases/10.3R/installation.html
https://lists.freebsd.org/pipermail/freebsd-announce/2016-April/001713.html
https://www.freebsd.org/releases/10.3R/relnotes.html#kernel-bugfix
Android Nexus 5 Monitor Mode
Vincent recently tweeted this pointer to a blog from Frédéric Basse, talking about Android Nexus 5’s Monitor Mode:
Analysis of Nexus 5 Monitor mode
This article will first describe how to locate the Monitor mode code in Nexus 5 firmware (hammerhead-ktu84p-factory-35ea0277, bootloader-hammerhead-hhz11k : c32f8bec310c659c1296739b00c6a8ac). Then, we will try to understand what it does (its functionalities). Finally, you will have to find bugs by yourself because I didn’t find any…so far !
[…]
Full article:
http://www.fredericb.info/2014/12/analysis-of-nexus-5-monitor-mode.html?spref=tw
Vincent on UEFI firmware updates
Vincent Zimmer of Intel (and UEFI Forum) has a blog post about the recent Open Compute Project Summit, discussing UEFI and firmware updates, especially network-based updates, and the issues involved. There’s a presentation (with slides and video) from the OCP Summit to watch, blog has multiple pointers.
ARM Security Extensions
There’s a new blog post on the ARM blog, talking about Security Extensions and Privilege Levels in ARMv8-M Cortex systems:
Security Extensions and Privilege Levels
[…]
ARMv8-M introduces Security Extensions that provide hardware features for more secure devices. The Security Extensions allow the protection of trusted and system resources from untrusted handlers and applications. They can be executed without the additional software sandboxing overheads of reprogramming the MPU. The Security Extensions collaborates with the associated software model to provide a mechanism to restrict access to system resources and processes through well-defined interfaces similar to system calls, thereby ensuring a higher level of protection and also offering an implicit privilege-stack. […]
LUV 2.0 released!
The Intel LUV team, at least including: Gayatri Kammela (12), Megha Dey (12), Naresh Bhat (1), and Ricardo Neri (46) have released 2.0 of LUV, the Linux UEFI Validation Project.
These are the highlights of the release:
*Different types of image available (i386 and x86_x64)
*Logging and debugging via network (or serial)
*Tests for persistent memory (NVDIMM)
*Support for i386
*Booting LUV via network (PXE, HTTP boot later)
*Miscellaneous updates (BITS perf improvements, Linux 4.4 kernel, …)
*Dropped support for fido (focus is on Jethro)
*Known issues and limitations (Debugging works only over Ethernet, not WiFi, …)
Read the full announcement, there are pages of details not included here.
One new feature is i386 support. LUV 1.x was x64-centric, now we hopefully also use LUV 2.0 for testing x86 systems! But signed shim is still only available for 64-bit, so Secure Boot is not enabled for 32-bit support [yet?]. Quoting the release notes: “At the last minute we faced a kernel issue when booting on a i386-based system. We are debugging. Once this is cleared, a bootable image will be uploaded (issue #76 on [3])”
Full announcement:
https://lists.01.org/pipermail/luv/2016-April/001035.html
https://download.01.org/linux-uefi-validation/v2.0
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc
[1]. https://github.com/01org/luv-yocto/tree/master/meta-luv
[2]. https://github.com/pmem/ndctl
[3]. https://github.com/01org/luv-yocto
William Leara introduction to SCTs
William Leara has a new blog post giving an introduction to the UEFI SCTs, Self-Certification Tests:
http://www.basicinputoutput.com/2016/03/introduction-to-uefi-self-certification.html
These tests are fully-available to UEFI Forum members, and snapshots of it are given to the public every few quarters. I wish there was more security testing in them, not just protocol adherance testing.
TPM2 ACPI table
Finnbarr P. Murphy has a new blog post about viewing the TPM2 ACPI table:
[…] Why two definitions for the same header? The current ACPI standard defines the table description header as follows: […]
I believe that the second definition is closer to the intent of the ACPI. For a more detailed look at the actual TPM2 support in the EDK2, read the Intel white paper entitled A Tour Beyond BIOS with the UEFI TPM2 Support in EDKII by Jiewen Yao and Vincent J. Zimmer. […]
http://blog.fpmurphy.com/2016/03/examining-tpm2-acpi-table.html
Xen patches for AMD FIP/FCS/FDP/FDS/FOP instruction leak
The Xen security team posted an updated security advisory with a workaround to an AMD CPU issue. Heavily-edited announcement follows, see the OSS-security list post for the full announcement and patches:
Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172
version 3
broken AMD FPU FIP/FDP/FOP leak workaround
There is a workaround in Xen to deal with the fact that AMD CPUs don’t load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS), and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending unmasked exception. (See XSA-52.) However, this workaround does not cover all possible input cases. This is because writes to the hardware FSW.ES bit, which the current workaround is based on, are ignored; instead, the CPU calculates FSW.ES from the pending exception and exception mask bits. Xen therefore needs to do the same. Note that part of said workaround was the subject of XSA-52. This can leak register contents from one guest to another. The registers in question are the FPU instruction and data pointers and opcode.
A malicious domain is able to obtain address space usage and timing information, about another domain, at a fairly low rate. The leaked address information might be used to help defeat address space randomisation in order to enable another attack. The leaked address and timing information forms a low-bandwidth covert channel which might be used to gain information about the operation of a target guest. The affected FPU facility would not normally be used by cryptographic operations, as it does not provide cryptographically-relevant SIMD functions. It appears to us very unlikely that the leak might directly compromise sensitive information such as cryptographic keys, although (without knowledge of the guest software) this cannot be ruled out. (This is notwithstanding the contrary statement in `Impact’ in XSA-52.)
Xen versions 4.0 and onwards are vulnerable. Any kind of guest can exploit the vulnerability. The vulnerability is exposed only on AMD x86 systems. Intel and ARM systems do not expose this vulnerability. Both PV and HVM guests are affected. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. On Xen versions 4.3 and earlier, turning off XSAVE support via the “no-xsave” hypervisor command line option will avoid the vulnerability. On Xen versions 4.4 and onwards there is no other known mitigation.
This issue was discovered by Jan Beulich from SUSE.
http://xenbits.xen.org/xsa/advisory-172.html
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2016-3159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3158
UEFI Forum Spring plugfest presentations uploaded
The UEFI Forum is concluding their Spring plugfest in Taipei. They’ve uploaded the 8 presentations to uefi.org:
UEFI Forum Update – Dong Wei (HPE)
UEFI Forum ARM Update – Mitch Ishihara (ARM)
Improving Platform Security with UEFI Secure Boot and UEFI Variables – David Chen (Insyde Software)
The TPM 2.0 specs are here, now what? – Dick Wilkins (Phoenix Technologies)
Standardized Firmware for ARMv8 based Volume Servers – Jonathan Zhang (Cavium Inc.) and Robert Hsu (AMI)
Microsoft Update for Windows Security – Jackie Chang, Tony Lin (Microsoft Corporation)
UEFI Port to RISC-V Processor Architecture – Abner Chang (HPE)
Tianocore 2016 Updates – Tony Mangefeste (Intel)
http://uefi.org/learning_center/presentationsandvideos
and look for the videos to start showing up here:
https://www.youtube.com/user/UEFIForum
Debian plans for UEFI Secure Boot
Steve McIntyre of the Debian Project posted a message to the Debian-EFI list, with plans for getting Debian to support UEFI Secure Boot. A summary of the main steps:
1. Generate a key and an EV code-signing cert, submit to Microsoft
2. dak changes to support upload and signing of EFI executables
3. Prepare and upload a package of the ‘shim’ EFI boot loader
4. Updates for other core packages to add signed versions
* grub2
* linux
* fwupdate
* ???
5. Minor tweaks to other places to make use of the signed packages
* d-i
* debian-cd
* debian-live
* ???
Full status message and more information:
https://wiki.debian.org/SecureBoot
https://lists.debian.org/debian-efi/2016/04/msg00002.html
Intel patch to Linux kernel for ACPI overlays
Octavian Purdila of Intel has posted a 10-part patch to the Linux-(ACPI,EFI,I2C,SPI,Kernel) lists, adding “ACPI Overlays” to the Linux kernel:
This patch set enables custom ACPI board configuration by adding mechanisms in the Linux kernel for loading user defined SSDTs. In order to support ACPI open-ended hardware configurations we need a way to augment the ACPI configuration provided by the firmware image. A common example is connecting sensors on I2C / SPI buses on development boards. Although this can be accomplished by creating a kernel platform driver or recompiling the firmware image with updated ACPI tables, neither is practical: the former proliferates board specific kernel code while the latter requires access to firmware tools which are often not publicly available. Because ACPI supports external references in AML code a more practical way to augment firmware ACPI configuration is by dynamically loading user defined SSDT tables that contain the board specific information.
This patch sets provides three methods for loading custom SSDTs:
1) From an EFI variable: This is the preferred method, when EFI is supported on the platform, because it allows a persistent, OS independent way of storing and updating the user defined SSDTs. There is also work underway to implement EFI support for loading user defined SSDTs and using this method will make it easier to convert to the EFI loading mechanism when that will arrive.
2) From the first uncompressed initrd (similar with the override functionality): This is useful when EFI is not supported on the platform and when it is not possible to defer the loading to userspace.
3) From userspace via configfs: This is useful when we want to defer the operation to userspace for platform detection, loading the SSDTs from a custom partition, etc.
Octavian Purdila (10):
kernel: add TAINT_OVERLAY_ACPI_TABLE
acpi: install SSDT tables from initrd
acpi: add support for ACPI reconfiguration notifiers
acpi: fix enumeration (visited) flags for bus rescans
i2c: add support for ACPI reconfigure notifications
spi: add support for ACPI reconfigure notifications
efi: load SSTDs from EFI variables
configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions
acpi: add support for configfs
acpi: add support for loading SSDTs via configfs
Documentation/ABI/testing/configfs-acpi | 23 +++++
Documentation/acpi/ssdt-overlays.txt | 174 ++++++++++++++++++++++++++++++++
Documentation/kernel-parameters.txt | 7 ++
Documentation/oops-tracing.txt | 2 +
Documentation/sysctl/kernel.txt | 1 +
MAINTAINERS | 1 +
drivers/acpi/Kconfig | 9 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 72 +++++++++++++
drivers/acpi/configfs.c | 143 ++++++++++++++++++++++++++
drivers/acpi/internal.h | 3 +
drivers/acpi/scan.c | 73 +++++++++++++-
drivers/acpi/sysfs.c | 6 +-
drivers/firmware/efi/efi.c | 107 ++++++++++++++++++++
drivers/i2c/i2c-core.c | 38 ++++++-
drivers/spi/spi.c | 36 ++++++-
include/acpi/acpi_bus.h | 8 ++
include/linux/configfs.h | 4 +-
include/linux/kernel.h | 1 +
kernel/panic.c | 2 +
20 files changed, 699 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/configfs-acpi
create mode 100644 Documentation/acpi/ssdt-overlays.txt
create mode 100644 drivers/acpi/configfs.c
For more information, see the full patch on the above-listed mailing lists.
MSI releases modular system: The One
Today, April First, MSI has announced a new device, “The One”, which sounds awesome! I’d post more info on it, but I’m busy trying to figure out how to buy one… 🙂
http://www.tomshardware.com/news/msi-modular-motherboard,31532.html
https://www.msi.com/Motherboard/The-One.html#hero-overview
Intel releases STM
Vincent has a new blog post about Intel STM being released to the public!
OpenBSD 5.9 released
OpenBSD 5.9 has been released. There are a few firmware-related improvements in this release, such as:
* New efifb(4) driver for EFI frame buffer.
* amd64 can now boot from 32 bit and 64 bit EFI.
* Initial support for hardware reduced ACPI added to acpi(4).
* New asmc(4) driver for the Apple System Management Controller.
* New dwiic(4) driver for the Synopsys DesignWare I2C controller.
* Support for ACPI configured SD host controllers has been added to sdhc(4).
* The sdmmc(4) driver now supports sector mode for eMMC devices, such as those found on some BeagleBone Black boards.
* The ipmi(4) driver now supports OpenIPMI compatible character device.
Full announcement:
http://www.openbsd.org/59.html
Intel Firmware Engine 2.0 released
https://twitter.com/Intel_UEFI/status/715195675261009920
Intel has released the 2.0.0 version of the Firmware Engine for Microsoft* Windows 7/8/8.1/10. Includes program and MinnowBoard Max and MinnowBoard Turbot platform support.
http://firmware.intel.com/learn/intel-firmware-engine/downloads
Firmware Security 
You must be logged in to post a comment.