On OpenPOWER POWER9 systems, we typically talk to the flash chips that hold firmware for the host (i.e. the POWER9) processor through a daemon running on the BMC (aka service processor) rather than directly. We have host firmware map โwindowsโ on the LPC bus to parts of the flash chip. This flash chip can in fact be a virtual one, constructed dynamically from files on the BMC. Since weโre mapping windows into this flash address space, we have some knowledge as to what IO the host is doing to/from the pnor. We can use this to output data in the blktrace format and feed into existing tools used to analyze IO patterns. So, with a bit of learning of the data format and learning how to drive the various tools, I was ready to patch the BMC daemon (mboxbridge) to get some data out.[…]
Author: hucktech
Beam me up, CFG (Control Flow Guard)
https://twitter.com/hh86_/status/1063347806948216833
What is CFG? Earlier in 2018 while revisiting the Delay Import Table, I used dumpbin to check the Load Configuration data of a file and noticed new fields in it: <figure omitted>. And at the time of writing this, more fields were added! The first CFGuard caught my attention and I learned about Control Flow Guard, it is a new security feature. To put it simple, it protects the execution flow from redirection – for example, from exploits that overwrite an address in the stack. Maybe they should call it the Security Directory instead. ;-)[…]
https://86hh.github.io/cfg.html
more info:
https://docs.microsoft.com/en-us/windows/desktop/secbp/control-flow-guard
Defensive Security: Playing with Linux Kernel Runtime Guard (LKRG)
UEFI SecureBoot on ArchLinux
I want full control at what boots the computer to avoid the so called evil maid attack. That requires setting SecureBoot with only my own keys. SecureBoot protects the computer from tampering with the installed OS and boot files, while it’s left powered off outside our view. It’s not a substitute for disk encryption though, it’s an addition to it.[…]
https://github.com/gdamjan/secure-boot
ShadEFI: A general purpose UEFI Bootloader/Chainloader with a modern UI.
A general purpose UEFI Bootloader/Chainloader with a modern UI.
SeaBIOS 1.12.0 released
Kevin O’Connor announced release 1.12.0 of SeaBIOS:
New in this release:
* Initial support for “TPM CRB” hardware
* Improved cdrom media reporting in the boot menu on QEMU
* Improved floppy support on real floppy hardware
* SeaVGABIOS support for QEMU “bochs-display” and QEMU “ramfb” displays
* Several bug fixes and code cleanups
https://seabios.org/Releases#SeaBIOS_1.12.0
more info about this release:
https://mail.coreboot.org/pipermail/seabios/2018-November/012576.html
ZFS Boot Environments
As long as sysadmins need to maintain, change and update operating systems there is always need to protect against problems that may occur during these operations. Various solutions were used starting from simple backup/restore procedures or copying the contents of system filesystems into spare disks to snapshots and clones recently. None of these solutions were transparent enough or bulletproof enough to provide complete and consistent protection again failures in the change or update process. One of such holy grails is ZFS Boot Environments solution. It protects entire system (and even additional data when needed) against almost any change or update process. As ZFS Boot Environments matured in Solaris/Illumos systems and then on FreeBSD UNIX other systems started to copy its principles to provide similar solutions such as snapper with BTRFS in SUSE or Boot Environment Manager for DragonFly BSD with their HAMMER filesystem. The presentation aims to walk through the history of these solutions with the focus on practical ZFS Boot Environments solutions and examples.
ZFS Boot Environments Reloaded at NLUUG Autumn Conference 2018
https://www.nluug.nl/activiteiten/events/nj18/abstracts/ab12.html
Phantom Device Attack: Uncovering the Security Implications of the Interactions among Devices, IoT Cloud, and Mobile Apps
(Submitted on 8 Nov 2018)
Smart home connects tens of home devices into the Internet, running a smart algorithm in the cloud that sends remote commands to the devices. While bringing unprecedented convenience, accessibility, and efficiency, it also introduces safety hazards to users. Prior research studied smart home security from various aspects. However, we found that the complexity of the interactions among the participating entities (device, IoT cloud, and mobile app) has not yet been systematically investigated. In this work, we conducted an in-depth analysis to four widely used smart home solutions. Combining firmware reverse-engineering, network traffic interception, and black-box testing, we distill the general state transitions representing the complex interactions among the three entities. Based on the state machine, we reveal several vulnerabilities that lead to unexpected state transitions. While these minor security flaws appear to be irrelevant, we show that combining them in a surprising way poses serious security or privacy hazards to smart home users. To this end, five concrete attacks are constructed and illustrated. We also discuss the implications of the disclosed attacks in the context of business competition. Finally, we propose some general design suggestions for building a more secure smart home solution.
USBCaptchaIn: Preventing (Un)Conventional Attacks from Promiscuously Used USB Devices in Industrial Control Systems
(Submitted on 11 Oct 2018)
Industrial Control Systems (ICS) are sensible targets for high profile attackers and advanced persistent threats, which are known to exploit USB thumb drives as an effective spreading vector. In ICSes, thumb drives are widely used to transfer files among disconnected systems and represent a serious security risks, since, they may be promiscuously used in both critical and regular systems. The threats come both from malware hidden in files stored in the thumb drives and from BadUSB attacks [16]. BadUSB leverages the modification of firmware of USB devices in order to mimic the behaviour of a keyboard and send malicious commands to the host. We present a solution that allows a promiscuous use of USB thumbs drives while protecting critical machines from malware, that spread by regular file infection or by firmware infection. The main component of the architecture we propose is an hardware, called USBCaptchaIn, intended to be in the middle between a critical machine and all USB devices. We do not require users to change the way they use thumb drives. To avoid human-errors, we do not require users to take any decision. The proposed approach is highly compatible with already deployed products of a ICS environment and proactively blocks malware before they reach their targets. We describe our solution, provide a thorough analysis of the security of our approach in the ICS context, and report the informal feedback of some experts regarding our first prototypes.
Interface-Based Side Channel Attack Against Intel SGX
(Submitted on 8 Oct 2018)
Intel has introduced a trusted computing technology, Intel Software Guard Extension (SGX), which provides an isolated and secure execution environment called enclave for a user program without trusting any privilege software (e.g., an operating system or a hypervisor) or firmware. Nevertheless, SGX is vulnerable to several side channel attacks (e.g. page-fault-based attack and cache-based attack). In this paper, we explore a new, yet critical side channel attack in SGX, interface-based side channel attack, which can infer the information of the enclave input data. The root cause of the interface-based side channel attack is the input dependent interface invocation information (e.g., interface information and invocation patterns) which can be observed by the untrusted privilege software can reveal the control flow in the enclave. We study the methodology which can be used to conduct the interface-based side channel attack. To illustrate the effectiveness of the interface-based side-channel attacks, we use our methodology to infer whether tracked web pages have been processed by the SGX-assisted NFV platforms and achieve the accuracy of 87.6% and recall of 76.6%. We also identify the packets which belong to the tracked web pages, with the accuracy of 67.9%and recall of 71.1%. We finally propose some countermeasures to defense the interface-based side channel attack in SGX-assisted applications.
William Leara: iPXE Walkthrough
This article explores iPXE, an open source network boot firmware that I think BIOS developers should be aware of.[…]
https://www.basicinputoutput.com/2018/11/ipxe-walkthrough.html
Bushwhacking your way around a bootloader
Tools and techniques for traversing treacherous code bases
– or- How I managed to develop understanding of U-Boot
Spring 2019 UEFI Forum plugfest date/location announced
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.

You must be logged in to post a comment.