The UEFI Forum has specified the date/location of the next plugfest:
Event Date: April 8-12, 2019
Location: Bellevue, WA
Intel security guidance: Host Firmware Speculative Execution Side Channel Mitigation
[…]This provides specific guidance for firmware based upon the EFI Developer Kit II (EDKII) and coreboot. Because this document deals with host firmware internal requirements, it is not intended to provide side channel mitigation guidance for general application developers.
Scope: This addresses bare-metal firmware runtime risks and mitigation suggestions for the bounds check bypass, branch target injection, rogue data cache load, rogue system register read, and speculative store bypass side channel methods. Our examples and context are primarily focused on ring 0 firmware runtimes (for example: EFI Developer Kit II, PI SMM, and coreboot SMM). Other firmware execution environments are out of scope.[…]
more info:
https://software.intel.com/security-software-guidance/software-guidance
Rendered Insecure: GPU Side Channel Attacks are Practical
Graphics Processing Units (GPUs) are commonly integrated with computing devices to enhance the performance and capabilities of graphical workloads. In addition, they are increasingly being integrated in data centers and clouds such that they can be used to accelerate data intensive workloads. Under a number of scenarios the GPU can be shared between multiple applications at a fine granularity allowing a spy application to monitor side channels and attempt to infer the behavior of the victim. For example, OpenGL and WebGL send workloads to the GPU at the granularity of a frame, allowing an attacker to interleave the use of the GPU to measure the side-effects of the victim computation through performance counters or other resource tracking APIs. We demonstrate the vulnerability using two applications. First, we show that an OpenGL based spy can fingerprint websites accurately, track user activities within the website, and even infer the keystroke timings for a password text box with high accuracy. The second application demonstrates how a CUDA spy application can derive the internal parameters of a neural network model being used by another CUDA application, illustrating these threats on the cloud. To counter these attacks, the paper suggests mitigations based on limiting the rate of the calls, or limiting the granularity of the returned information.
A Systematic Evaluation of Transient Execution Attacks and Defenses
Modern processor optimizations such as branch prediction and out-of-order execution are crucial for performance. Recent research on transient execution attacks including Spectre and Meltdown showed, however, that exception or branch misprediction events may leave secret-dependent traces in the CPU’s microarchitectural state. This observation led to a proliferation of new Spectre and Meltdown attack variants and even more ad-hoc defenses (e.g., microcode and software patches). Unfortunately, both the industry and academia are now focusing on finding efficient defenses that mostly address only one specific variant or exploitation methodology. This is highly problematic, as the state-of-the-art provides only limited insight on residual attack surface and the completeness of the proposed defenses.
In this paper, we present a sound and extensible systematization of transient execution attacks. Our systematization uncovers 7 (new) transient execution attacks that have been overlooked and not been investigated so far. This includes 2 new Meltdown variants: Meltdown-PK on Intel, and Meltdown-BR on Intel and AMD. It also includes 5 new Spectre mistraining strategies. We evaluate all 7 attacks in proof-of-concept implementations on 3 major processor vendors (Intel, AMD, ARM). Our systematization does not only yield a complete picture of the attack surface, but also allows a systematic evaluation of defenses. Through this systematic evaluation, we discover that we can still mount transient execution attacks that are supposed to be mitigated by rolled out patches.
An introduction to Udev: The Linux subsystem for managing device events
https://twitter.com/opensourceway/status/1062526031905652736
Linux subsystem for managing device events
Create a script that triggers your computer to do a specific action when a specific device is plugged in.
13 Nov 2018
Seth Kenlon (Red Hat)
Udev is the Linux subsystem that supplies your computer with device events. In plain English, that means it’s the code that detects when you have things plugged into your computer, like a network card, external hard drives (including USB thumb drives), mouses, keyboards, joysticks and gamepads, DVD-ROM drives, and so on. That makes it a potentially useful utility, and it’s well-enough exposed that a standard user can manually script it to do things like performing certain tasks when a certain hard drive is plugged in. This article teaches you how to create a udev script triggered by some udev event, such as plugging in a specific thumb drive. Once you understand the process for working with udev, you can use it to do all manner of things, like loading a specific driver when a gamepad is attached, or performing an automatic backup when you attach your backup drive.[…]
https://opensource.com/article/18/11/udev?sc_cid=70160000001273HAAQ
A Deeper Look Into Reversing the Toshiba FlashAir SD Card
OpenBSD/arm64 on QEMU with networking
https://twitter.com/0x16h/status/1062387471500148740
With the increasing popularity of ARM64/AArch64 systems, from the Raspberry Pi 3 and PINE64 to Fujitsu’s move away from SPARC64 supercomputers, there hasn’t been a better time to get started with learning this architecture. I wanted to make a start to an Aarch64 assembly language tutorial but didn’t have access to my RPi3, so I looked into the state of QEMU’s emulation. I didn’t need RPi3-specific hardware – which is just as well as I can’t remember off-hand how the bootcode and start.elf crap would work with QEMU – anyway, I opted for a generic device using Linaro’s EDK2 UEFI firmware. The first pre-built EDK2 binary I downloaded wouldn’t play nicely with the OpenBSD kernel so I grabbed a release mentioned by the FreeBSD team – which worked.[…]
https://cryogenix.net/OpenBSD_arm64_qemu.html
libcyres: Interface to Cyres, to be consumed by U-Boot, OP-TEE, and UEFI. Contains routines to manipulate and pass certificate chains between boot stages.
Jordan Rhee of Microsoft has created a new project. All the documentation was used for the Title.
https://github.com/jordanrh1/libcyres
Now I’m wondering what Project Cyres is.
Intel ‘patch Tuesday’: 8 new security advisories
INTEL-SA-00199
Intel® RAID Web Console 3 Cross-site Scripting Vulnerability Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00199.html
INTEL-SA-00198
Intel® Ready Mode Technology File Permissions Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00198.html
INTEL-SA-00197
Intel® Media Server Studio for Windows® Vulnerability Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00197.html
INTEL-SA-00196
Intel® RAID Web Console 3 for Windows Authentication Bypass Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00196.html
INTEL-SA-00188
Intel® PROSet/Wireless WiFi Software Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00188.html
INTEL-SA-00187
Intel® Driver & Support Assistant Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00187.html
INTEL-SA-00180
Intel® Trace Analyzer 2018 Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00180.html
INTEL-SA-00153
Intel® Rapid Store Technology Installer Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00153.html
Surprisingly Turing Complete – How many computers are in your computer?
https://www.gwern.net/Turing-complete
one might think that such universality as a system being smart enough to be able to run any program might be difficult or hard to achieve, but it turns out to be the opposite and it is difficult to write a useful system which does not immediately tip over into TC
And a nice reference to this old Tweet:
It’s amazing how many heterogeneous CPU cores were integrated in Intel Silvermont’s Moorefield SoC (ANN): x86, ARC, LMT, 8051, Audio DSP, each running own firmware and supporting JTAG interface
ibm_pw_clear: EFI utility that clears the power-on and setup passwords in IBM x3550/x3650 M3 servers
[…]Will this work on a non-IBM server?
No, this uses IBM-specific UEFI hooks to reset the passwords.
[…]
Print(L“Loaded DxeIBMUserSecurity\n“);
https://github.com/bdutro/ibm_pw_clear
NSA UEFI Lockdown Quick Guidance
UEFI Lockdown Quick Guidance
https://apps.nsa.gov/iaarchive/library/ia-guidance/security-tips/cfs-u-oo-111747-18.cfm
UEFI Advantages Over Legacy Mode
https://apps.nsa.gov/iaarchive/library/ia-guidance/security-tips/uefi_lockdown_quick_guidance.cfm
ISA Semantics for ARMv8-A, RISC-V, and CHERI-MIPS
https://twitter.com/daniel_bilar/status/1061679196194377731
Proc. 46th ACM SIGPLAN Symposium on Principles of Programming Languages
Architecture specifications notionally define the fundamental interface between hardware and software: the envelope of allowed behaviour for processor implementations, and the basic assumptions for software development and verification. But in practice, they are typically prose and pseudocode documents, not rigorous or executable artifacts, leaving software and verification on shaky ground. In this paper, we present rigorous semantic models for the sequential behaviour of large parts of the mainstream ARMv8-A, RISC-V, and MIPS architectures, and the research CHERI-MIPS architecture, that are complete enough to boot operating systems, variously Linux, FreeBSD, or seL4. Our ARMv8-A models are automatically translated from authoritative ARM-internal definitions, and (in one variant) tested against the ARM Architecture Validation Suite. We do this using a custom language for ISA semantics, Sail, with a lightweight dependent type system, that supports automatic generation of emulator code in C and OCaml, and automatic generation of proof-assistant definitions for Isabelle, HOL4, and (currently only for MIPS) Coq. We use the former for validation, and to assess specification coverage. To demonstrate the usability of the latter, we prove (in Isabelle) correctness of a purely functional characterisation of ARMv8-A address translation. We moreover integrate the RISC-V model into the RMEM tool for (user-mode) relaxed-memory concurrency exploration. We prove (on paper) the soundness of the core Sail type system. We thereby take a big step towards making the architectural abstraction actually well-defined, establishing foundations for verification and reasoning.
ish: Linux shell for iOS
Keystone: Open-source Secure Hardware Enclave
Keystone is an open-source project for building trusted execution environments (TEE) with secure hardware enclaves, based on the RISC-V architecture. Our goal is to build a secure and trustworthy open-source secure hardware enclave, accessible to everyone in industry and academia.
FuzzNDIS: a fuzzer for Windows NDIS drivers by IOActive
PentestHardware: Kinda useful notes collated together publicly [WIP]
PentestHardware: Kinda useful notes collated together publicly
NB – this is very much a work in progress, released early for comments and feedback. Hoping to complete first full version by XMas 2018. 🙂
https://github.com/unprovable/PentestHardware
bootscripts: UEFI Linux boot scripts and instructions
UEFI-Boot is a simple project that focused on loading Linux kernel directly from UEFI firmware without need in any bootloader.
Russian: http://help.ubuntu.ru/wiki/uefiboot
Apple: About Secure Boot
Apple has — at least I think so — updated their Secure Boot knowledge base article in the last few days:
Daax: virtualization hypervisor series: part 3 now available
Part 3 is out, and I also neglected to mention part 2.
https://revers.engineering/day-2-entering-vmx-operation/
Day 3: The VMCS, Component Encoding, and Multiprocessor Initialization
Firmware Security 
You must be logged in to post a comment.