Lanner: Security-enhanced BIOS

Hmm, today I learned about Lanner Electronics, in Taiwan, who ships a “secure BIOS” product.

Lanner witnesses the growing awareness of potential security risk for the pre-OS level and offers advnaced security features integrated within our exclusive BIOS designs. Lanner’s BIOS firmware offerring including market-proven technologies such as Secure Boot and Intel Boot Guard technology deliver solid commitments for the shield protection against malware, uncertified sequences and other named cyber threats. For specific applications, Lanner’s security-enhanced BIOS can be customized with the services covering DMI data pool, customer logo and password protection.

http://www.lannerinc.com/products/firmware-and-software/securityenhanced-bios#

The page has some download links, last updated in 2018, The doc links work, but the link to the BIOS download doesn’t work (at least for me).

Intel releases 6 security advisories

Intel has released 6 new security advisories:

RWC3 Advisory, INTEL-SA-00341
MPSS Advisory, INTEL-SA-00340
RWC2 Advisory, INTEL-SA-00339
SGX SDK Advisory, INTEL-SA-00336
CSME
Advisory, INTEL-SA-00307
Renesas Electronics USB 3.0 Driver Advisory, INTEL-SA-00273

https://www.intel.com/content/www/us/en/security-center/default.html

Rust-based UEFI test framework

From Bret Barkelew of Microsoft:

What’s better than UnitTests almost being ready for deployment in TianoCore? How about using those UnitTests to validate a native Rust port of one of our VarCheck libs? Building upon Jiewen’s work (among others) I’ve finally managed to prototype a port of the UefiVariablePolicyLib to Rust, and have shown that it can build as part of our normal CI process and run the same UnitTests that are used for the C version…

https://edk2.groups.io/g/devel/message/53252

https://github.com/corthon/edk2-staging/tree/rust_and_tests

IETF: Remote Attestation Procedures Architecture

In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer’s trustworthiness, and a way to appraise such evidence. The evidence is typically a set of claims about its software and hardware platform. This document describes an architecture for such remote attestation procedures (RATS).

https://tools.ietf.org/html/draft-ietf-rats-architecture-01

Discussion on RATS: https://mailarchive.ietf.org/arch/browse/rats/

BGRTInjector: Customize boot logo without modifying UEFI

With BGRT hacking, users can update the OEM boot logo graphic with their own. Apparently this is very popular, there’re a few BGRT posts on this blog that’re consistantly highly-viewed. Here’s a new BGRT tool:

Changes the boot screen image on a UEFI computer. This is a remake of Ben Wang’s windows_custom_loader.efi, the source code of which is long lost. Several incompatiblities with non-Apple UEFI implementations are addressed, and you can now replace the logo without recompiling the whole program.

[…]

Security: Loading untrusted image into memory is dangerous. BGRTInjector only reads the image file from the volume (partition) it lives in, and ESP partition is usually protected under end-user accessible operating systems, so we can assume only a system administrator or a evil maid can load an evil image. Additionally BGRTInjector does some basic sanity checks on the image file, but it is still prone to specially crafted evil images. If you are not signing your own Secure Boot keys, using BGRTInjector means Secure Boot will be unavailable. In Windows loader mode, BGRTInjector does not verify the authenticity of the target bootloader.

https://github.com/Jamesits/BGRTInjector

DevOps for Embedded

Paul’s first post in a long while – I stumbled on this series of articles which are excellent if you happen to be developing and deploying embedded firmware.

Part 1: https://www.stupid-projects.com/devops-for-embedded-part-1/

Part 2: https://www.stupid-projects.com/devops-for-embedded-part-2/

Part 3: https://www.stupid-projects.com/devops-for-embedded-part-3/

Also if your job still has some hardware for which you’re somehow responsible (ie: you’re not 100% on someone else’s cloud service!) these are worth a read. While your employer might just be a consumer of the end product – shipped versions of firmware on hardware that you buy / already own, it is worth understanding what is involved in making that firmware and shipping updates.!

hwsec_lecture_notes: Lecture notes for the Hardware and Embedded Systems Security lecture

These are my notes for an introductory lecture covering efficient implementation as well as implementation attacks (side channels, faults). It is by far not completely covering this much more complex field, but should give a decent overview and pointers for further reading.

https://github.com/david-oswald/hwsec_lecture_notes

CacheOut: Intel Processors Data Leakage Advisory (INTEL-SA-00329, CVE-2020-0548, CVE-2020-0549)

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00329.html

https://software.intel.com/security-software-guidance/software-guidance

Acknowledgements: Intel would like to thank the following individuals for finding, reporting and coordinating these vulnerabilities to us. Intel thanks TU Graz and KU Leuven for disclosure of CVE-2020-0549. Graz University of Technology: Moritz Lipp, Michael Schwarz, Daniel Gruss. KU Leuven: Jo Van Bulck. Intel thanks VU Amsterdam, for disclosure of CVE-2020-0548 and CVE-2020-0549. VUSec group at VU Amsterdam: Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida. Researchers from TU Graz and Ku Leuven provided Intel with a Proof of Concept (POC) in May 2019 and researchers from VU Amsterdam provided Proof of Concept (POC) in October 2019. Intel subsequently confirmed each submission demonstrates CVE-2020-0549 individually.

