This note explains how to switch a legacy boot Debian/Ubuntu system into a UEFI boot system. Typical use cases: 1) switch a legacy boot installation into an UEFI one, 2) reinstall a broken UEFI boot loader on Debian 7, Debian 8 or Debian 9.[…]
Author: hucktech
Debian 10 released, with Secure Boot
[…]The UEFI (“Unified Extensible Firmware Interface”) support first introduced in Debian 7 (code name “wheezy”) continues to be greatly improved in Debian 10 “buster”. Secure Boot support is included in this release for amd64, i386 and arm64 architectures and should work out of the box on most Secure Boot-enabled machines. This means users should no longer need to disable Secure Boot support in the firmware configuration.[…]
https://lists.debian.org/msgid-search/bcd827ac-a3cf-6695-9a21-9b9d148aed76@debian.org
Hmm, above URL generates an error on the resulting Debian.org-hosted page, but the MARC and Mail-Archive links work, the latter rendered better. The Debian page also wrongly points to the now-dead GMane site, two Debian bugs that need to get fixed…
Which smart bulbs should you buy (from a security perspective)
Matthew has a new blog post about smart lightbulb security:
People keep asking me which smart bulbs they should buy. It’s a great question! As someone who has, for some reason, ended up spending a bunch of time reverse engineering various types of lightbulb, I’m probably a reasonable person to ask. So. There are four primary communications mechanisms for bulbs: wifi, bluetooth, zigbee and zwave. There’s basically zero compelling reasons to care about zwave, so I’m not going to.[…]
QEMU gets new machine type: microvm
Re: https://firmwaresecurity.com/2018/11/27/amazon-com-announces-firecracker-a-secure-open-source-microvm/ and https://firmwaresecurity.com/2018/06/12/nemu-fork-of-qemu-by-intel/
Microvm is a machine type inspired by both NEMU and Firecracker, and constructed after the machine model implemented by the latter. It’s main purpose is providing users a KVM-only machine type with fast boot times, minimal attack surface (measured as the number of IO ports and MMIO regions exposed to the Guest) and small footprint (specially when combined with the ongoing QEMU modularization effort). Normally, other than the device support provided by KVM itself, microvm only supports virtio-mmio devices. Microvm also includes a legacy mode, which adds an ISA bus with a 16550A serial port, useful for being able to see the early boot kernel messages.[…]
https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06211.html
New blog: Modern C++ for Safety Critical Systems
The Advanced Threats Evolution: REsearchers Arm Race, slides online
Navigating Tianocore EDK Releases
William Leara has a new blog post talking about the UEFI Tianocore development environment, “EDK”, including historical “EDK I” up to current branches. The Tianocore build environment is nonstandard, this background would be helpful to newcomers.
https://www.basicinputoutput.com/2019/07/navigating-edk-releases.html
Adventures in reverse engineering Broadcom NIC firmware
For some time now, I’ve been reverse engineering the firmware of the Broadcom BCM5719 Ethernet NIC chip, so that open source firmware can be produced for it. The BCM5719 is a PCIe chip which provides up to four Gigabit Ethernet ports, and is mainly intended for use in server applications. It can be used with the Linux “tg3” driver and is approximately the twelfth generation of chips in a long line of Ethernet NICs ultimately descended from the Tigon range of NICs made by Alteon, the IP of which got transferred to Broadcom at some point.[…]
https://github.com/hlandau/ortega
New UEFI/Tianocore documents
https://legacy.gitbook.com/book/edk2-docs/edk-ii-secure-coding-guide/details
https://legacy.gitbook.com/book/edk2-docs/edk-ii-secure-code-review-guide/details
https://legacy.gitbook.com/book/edk2-docs/understanding-the-uefi-secure-boot-chain/details
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
BlackHat: Behind the scenes of iOS and Mac Security
Ivan Krstić, Head of Apple Security Engineering and Architecture at Apple, will be speaking at BlackHat on the T2 security processor:
[…]We will discuss three iOS and Mac security topics in unprecedented technical detail, offering the first public discussion of several key technologies new to iOS 13 and the Mac.[…]The T2 Security Chip brought powerful secure boot capabilities to the Mac. Comprehensively securing the boot process required protections against sophisticated direct memory access (DMA) attacks at every point, even in the presence of arbitrary Option ROM firmware. We will walk through the boot sequence of a Mac with the T2 Security Chip and explain key attacks and defenses at each step, including two industry-first firmware security technologies that have not been publicly discussed before.[…]
https://www.blackhat.com/us-19/briefings/schedule/#behind-the-scenes-of-ios-and-mac-security-17220
NIST Releases Report on Managing IoT Risks (NISTIR 8228)
The National Institute of Standards and Technology (NIST) has released the Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks report. The publication—the first in a planned series on IoT—aims to help federal agencies and other organizations manage the cybersecurity and privacy risks associated with individual IoT devices.[…]
https://www.us-cert.gov/ncas/current-activity/2019/06/26/nist-releases-report-managing-iot-risks
AMD-SEV: Platform DH key recovery via invalid curve attack (CVE-2019-9836)
[…]Through ongoing collaboration with industry researchers AMD became aware that, if using the user-selectable AMD secure encryption feature on a virtual machine running the Linux operating system, an encryption key could be compromised by manipulating the encryption technology’s behavior.[…]
This vulnerability was discovered and reported to AMD by Cfir Cohen of the
Google Cloud security team.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836
edk2-gdb-server: Open Source EDK2 GDB Server
For a long time Intel has offered a “freeware” (not open source) solution to debug UEFI with a 2-system solution, one running either Linux/GDB or Windows/Windbg:
Last updated in 2017, it used to work on the old TunnelMountain desktop systems, I’ve been meaning to see if it works on MinnowBoard2 systems. And this is Intel-centric (and I presume it may also work on AMD), but, I’m not aware of ARM — nor UEFI Forum’s Tianocore — having a similar offering, which I’d like to be able to use on a UEFI-based Rasberry Pi. HOWEVER… I just noticed this, which came out LAST YEAR, somehow I missed it, an open source solution!!
This is a open code replacement for Intel’s binary only GDB server that comes as part of the ‘Intel UEFI Development Kit Debugger Tool’. Since that tool is Intel x86/64 Linux/Windows only this allows more flexibility. E.g. you can run this on any ARM based SoC with python3 and a USB OTG port connected directly to your target via a USB2.0 EHCI Debug port using the Linux USB OTG Debug Port gadget. You can then connect to that target remotely from your build box, etc. This also allows you to tweak the debugger itself. I’ve already added some additional functionality here to assist when using SourceLevelDebugPkg on non-EDK2 (i.e. no source available) firmwares such as AMI Aptio IV.
https://github.com/night199uk/edk2-gdb-server
Now it just needs also add LLDB support (especially for the Clang-centric HBFA branch)… 🙂 Given this is open source, unlike the Intel solution, this is a possiblity!
A Comprehensive Formal Security Analysis and Revision of the Two-phase Key Exchange Primitive of TPM 2.0
Qianying Zhang, Shijun Zhao, Zhiping Shi, Yong Guan, Guohui Wang
(Submitted on 16 Jun 2019)
The Trusted Platform Module (TPM) version 2.0, which has been demonstrated as a key element of Industry 4.0, presents a two-phase key exchange primitive for secure communications between Industry 4.0 components. The key exchange primitive of TPM 2.0 can be used to implement three widely-standardized authenticated key exchange protocols: the Full Unified Model, the Full MQV, and the SM2 key exchange protocols. However, vulnerabilities have been found in all of these protocols. Fortunately, it seems that the protections offered by TPM chips can mitigate these vulnerabilities. In this paper, we present a security model which captures TPM's protections on keys and protocols' computation environments and in which multiple protocols can be analyzed in a unified way. Based on the unified security model, we give the first formal security analysis of the key exchange primitive of TPM 2.0, and the analysis results show that, with the help of hardware protections of TPM chips, the key exchange primitive indeed satisfies the well-defined security property of our security model, but unfortunately under some impractical limiting conditions, which would prevent the application of the key exchange primitive in real-world networks. To make TPM 2.0 applicable to real-world networks, we present a revision of the key exchange primitive of TPM 2.0, which can keep secure without the limiting conditions. We give a rigorous analysis of our revision, and the results show that our revision achieves not only the basic security property of modern AKE security models but also some further security properties. https://arxiv.org/abs/1906.06653
FreeBSD: call for testing: UEFI HTTPS boot
The FreeBSD project needs some testing help:
https://lists.freebsd.org/pipermail/freebsd-current/2019-June/073593.html
QuarksLab: LLDBagility: practical macOS kernel debugging
Date Tue 18 June 2019 By Francesco Cagnin Category macOS. Tags macOS XNU kernel hypervisor debugging FDP LLDBagility
This is the second of two blog posts about macOS kernel debugging. In the previous post, we defined most of the terminology used in both articles, described how kernel debugging is implemented for the macOS kernel and discussed the limitations of the available tools; here, we present LLDBagility, our solution for an easier and more functional macOS debugging experience.[…]
https://blog.quarkslab.com/lldbagility-practical-macos-kernel-debugging.html
macOSEfiMount: mounts ESP
“A quick macOS-EFI-Mounter for those who are too lazy to work with Terminal-Commands.”
NSA document updated, Boot Security Modes and Recommendations
I not positive, but I think that one of the NSA’s guidance documents has been recently updated:
Click to access csi-boot-security-modes-and-recommendations.pdf
BOOT SECURITY MODES AND RECOMMENDATIONS
Modern computing platforms provide a variety of boot options. The security implications, advantages, and disadvantages are rarely identified in documentation. Some configuration options, such as Secure Boot and Trusted Platform Module (TPM) 1 may appear redundant despite serving complementary roles. Six different configurations are compared below. Recommendations for different use cases are presented at the end of this document.
NSA adding STM support to coreboot
GRUB2 patch lists …and preOS network security
I was just watching this presentation on GRUB from FOSDEM 2019:
https://fosdem.org/2019/schedule/event/grub_upstream_and_distros/
and it mentions that Fedora has a large number of downstream patches. Before this, I didn’t realize how MANY PATCHES that GRUB2 has, in various distros. For example
https://src.fedoraproject.org/rpms/grub2/tree/master
https://build.opensuse.org/package/show/openSUSE:Factory/grub2
https://sources.debian.org/patches/grub2/2.04%7Erc1-2/
So I need to stop thinking all GRUBS are alike.
I also note this recent Debian bug report, which suggests some GRUB network security issues (which do not appear to be Debian-centric):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930217
I hope GRUB’s network issues can be improved, maybe the additional focus of firmware security researchers?
Firmware Security 
You must be logged in to post a comment.