simple-bootsplash
displays the UEFI Logo during initramfs stage
depends on fbv, xrandr, awk, lzop
Author: hucktech
UEFIoverclockMonitor.efi: Monitor TSC, default and overclocked CPU frequencies
Written in FASM.
Measure TSC, default and overclocked CPU frequencies.
https://github.com/manusov/UEFIoverclockMonitor
UEFI topics in Paul’s Security Weekly 550-551
Episode 550 has AMI, and 551 has Phoenix
https://securityweekly.com/subscribe/
https://wiki.securityweekly.com/Episode550
https://wiki.securityweekly.com/Episode551
Sorry can’t find URL to the 551 video, leaving that as ‘an exercise for the reader’. 🙂
https://securityweekly.com/subscribe/
OpenXT: adding anti-evil maid support, using UEFI and Xen in place of TXT
[…]In this PR OpenXT is extended to allow booting under UEFI while maintaining current security properties.,Changes to Measured Launch,,Booting OpenXT under UEFI introduces significant changes to the Measured Launch system of OpenXT by switching to the use of SRTM PCRs. Performing DRTM with TXT when booting under UEFI is not supported but can be implemented at a later date. OpenXT under UEFI relies on the shim EFI application to perform necessary measurements of critical boot components of OpenXT. OpenXT’s static PCR list is extended to include PCR4, PCR5, PCR7 and PCR8. Specific to OpenXT’s context, PCR4 holds the measurements of the shim, Xen and the dom0 kernel while PCR8 holds the measurements of openxt.cfg, the dom0 initrd image and the XSM policy. Any change in these components, selecting a boot entry other then the one used when Sealing took place and/or booting any application before the shim will result in the Measured Launch system tripping.[…]
https://github.com/OpenXT/xenclient-oe/pull/828
MicroPython for UEFI
https://twitter.com/DevZoneBlog/status/971860129946611712
[…]my team investigated several options to support Python 3.x in UEFI boot services. Because firmware is a constrained environment compared to OS runtime, we evaluated porting MicroPython to UEFI. MicroPython is a Python 3 variant designed for microcontrollers, with memory and size optimizations that make it ideal for pre-OS applications. […] Supporting Python 3.x & MicroPython in open source creates new opportunities for the TianoCore community to validate robust firmware solutions.[…]
https://software.intel.com/en-us/blogs/2018/03/08/implementing-micropython-as-a-uefi-test-framework
Deconstructing the Xbox Boot ROM
[…]I recently wanted to do a bit of reverse-engineering and so I decided to deconstruct the boot ROM to better understand the Xbox security system. In this article, I will present the high-level boot flow of the system, the disassembled ROM code, pseudocode for the disassembly, along with some thoughts. It should be known that there is essentially no new information presented in this article. The many flaws of the Xbox security system have already been well documented years ago by some really smart people. That said, I am not aware of a similar disassembly of the ROM, so perhaps this article will serve as a guide for others who are interested.[…]
https://mborgerson.com/deconstructing-the-xbox-boot-rom/
LLVM 6.0.0 Released, includuing Spectre variant2 mitigations
This release is the result of the community’s work over the past six months, including: retpoline Spectre variant 2 mitigation, significantly improved CodeView debug info for Windows, GlobalISel by default for AArch64 at -O0, improved scheduling on several x86 micro-architectures, Clang defaults to -std=gnu++14 instead of -std=gnu++98, support for some upcoming C++2a features, improved optimizations, new compiler warnings, many bug fixes, and more.
https://llvm.org/releases/download.html#6.0.0
https://llvm.org/releases/6.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/lld/docs/ReleaseNotes.html
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-announce
Emulating Exynos 4210 BootROM in QEMU
[…]This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.[…]
Nicely-written. Includes coverage of U-Boot and U-Boot Secure Boot.
https://www.fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html#emulating-exynos-4210-bootrom-in-qemu
https://github.com/frederic/qemu-exynos-bootrom
PS: I just learned about this blog. Catching up, there are some interesting older posts, eg:
Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM
https://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html#amlogic-s905-soc-bypassing-not-so
Debian and FWTS
Re: https://firmwaresecurity.com/2017/11/28/fwts-added-to-debian/
It looks like Canonical’s FWTS is having a hard time staying in Debian repos. 😦
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748783
UefiDiskBenchmark.efi: Mass storage benchmark for UEFI (written in FASM)
UefiDiskBenchmark: Mass storage benchmark, based on EFI_BLOCK_IO_PROTOCOL EFI Byte Code (EBC) application.
Output parameters and flags:
“#” Device number in the list
“Revision” Revision of UEFI API EFI_BLOCK_IO_PROTOCOL.
“Media” Media ID
“RM” Removable Media flag, for example CD or USB flash
“MP” Media Present
“LP” Logical Partition
“RO” Read Only
“WC” Write Cache
“Block” Block size, bytes
“Align” Required alignment for memory buffer, bytes
“Size” Available size of mass storage device
Known bug: maximum 10 devices supported, include aliases.
https://github.com/manusov/UEFIdiskBenchmark
UefiUsbScan.efi: Scan USB host controllers and connections, written in FASM
UefiUsbScan: Scan for USB host controllers and connections, current version use direct PCI/MMIO hardware access. Only xHCI controllers supported yet, not supports UHCI, OHCI, EHCI.
docker-edk2-uefi: Docker container for Tianocore EDK2 dev
Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh
UEFI EDKII Development Environment
This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]
https://hub.docker.com/r/geneerik/docker-edk2-uefi/
Somewhat related, I also found these UEFI/Docker options:
https://hub.docker.com/r/rojuinex/edk2-uefi/~/dockerfile/
https://hub.docker.com/r/michas2/edk2-test/~/dockerfile/
PS: Wondering what he’s been messing with UEFI on:
US Homeland Security: Threat to Network Infrastructure Devices
https://twitter.com/RidT/status/970877316602658816
https://twitter.com/RidT/status/970880435411709952
Threat to Network Infrastructure Devices
The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations
Click to access ar-16-20173.pdf
Kotlin-native-UEFI: A UEFI Application made by kotlin-native
It appears that there *might* be some Kotlin support for UEFI target. There is a new project that hints of this, but project is too new, no docs/comments, looks to not be ready for use yet.
https://github.com/youta1119/kotlin-native-uefi
I suspect this is part of the same person’s KotlinOS project:
https://github.com/youta1119/koslin-os
Qubes: Anti Evil Maid (AEM): improved TPM support
Anti Evil Maid is an implementation of a TPM-based dynamic (Intel TXT) trusted boot for dracut/initramfs-based OSes (Fedora, Qubes, etc.) with a primary goal to prevent Evil Maid attacks. In short, AEM relies on TPM and a feature found in Intel’s vPro CPUs (TXT) to detect tampering of various boot components.
Even if you don’t use Qubes, this is a good read:
[…]To recap — you need to fully trust:
* CPU (Intel, since we’re depending on TXT)
+ sometimes over-optimizes for performance at the cost of security, see eg. Meltdown/Spectre, cache attacks against SGX enclaves, …
* TPM (various vendors)
+ few known attacks sniffing and injecting commands on the LPC bus; differential power analysis; buggy RSA key generation code
+ note that any potential TPM exploits (should) have no means of compromising your system directly — a TPM under attacker’s control can only be used to hide the fact that a compromise has occurred (ie. defeating the whole AEM feature)
* BIOS (a few vendors)
+ it’s full of holes!
* that the attacker cannot get physically inside your laptop without you noticing (see the glitter hint above)
[…]
https://github.com/QubesOS/qubes-antievilmaid/commit/da6c1bacfe5f8864e08efcf7903f9867d40629b3
https://github.com/QubesOS/qubes-antievilmaid
https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
Embedded Rust Book seeks firmware contributors
https://github.com/rust-lang-nursery/embedded-wg/issues/56
https://github.com/rust-lang-nursery/embedded-wg
Note that ‘firmware’ does not appear to be in scope of this book, which is sad. In the current Rust future, we’ll still have to use C for firmware, then Rust for the OS-level embedded code.
Richard Wilkins of Phoenix on UEFI-based IoT security (and rant on firmware diversity)
Richard Wilkins of Phoenix Technologies has an article in Embedded Computing about UEFI-based IoT security:
[…]This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.[…]
http://www.embedded-computing.com/articles/firmware-security-for-iot-devices
PS: RANT… for some reason, one sentence jumped out at me:
“So why isn’t everyone using UEFI firmware? If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it?”
I think the answer: UEFI is *A* solution, there are other solutions. Coreboot with Heads is another solution. Coreboot with Verified Boot is another solution. Using TXT and TPM measurements are other layers. Hypervisors/TEEs/SEEs are another layer. Separate security processors are another way. What is the right way, why isn’t everyone using one way? While I am a UEFI Forum member, I don’t think UEFI everyone should be using it. I welcome firmware diversity. 🙂 IMO, there are multiple implementations of signed code, signed updates, and a signed boot-up process, controlled by multiple (not a single) organization. I’m still hoping to see some professor gets a grad student to write a report doing a proper comparision of the various modern firmware security implementations’ strengths, so someone can start to make a reasonale decision as to which firmware security architecture is the solution for them.
Alex’s OffensiveCon slides uploaded
“My @offensive_con slides released! Include all 010 templates for Intel ACM and Boot Guard (KM + IBBM). All these details been REconstructed from AMI FW. Discovered few Intel Boot Guard bypasses: 2 SW + 1 HW. Never underestimate RE in your Threat Model!!”
Betraying the BIOS: Where the Guardians of the BIOS are Failing
For UEFI firmware, the barbarians are at the gate — and the gate is open. On the one hand, well-intentioned researchers are increasingly active in the UEFI security space; on the other hand, so are attackers. Information about UEFI implants — by HackingTeam and state-sponsored actors alike — hints at the magnitude of the problem, but are these isolated incidents, or are they indicative of a more dire lapse in security? Just how breachable is the BIOS? In this presentation, I’ll explain UEFI security from the competing perspectives of attacker and defender. I’ll cover topics including how hardware vendors have left SMM and SPI flash memory wide open to rootkits; how UEFI rootkits work, how technologies such as Intel Boot Guard and BIOS Guard (and the separate Authenticated Code Module CPU) aim to kill them; and weaknesses in these protective technologies. There are few public details; most of this information has been extracted by reverse engineering. This talk is a revisited version of the Black Hat Vegas 2017 research with new details about Intel BIOS Guard and Intel ACM’s including new vulnerabilities.
https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS
https://www.offensivecon.org/agenda/
Click to access Offensivecon_18%5Bv2.0%5D.pdf
010 editor templates:
https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS/010%20templates
https://www.sweetscape.com/010editor/
X41 D-Sec GmbH browser security whitepaper: WebUSB, WebBluetooth, WebSMM
This white paper provides a technical comparison of the security features and attack surface of Google Chrome, Microsoft Edge, and Internet Explorer. We aim to identify which browser provides the highest level of security in common enterprise usage scenarios, and show how differences in design and implementation of various security technologies in modern web browsers might affect their security. Comparisons are done using a qualitative approach since many issues regarding browser security cannot easily be quantified. We focus on the weaknesses of different mitigations and hardening features and take an attacker’s point of view. This should give the reader an impression about how easy or hard it is to attack a certain browser. The analysis has been sponsored by Google. X41 D-Sec GmbH accepted this sponsorship on the condition that Google would not interfere with our testing methodology or control the content of our paper. We are aware that we could unconsciously be biased to produce results favorable to our sponsor, and have attempted to eliminate this by being as transparent as possible about our decision-making processes and testing methodologies.
Click to access X41-Browser-Security-White-Paper.pdf
https://www.x41-dsec.de/#about
https://www.x41-dsec.de/security/report/whitepaper/2017/09/18/whitepaper-x41-browser-security/
OpticSpy: A tool to explore optical data transmissions and covert channels
https://www.crowdsupply.com/grand-idea-studio/opticspy
Uses & Application Ideas:
Search for optical covert channels that may exist in modern devices
Add data exfiltration/transfer functionality into a project
Capture/decode/demodulate IR signals from remote controls
Discover Li-Fi networks or Visible Light Communication (VLC) systems
Firmware Security 
You must be logged in to post a comment.