Kaspersky has a new blog post about the ASUS incident:

Operation ShadowHammer: a high-profile supply chain attack

Google has a new blog post about Javascript and Spectre:

https://v8.dev/blog/spectre

NCC Group has some new research on TrustZone:

The PDFs from the recent UEFI Forum plugfest’s presentations have been uploaded. Hopefully soon the videos will also show up on Youtube.

https://uefi.org/learning_center/presentationsandvideos

ReFirm Labs has an updated version of Centrifuge out, which includes UEFI support. They also have BinWalk Pro.

https://markets.businessinsider.com/news/stocks/refirm-labs-announces-spring-2019-release-of-centrifuge-platform-updates-with-uefi-support-launches-binwalk-pro-1028133957

https://www.prweb.com/releases/refirm_labs_announces_spring_2019_release_of_centrifuge_platform_updates_with_uefi_support_launches_binwalk_pro/prweb16263527.htm

https://www.refirmlabs.com/binwalk-pro/

I just had the first request to remove a blog post about a project of theirs. There are multiple broken links on this blog, where Github projects have disappeared. This is the first blog post that I’ve taken down.

If you don’t want to have people see your project, maybe you should not post it on Github to be publicly-viewable. If you’re concerned about privacy issues about your name being associated with a project, perhaps you should not use your name on that Github account. Many of my posts are based on watching Github for new projects, which is how I found the <now-deleted-project>:

https://github.com/search?o=desc&q=UEFI&s=updated&type=Repositories

This guide takes a look at vetting an embedded system (An ASUS RT-AC51U) using AFL, angr, a cross compiler, and some binary instrumentation without access to the physical device. We’ll go from static firmware to thousands of executions per second of fuzzing on emulated code. (Sorry no 0days in this post). Asus is kind enough to provide the firmware for their devices online. Their firmware is generally a root file system packed into a single file using squashfs. As shown below, binwalk can run through this file system and identify the filesystem for us.[…]

Re: https://firmwaresecurity.com/2019/01/21/blackhat-asia-modern-secure-boot-attacks-bypassing-hardware-root-of-trust-from-software/

Slides are avaiable:

https://github.com/REhints/Publications/blob/f1f305eff156267e194e941d32caf7cc2bfc053b/Conferences/Bypassing%20Hardware%20Root%20of%20Trust/BHASIA2019_matrosov_final.pdf

A new Rust library:

https://github.com/mizkichan/uefi-unifont

Relies on:

A new Rust-based tool:

https://github.com/MOZGIII/rebootinto

[…]Last week at Google Cloud Next ’19, we announced the general availability of Shielded VM—virtual machine instances that are hardened with a set of easily configurable security features that assure you that when your VM boots, it’s running a verified bootloader and kernel. Shielded VM can help you protect your system from attack vectors like: Malicious guest OS firmware, including malicious UEFI extensions,
Boot and kernel vulnerabilities in guest OS, and Malicious insiders within your organization.[…]

https://cloud.google.com/blog/products/identity-security/shielded-vm-your-ticket-to-guarding-against-rootkits-and-exfiltration

https://cloud.google.com/shielded-vm/

Defence Industries has an article that describes Secure Boot, Trusted Boot, Measured Boot, and Verified Boot. And Intel Boot Guard. It seems they didn’t cover the latter one, but the article was focused on Windows systems…

https://www.defence-industries.com/articles/explanation-of-secure-system-startup-processes-concurrent-technologies-processor-boards

https://github.com/jslegendre/ACPIPatcher

https://arxiv.org/abs/1904.05572

René Mayrhofer, Jeffrey Vander Stoep, Chad Brubaker, Nick Kralevich
(Submitted on 11 Apr 2019)

Android is the most widely deployed end-user focused operating system. With its growing set of use cases encompassing communication, navigation, media consumption, entertainment, finance, health, and access to sensors, actuators, cameras, or microphones, its underlying security model needs to address a host of practical threats in a wide variety of scenarios while being useful to non-security experts. The model needs to strike a difficult balance between security, privacy, and usability for end users, assurances for app developers, and system performance under tight hardware constraints. While many of the underlying design principles have implicitly informed the overall system architecture, access control mechanisms, and mitigation techniques, the Android security model has previously not been formally published. This paper aims to both document the abstract model and discuss its implications. Based on a definition of the threat model and Android ecosystem context in which it operates, we analyze how the different security measures in past and current Android implementations work together to mitigate these threats. There are some special cases in applying the security model, and we discuss such deliberate deviations from the abstract model.

=

Here’s a new project on Github, an Insyde-specific Linux-specific
driver. I asked Insyde about this, and apparently it is an out-of-date
driver, and they should have a statement about a newer version in the
near future.

https://github.com/tomreyn/isfl

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 reverse engineering project, Project Ortega, began in December 2017 and involved reverse engineering proprietary firmware to determine what any open source replacement would need to do. Mainly this involved producing a reverse engineered C codebase from the disassembly of proprietary firmware, then producing a natural-language specification for others to reimplement; the actual reversed code itself is not published. In other words, this is a clean-room reverse engineering workflow. The reverse engineering side is now pretty much done and availability of open source firmware for the BCM5719 is waiting on the completion of a reimplementation effort (thanks to Evan Lojewski). This is a cleanroom implementation and doesn’t share any code with Project Ortega or the proprietary firmware, but is produced using the human-readable specifications delivered by Project Ortega. Once this is delivered, it will be possible to use Raptor’s POWER9 systems with purely 100% free, open source firmware. As far as I am aware, there is no other machine in the same performance class which can make such a claim. The rest of this article describes the entire journey of getting to this point, and briefly discusses the innards of the BCM5719.[…]

https://www.devever.net/~hl/ortega

https://github.com/hlandau/ortega

https://tsc.intel.com/c

I wish I had more information, but nope. Please leave a Comment if you have something. As to whether this is a joke or not, I’ve heard one Intel engineer talk — with a straight face — about using blockchain-based tech to help secure firmware blobs’ supply chain a few months ago, maybe this was what they were talking about… For better or worse, I ignore anything that mentions blockchain technology, maybe I’m missing out in a bunch of legitimate things?

https://www.intel.com/content/www/us/en/security/blockchain-overview.html

efi-loadopt: A tiny utility crate — Rust code — with a sole purpose of deserializing UEFI Boot Manager’s Load Options (EFI_LOAD_OPTION) – see 3.1.3 at UEFI spec.

https://github.com/MOZGIII/efi-loadopt