This is a new product support document from Apple:
This article contains references for key product certifications, cryptographic validations, and security guidance for Secure Enclave Processor (SEP): Secure Key Store. Contact us at firstname.lastname@example.org if you have any questions.[…]
Richard Hughes has two new blog posts, one with an update to LVFS, and one on how it parses firmware ‘blobs’:
[…]Specifically, firmware is now being checked for expired Authenticode certificates which expired more than 3 years before the upload date of the firmware. The LVFS is also looking for test signing certificates that really should not exist in production firmware. All existing firmware on the LVFS is being tested, and the test backlog should be complete by this afternoon. All test failures are currently waivable.[…]
Teddy Reed of Facebook has a new blog post on using Intel DCI, UEFI Tool, Intel System Studio, and other tools:
TL;DR, if you have a newer CPU & chipset you can purchase a $15 off-the-shelf cable and single-step your hardware threads. The cable is a USB 3.0 debugging cable; and is similar to an ethernet crossover cable in the sense that the internal wiring is crossed. Be careful with this cable as unsupported machines will have undefined behavior due to the electronics of USB.
SpecFuzz is the first tool that enables dynamic testing for speculative execution vulnerabilities (e.g., Spectre). The key is the concept of speculation exposure: The program is instrumented to simulate speculative execution in software by forcefully executing the code paths that could be triggered due to mispredictions, thereby making the speculative memory accesses visible to integrity checkers. Combined with the conventional fuzzing techniques, speculation exposure enables more precise identification of potential vulnerabilities compared to the state-of-the-art static analyzers. Our prototype for detecting Spectre V1 vulnerabilities successfully identifies all known variations of Spectre V1, and dramatically reduces the overheads compared to the deployed Speculative Load Hardening mitigation across the evaluated applications, reducing the amount of necessary instrumentation by 99% in some of them.
Instead of the ‘disable it and presume everything is fine’ approach, I’ve been looking around for something like an Intel AMT/ME Security Best Practices document, to help sysadmins (and end users) secure that processor as much as possible. A friend at Intel found this, closest-fit document, with AMT configuration information, that is interesting to read. First released in 2015, last updated Janurary 2019.
Deployment GUIDE Intel® Setup and Configuration Software (Intel® SCS)
This deployment guide is an instructional document providing simple steps to enable the discovery, configuration and maintenance of Intel® Active Management Technology (Intel® AMT) platforms using Intel® Setup and Configuration Software (Intel® SCS). Intel® AMT operates independently of the CPU and the firmware is delivered in an un-configured state. Intel® SCS is provided by Intel to support the setup and configuration of the firmware for the target environment and enable remote, out-of-band access to Intel® AMT features. Guidance is provided to enable a baseline implementation of Intel® AMT and identifies common configuration settings to support an enterprise deployment that take advantage of the manageability and security features available on platforms that support Intel® AMT and Intel® Standard Manageability. After configuration, Intel® AMT systems can be remotely managed by products, toolsets and solutions including Microsoft System Center Configuration Manager, Microsoft PowerShell, and Intel® Manageability Commander.
Pitchfork is a static analysis tool, built on angr, which performs speculative symbolic execution. That is, it not only executes the “correct” or “sequential” paths of a program, but also the “mispredicted” or “speculative” paths, subject to some speculation window size. Pitchfork finds paths where secret data is used in either address calculations or branch conditions (and thus leaked), even speculatively – these paths represent Spectre vulnerabilities. Pitchfork covers Spectre v1, Spectre v1.1, and theoretically Spectre v4 (the code for v4 is here, but hasn’t been tested).
PSPTool is a Swiss Army knife for dealing with firmware of the AMD Secure Processor (formerly known as Platform Security Processor or PSP). It locates AMD firmware inside UEFI images as part of BIOS updates targeting AMD platforms. It is based on reverse-engineering efforts of AMD’s proprietary filesystem used to pack firmware blobs into UEFI Firmware Images. These are usually 16MB in size and can be conveniently parsed by UEFITool. However, all binary blobs by AMD are located in padding volumes unparsable by UEFITool. PSPTool favourably works with UEFI images as obtained through BIOS updates.
VxHunter: A ToolSet for VxWorks Based Embedded Device Analyses. The firmware analyze tool is plugins written in Python, mainly used for analyze firmware loading address, fix function name with symbol table and etc.[…]
By: Sujit Kumar Muduli Pramod Subramanyan, Sayak Ray
An important primitive in ensuring security of modern systems-on-chip designs are protocols for authenticated firmware load. These loaders read a firmware binary image from an untrusted input device, authenticate the image using cryptography and load the image into memory for execution if authentication succeeds. While these protocols are an essential part of the hardware root of trust in almost all modern computing devices, verification techniques for reasoning about end-to-end security of these protocols do not exist. In this paper, we take a step toward addressing this gap by introducing a system model, adversary model and end-to-end security property that enable reasoning about the security of authenticated load protocols. We then present a decomposition of the security property into two simpler hyperproperties. This decomposition enables more scalable verification. Experiments on a protocol model demonstrate viability of the methodology.
Good new, the long awaited UEFI-based boot support for Azure virtual machine is now available in preview. The UEFI-based boot support was added to on-premises Hyper-V since Windows Server 2012 R2, quite long time ago and since then we have been waiting for this on Azure. The new generation (aka generation 2) of Azure virtual machine introduces this support alongside of: […] and off course, support of SecureBoot and vTPM (virtual trusted platform module). Unfortunately, the support for VHDX is still not there. […] Complete list of support and limitations is available here https://docs.microsoft.com/en-us/azure/virtual-machines/windows/generation-2 (side note, it seems the documentation is not completely correct at the time of writing as SecureBoot and vTPM are still listed as unsupported).[…]