https://cacheoutattack.com/

CacheOut Logo

Linux-Surface: ACPIDumps: ACPI dumps from various Microsoft Surface devices

There’s a project which collects ACPI tables from Microsoft Surface devices. It appears to be a Linux distro for Surface, unclear how they’re being used.

https://github.com/linux-surface/acpidumps

See-also:
https://github.com/linux-surface/surface-ipts-firmware
https://github.com/linux-surface/surface-firmware

I wish OEMs had hashes for the ACPI tables they ship. I wish FWTS or CHIPSEC or someone else had some security-centric test tool that’d examine these ACPI tables for malware. There is this tool:
https://firmwaresecurity.com/2019/11/09/acpi-rootkit-scan-volatility-plugin-to-detect-acpi-rootkits/
And there’s also a collection of ACPI tables on:
https://firmwaresecurity.com/2019/12/31/acpi-tables-collection-of-acpi-tables-generated-by-linux-hardware-databases-hw-probe-tool/

Ticket #19263: Steps to hack a VirtualBox BIOS

There’s a new VirtualBox bug report, about ability of attacker to replace the Vbox firmware. The bug report had a link to a zipped DOCX file. It appears, from Oracle’s response, that they consider firmware root-of-trust a future enhancement, not a current bug. Virtualized firmware is interesting for attackers with OS root access: in that the firmware is more accessable, it is merely files on a disk, instead of flash-based, not just the files on the ESP.

This issue was initially reported to the security team, but after some discussion it was mentioned that I should open this in the public bug tracking system (seems strange to me, but…). Just for reference, follow the final conclusion from the security team:

“Admin rights give a user the power to do anything on the system. An “evil admin” is more a social component of this bug than a product’s security abilities (or its lack thereof). However, we get your point and think that the “validation/check” proposed by you may be an enhancement feature in the product. Since our team (SecAlert) only deals with security vulnerabilities in the product, we will not be able to help you on this further. You could log an enhancement request on VirtualBox’s public bug tracker: https://www.virtualbox.org/wiki/Bugtracker

https://www.virtualbox.org/ticket/19263

https://www.virtualbox.org/attachment/ticket/19263/Steps%20to%20hack%20a%20VirtualBox%20BIOS_v2.zip

Mortar: Framework to join Linux's physical security bricks (Secureboot, TPM keys, and LUKS)

Mortar is an attempt to take the headache and fragmented processes out of joining Secureboot, TPM keys, and LUKS. Through the “Mortar Model” everything on disk that is used is either encrypted, signed, or hashed. The TPM is used to effectively whitelist certain boot states. Disks are automatically unlocked once the boot sequence has been validated. This makes full-disk encryption dramatically more convenient for end-users and viable on servers (as they can automatically unlock on reboot). Mortar aims to support both TPM 1.2 (via its own implementation) and TPM 2 (via clevis). LUKS1 and LUKS2 are both supported by intelligently selecting different implementation paths based on your current setup. Mortar aims to be distribution agnostic. Initial developments are on Arch Linux and Debian Linux.

https://github.com/noahbliss/mortar

Revsersing UEFI SMM drives on Lenovo ThinkPads

Written by Bruno – 2020-01-14

Last summer, I finally started reversing the firmware of a computer I had since quite some times: a Lenovo ThinkPad P51s.[…]The problem of calling this function from SMM is that the EFI_BOOT_SERVICES is a table of services located in the normal world. An attacker can simply change the address in the EFI_BOOT_SERVICES table and get an arbitrary call. This type of vulnerability is usually named a callout of SMRAM and they are basically equivalent to calling userland code from kernelland.[…]

https://www.synacktiv.com/posts/exploit/through-the-smm-class-and-a-vulnerability-found-there.html

Intel releases 6 new security advisories

Intel has released 6 new security advisories:

SNMP Subagent Stand-Alone Advisory for Windows INTEL-SA-00300
Chipset Device Software Advisory INTEL-SA-00306
RWC 3 for Windows Advisory INTEL-SA-00308
Processor Graphics Advisory INTEL-SA-00314
VTune Amplifier for Windows Advisory INTEL-SA-00325
DAAL Advisory INTEL-SA-00332

And a blog post about it:

https://www.intel.com/content/www/us/en/security-center/default.html

https://www.us-cert.gov/ncas/current-activity/2020/01/14/intel-releases-security-updates

Haybale: Symbolic execution of LLVM IR

haybale is a general-purpose symbolic execution engine written in Rust. It operates on LLVM IR, which allows it to analyze programs written in C/C++, Rust, Swift, or any other language which compiles to LLVM IR. In this way, it may be compared to KLEE, as it has similar goals, except that haybale is written in Rust and makes some different design decisions. That said, haybale makes no claim of being at feature parity with KLEE.

https://github.com/PLSysSec/haybale