https://software.intel.com/en-us/blogs/2018/03/08/implementing-micropython-as-a-uefi-test-framework
Category: Uncategorized
AMI response to the CTS-Labs AMDflaws.com advisory
PCILeech 3.1 released!
Exploitation on ARM-based Systems
Exploitation on ARM-based Systems: These are the slides of the arm exploitation training we gave at Troopers18
https://github.com/sashs/arm_exploitation
https://scoding.de/troopers18-exploitation-on-arm-based-systems
Intel publishes PCIe Device Security Enhancements spec
PCIe Device Security Enhancements Specification
PCI Express (PCIe) Devices may be composed of hardware (immutable) and firmware (immutable and mutable) components. Presently, Vendor ID/Device ID/Revision ID registers convey the hardware identify of a PCIe* Device and there is no defined mechanism to convey the firmware identity of a PCIe Device. In addition to the Device identity, PCIe specification defines various types of capability structures to convey PCIe Device features capabilities. Both the Device Identity and capability can be spoofed and used maliciously by an advanced adversary. This specification introduces the notion of PCIe* Device Firmware Measurement, a method of exposing the identity of Device firmware. The Device Firmware Measurement mechanism used in isolation, however, is subject to supply chain attacks such as counterfeiting and can also be spoofed by an advanced adversary. Additionally this specification introduces the notion of PCIe Device Authentication, which uses public key cryptography to defend against such attacks and to provide higher assurance about the hardware and firmware identities and capabilities. PCIe Device Authentication adapts the USB Authentication mechanism to PCIe—the new elements are the specific PCIe register interface and the associated mechanisms, plus some details that are necessarily specific to PCIe. PCIe Device Authentication result can be used in various scenarios such as: 1) a data center administrator can ensure all PCIe Devices are running appropriate firmware versions 2) system software can ensure a trusted Device is plugged in before enabling the PCIe Address Translation Services (ATS) for the Device. PCIe Device Authentication provides platforms with a way to make trust decisions about specific Devices. This in turn provides value to Device vendors because the Authentication feature is itself a valuable Device feature, and supports the detection of counterfeit and potentially malicious Devices. This specification details the requirements, interface and protocol for PCIe Device Firmware Measurement and PCIe Device Authentication. It also provides general guidelines for implementing these technologies in practice.
https://www.intel.com/content/www/us/en/io/pci-express/pcie-device-security-enhancements-spec.html
sgx-papers: A cureted list of system papers using/about Intel SGX
A cureted list of system papers using/about Intel SGX. I’ll try to keep this list updated. I gladly accept PRs.
https://github.com/vschiavoni/sgx-papers
Linux ACPI Time and Alarm Device (TAD) driver
Rafael J. Wysocki of Intel submitted a patch to Linux ACPI for a ACPI Time and Alarm Device (TAD) driver:
Introduce a driver for the ACPI Time and Alarm Device (TAD) based on Section 9.18 of ACPI 6.2. This driver only supports the system wakeup capabilities of the TAD which are mandatory. Support for the RTC capabilities of the TAD will be added to it in the future. This driver is entirely sysfs-based. It provides attributes (under the TAD platform device) to allow user space to manage the AC and DC wakeup timers of the TAD: set and read their values, set and check their expire timer wake policies, check and clear their status and check the capabilities of the TAD reported by AML. The DC timer attributes are only present if the TAD supports a separate DC alarm timer. The wakeup events handling and power management of the TAD is expected to be taken care of by the ACPI PM domain attached to its platform device.
The ACPI Time and Alarm (TAD) device is an alternative to the Real Time Clock (RTC). Its wake timers allow the system to transition from the S3 (or optionally S4/S5) state to S0 state after a time period elapses. In comparison with the RTC Alarm, the TAD provides a larger scale of flexibility in the wake timers. The time capabilities of the TAD maintain the time of day information across platform power transitions, and keep track of time even when the platform is turned off.
More info: linux-acpi list archives, http://vger.kernel.org/majordomo-info.html
https://patchwork.kernel.org/patch/10287043/
Documentation/ABI/testing/sysfs-devices-platform-ACPI-TAD
HardwareCon 2018: hardware startup conference
Linux Foundation has an article on HardwareCon by the event founder:
https://www.linux.com/blog/event/hardware-con/2018/3/hardwarecon-slope-enlightenment
https://www.hardwarecon.com/home
There is one talk that has ‘security’ in it’s title: ” Cloud Platforms and the Product Management Lifecycle: Cloud Costs, Data Analytics and Security”. I guess this is better than previous hardware startup events, which were 100% security-free. Still, there is not enough security content in these hardware startup events. 😦
Open Source Firmware Conference 2018, September, Germany
Mission: Change the way of firmware development, collaborate with others and share knowledge. Closed source firmware development has been the de-facto standard for the electronics industry since its inception. This didn’t change even as open-source took off in other areas. Now, with changing use cases and tighter security requirements, it’s more important than ever to take open-source firmware development to the next level.
Intel: hardware-based protection coming later this year
[…]These changes will begin with our next-generation Intel® Xeon® Scalable processors (code-named Cascade Lake) as well as 8th Generation Intel® Core™ processors expected to ship in the second half of 2018.[…]
https://newsroom.intel.com/editorials/advancing-security-silicon-level/
https://newsroom.intel.com/news-releases/security-first-pledge/
alt archive for edk2-devel mailing list
Multiple URLs on this blog point to the Tianocore EDK2 development mailing list for more information.
https://lists.01.org/mailman/listinfo/edk2-devel
However, there’s a few broken links on the archive page for that list.
Here is more info on some changes to the list archives:
https://lists.01.org/pipermail/edk2-devel/2016-July/000000.html
Here is another source of archives of the list:
https://www.mail-archive.com/edk2-devel@lists.01.org/info.html
Thanks to the edk2-devel-owners for a pointer to this alt archive site.
ARM Dynamic Tables Framework
ARM has submitted a patch to UEFI’s Tianocore which adds a “Dynamic Tables” framework that abstracts ACPI amongst other things… Readme excerpt of patch below:
This patch introduces a branch for implementing Dynamic Tables Framework.
To reduce the amount of effort required in porting firmware to new platforms, we propose this “Dynamic Tables” framework. The aim is to provide an example implementation capable of generating the firmware tables from an external source. This is potentially a management node, either local or remote, or, where suitable, a file that might be generated from the system construction. This initial “proof of concept” release does not fully implement that – the configuration is held in local UEFI modules.
The dynamic tables framework is designed to generate standardised firmware tables that describe the hardware information at run-time. A goal of standardised firmware is to have a common firmware for a platform capable of booting both Windows and Linux operating systems.
Traditionally the firmware tables are handcrafted using ACPI Source Language (ASL), Table Definition Language (TDL) and C-code. This approach can be error prone and involves time consuming debugging. In addition, it may be desirable to configure platform hardware at runtime such as: configuring the number of cores available for use by the OS, or turning SoC features ON or OFF.
The dynamic tables framework simplifies this by providing a set of standard table generators, that are implemented as libraries. These generators query a platform specific component, the ‘Configuration Manager’, to collate the information required for generating the tables at run-time.
The framework also provides the ability to implement custom/OEM generators; thereby facilitating support for custom tables. The custom generators can also utilize the existing standard generators and override any functionality if needed.
The framework currently implements a set of standard ACPI table generators for ARM architecture, that can generate Server Base Boot Requirement (SBBR) compliant tables. Although, the set of standard generators implement the functionality required for ARM architecture; the framework is extensible, and support for other architectures can be added easily.
The framework currently supports the following table generators for ARM:
* DBG2 – Debug Port Table 2
* DSDT – Differentiated system description table. This is essentially a RAW table generator.
* FADT – Fixed ACPI Description Table
* GTDT – Generic Timer Description Table
* IORT – IO Remapping Table
* MADT – Multiple APIC Description Table
* MCFG – PCI Express memory mapped configuration space base address Description Table
* SPCR – Serial Port Console Redirection Table
* SSDT – Secondary System Description Table. This is essentially a RAW table generator.
[…]Please create a branch called ‘dynamictables’ in edk2-staging.[…]
More info: see the “[PATCH] Branch to implement Dynamic Tables Framework” thread on the edk2-devel list by Sami Mujawar. And look for above branch to be created.
Hmm, it appears the links to the archives on the URL provided in the mailing list posts is not valid:
https://lists.01.org/mailman/listinfo/edk2-devel
V1 from Oct2017:
TPM Genie: I2C bus interposer for discrete TPMs
[…]This tool was primarily developed to manipulate TPM response packets in order to trigger parsing bugs in the host-side TPM drivers. These bugs can be found in the Linux kernel, as well as a variety of bootloaders such as Tboot and Tianocore EDKII. Leveraging these vulnerabilities, an attacker may be able to compromise a host machine after it had successfully booted up into a fully measured and attested state. TPM Genie is also able to man-in-the-middle PCR Extend operations, yielding the ability to undermine most of the stated purposes of a TPM: measured boot, remote attestation, and sealed storage. Normally, attestation or unsealing should fail if an attacker modifies any component of the measured boot process. However, the interposer makes it is possible to spoof these measurements by replacing the the payload associated with the PCR Extend ordinal as it is transmitted across the bus. Additionally, TPM Genie can weaken the Linux hardware random number generator. On some systems, /dev/hwrng is tied into the Trusted Platform Module such that all reads on the character device will actually result in the TPM chip providing the random bytes. In this way, the interposer can subtly alter the platform’s RNG which may impair cryptographic operations on the host. Finally, TPM Genie can be used to simply sniff the bus to capture secrets, such as session data associated with the OIAP and OSAP commands. And with nominal additional engineering effort, TPM Genie should be able to spoof the Endorsement Key, gain control of the AuthData and recalculate the Authorization Session HMAC. (More info on that in my whitepaper. I promise I’ll implement that soon).[…]
https://github.com/nccgroup/TPMGenie
Scaleway: Open Source BIOS at Scale
Open Source Bios at Scale
Julien Viard de Galbert
At Scaleway we started to design our servers with the ARM C1. Later we switched to a x86 architecture to provide the C2 and Dedibox SC2016. In both ARM and x86, a BIOS is required to start the server. BIOS software got many legacy and backward compatible software to ensure a reliable behavior accross many boards. I was in charge of the BIOS development for our new generation of x86 servers. This article presents technical choices we used during our development.[…]
https://blog.online.net/2018/03/15/open-source-bios-at-scale/
Microsoft: Mitigating speculative execution side channel hardware vulnerabilities
SOF Project and Project ACRN
https://www.phoronix.com/scan.php?page=news_item&px=Sound-Open-Firmware
https://01.org/blogs/2018/introducing-acrn-and-sound-open-firmware
SOFProject: Sound Open Firmware is an open source audio DSP firmware and SDK that provides audio firmware infrastructure and development tools for developers who are interested in audio or signal processing on modern DSPs
ACRN: a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform
list of 29 USB-based attacks
https://twitter.com/campuscodi/status/973723887891464192
USB-based attacks
Nir Nissim, Ran Yahalom, Yuval Elovici
Attackers increasingly take advantage of innocent users who tend to use USB peripherals casually, assuming these peripherals are benign when in fact they may carry an embedded malicious payload that can be used to launch attacks. In recent years, USB peripherals have become an attractive tool for launching cyber-attacks. In this survey, we review 29 different USB-based attacks and utilize our new taxonomy to classify them into four major categories. These attacks target both individuals and organizations; utilize widely used USB peripherals, such as keyboards, mice, flash drives, smartphones etc. For each attack, we address the objective it achieves and identify the associated and vulnerable USB peripherals and hardware.
https://doi.org/10.1016/j.cose.2017.08.002
https://www.sciencedirect.com/science/article/pii/S0167404817301578
https://www.bleepingcomputer.com/news/security/heres-a-list-of-29-different-types-of-usb-attacks/
more on AMDflaws.com
AMD vulns: RYZENFALL, masterkey, Fallout, Chimera
Microsoft updates: Windows OEM security guidance
Standards for a highly secure Windows 10 device
03/07/2018
These standards are for general purpose laptops, tablets, 2-in-1’s, mobile workstations, and desktops. This topic applies specifically and uniquely for Windows 10 version 1709, Fall Creators Update. If you are a decision maker purchasing new devices and you want to enable the best possible security configuration, your device should meet or exceed these standards. Beyond the hardware and firmware configurations outlined below, Microsoft recommends running Windows 10 S for security. Windows 10 S is a specific configuration of Windows 10 Pro that offers a familiar Windows experience that’s streamlined for security and performance. Windows 10 S provides the best of the cloud and full featured apps, and is designed for modern devices. Windows Defender is always on and always up-to-date.[…]
https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure
Firmware Security 
You must be logged in to post a comment.