3 new research papers on fuzzing

 

https://arxiv.org/abs/1901.01142

https://arxiv.org/abs/1812.01197

https://arxiv.org/abs/1812.00140

 

Azure IoT automatic device management helps deploying firmware updates at scale

Automatic device management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. Since the feature shipped in June 2018, there has been a lot of interest in the firmware update use case. This blog article highlights some of the ways you can kickstart your own implementation.

https://azure.microsoft.com/en-us/blog/azure-iot-automatic-device-management-helps-deploying-firmware-updates-at-scale/

When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs

When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs
Ghada Dessouky, David Gens, Patrick Haney, Garrett Persyn, Arun Kanuparthi, Hareesh Khattri, Jason M. Fung, Ahmad-Reza Sadeghi, Jeyavijayan Rajendran
(Submitted on 1 Dec 2018)

In this paper, we take a deep dive into microarchitectural security from a hardware designer’s perspective by reviewing the existing approaches to detect hardware vulnerabilities during the design phase. We show that a protection gap currently exists in practice that leaves chip designs vulnerable to software-based attacks. In particular, existing verification approaches fail to detect specific classes of vulnerabilities, which we call HardFails: these bugs evade detection by current verification techniques while being exploitable from software. We demonstrate such vulnerabilities in real-world SoCs using RISC-V to showcase and analyze concrete instantiations of HardFails. Patching these hardware bugs may not always be possible and can potentially result in a product recall. We base our findings on two extensive case studies: the recent Hack@DAC 2018 hardware security competition, where 54 independent teams of researchers competed world-wide over a period of 12 weeks to catch inserted security bugs in SoC RTL designs, and an in-depth systematic evaluation of state-of-the-art verification approaches. Our findings indicate that even combinations of techniques will miss high-impact bugs due to the large number of modules with complex interdependencies and fundamental limitations of current detection approaches. We also craft a real-world software attack that exploits one of the RTL bugs from Hack@DAC that evaded detection and discuss novel approaches to mitigate the growing problem of cross-layer bugs at design time.

https://arxiv.org/abs/1812.00197

SPECTECTOR: Principled Detection of Speculative Information Flows

SPECTECTOR: Principled Detection of Speculative Information Flows
Marco Guarnieri, Boris Köpf, José F. Morales, Jan Reineke, Andrés Sánchez
(Submitted on 20 Dec 2018)

Since the advent of SPECTRE, a number of countermeasures have been proposed and deployed. Rigorously reasoning about their effectiveness, however, requires a well-defined notion of security against speculative execution attacks, which has been missing until now. We present a novel, principled approach for reasoning about software defenses against SPECTRE-style attacks. Our approach builds on speculative non-interference, the first semantic notion of security against speculative execution attacks. We develop SPECTECTOR, an algorithm based on symbolic execution for automatically proving speculative non-interference, or detecting violations.
We implement SPECTECTOR in a tool, and we use it to detect subtle leaks — and optimizations opportunities — in the way major compilers place SPECTRE countermeasures.

https://arxiv.org/abs/1812.08639

[AMD] SEVered attack: Extracting Secrets from Encrypted VMs

Extracting Secrets from Encrypted Virtual Machines
Mathias Morbitzer, Manuel Huber, Julian Horsch
(Submitted on 7 Jan 2019)

AMD SEV is a hardware extension for main memory encryption on multi-tenant systems. SEV uses an on-chip coprocessor, the AMD Secure Processor, to transparently encrypt virtual machine memory with individual, ephemeral keys never leaving the coprocessor. The goal is to protect the confidentiality of the tenants’ memory from a malicious or compromised hypervisor and from memory attacks, for instance via cold boot or DMA. The SEVered attack has shown that it is nevertheless possible for a hypervisor to extract memory in plaintext from SEV-encrypted virtual machines without access to their encryption keys. However, the encryption impedes traditional virtual machine introspection techniques from locating secrets in memory prior to extraction. This can require the extraction of large amounts of memory to retrieve specific secrets and thus result in a time-consuming, obvious attack. We present an approach that allows a malicious hypervisor quick identification and theft of secrets, such as TLS, SSH or FDE keys, from encrypted virtual machines on current SEV hardware. We first observe activities of a virtual machine from within the hypervisor in order to infer the memory regions most likely to contain the secrets. Then, we systematically extract those memory regions and analyze their contents on-the-fly. This allows for the efficient retrieval of targeted secrets, strongly increasing the chances of a fast, robust and stealthy theft.

https://arxiv.org/abs/1901.01759

Latest S2E released, adds QEMU v3 support

S²E is a platform for writing tools that analyze the properties and behavior of software systems. S²E comes as a modular library that gives virtual machines symbolic execution and program analysis capabilities. S²E runs unmodified x86, x86-64, or ARM software stacks, including programs, libraries, the kernel, and drivers. Symbolic execution then automatically explores hundreds of thousands of paths through the system, while analyzers check that the desired properties hold on these paths and selectors focus path exploration on components of interest. S²E is now commercially supported by Cyberhaven. It is free for non-commercial use. S²E was a research project of the Dependable Systems Lab at EPFL in Lausanne.

http://s2e.systems/docs/DesignAndImplementation/KvmInterface.html

https://github.com/s2e/

https://github.com/S2E/qemu

 

Keegan Ryan: Spectre on a Television

This past January, I ordered a new TV. […] The TV was manufactured by Sceptre Inc. (note the ‘C’ and ‘P’ switch) and was covered in SCEPTRE branding. My goal for this project was to perform a hardware-level attack against the TV and change the branding to SPECTRE as an homage to the microarchitectural attack. This project has nothing to do with exploiting speculative execution, but instead it demonstrates several common techniques NCC Group uses when analyzing embedded systems.[…]

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2018/december/spectre-on-a-television/

Hacking Your Way to a Custom TV Boot Screen

Spectre TV

Sail-Arm: Sail version of ARM ISA definition, currently for ARMv8.5-A

https://github.com/rems-project/sail-arm

see-also:

https://github.com/rems-project/sail

https://alastairreid.github.io/papers/FMCAD_16/

Bareflank’s hypervisor: lightweight hypervisor SDK written in C++ with support for Windows, Linux and UEFI

The Bareflank Hypervisor is an open source, hypervisor Software Development Toolkit (SDK), led by Assured Information Security, Inc. (AIS), that provides a set of APIs needed to rapidly prototype and create new hypervisors. To ease development, Bareflank is written in C/C++, and includes support for C++ exceptions, JSON, the GSL and the C++ Standard Template Library (STL).

https://github.com/Bareflank/hypervisor

https://www.ainfosec.com/

Bareflank

Debian UEFI Secure Boot changes!

Steve McIntyre has posted an update on Debian’s UEFI Secure Boot status, to the debian-boot and debian-efi mailing lists. Excerpt:

I’ve just pushed changes to a few bits of d-i this weekend to make SB work for amd64:

* build/util/efi-image: […]
* build/config/arm.cfg, build/config/x86.cfg: […]
* debian/control: […]
* grub-installer/grub-installer: […]

The effect of these changes is that the next daily and weekly debian installer images (tomorrow) should Just Work (TM) end-to-end with UEFI Secure Boot. The changes to efi-image also mean that our next live image builds will do SB (for live and installation).

I’ll test all these again in the next couple of days to verify that things have pulled through as I expect, then it’s time to post to d-d-a and write a blog too. We’ve made great progress already. These last changes just tie it all together for end users.

More info:

https://lists.debian.org/msgid-search/20190113192343.qg3ekmtnyepscwxb@tack.einval.com

hdk – (unofficial) Hyper-V® Development Kit

The HDK is an updated version of the HvGdk.h header file published under MSR-LA as part of the Singularity Research Kernel. It has been updated to add the latest definitions, structures and definitions as described in the Microsoft Hypervisor Top-Level Functional Specification (TLFS) 5.0c published June 2018.

https://ionescu007.github.io/hdk/

UEFI-based screen capture tools

I notice that Microsoft’s Project Mu has a PrintScreenLogger tool (Ctrl+PrtScn):

https://github.com/Microsoft/mu_plus/tree/release/201808/MsGraphicsPkg/PrintScreenLogger

https://microsoft.github.io/mu/dyn/mu_plus/MsGraphicsPkg/PrintScreenLogger/Readme/#printscreenlogger-operation

and that it is already getting some forks:

https://github.com/vscpp/PrintScreenLogger

Before that, there was RU.EFI command line tool (F12):

https://firmwaresecurity.com/2016/09/09/ru-efi-updated-screen-snapshot-support/

and Nikolaj’s CrScreenShotDXE (LeftCtrl+LeftAlt+F12):

https://firmwaresecurity.com/2016/01/04/screenshot-taking-uefi-dxe-driver/

https://firmwaresecurity.com/2016/08/23/william-reviews-crscreenshotdxe/

And there are probably a few other options I’m not aware of, including by IBVs/ODMs.

OCP Global Summit: : CHIPSEC on non-UEFI Platforms

by Stephano Cetola, Software Applications Engineer, Intel Corportation

CHIPSEC is a firmware threat assessment tool used to help verify that systems meet basic security best practices. The tool’s threat model is primarily based on Unified Extensible Firmware Interface (UEFI). However, other firmware may have different threat models that will cause failures in different CHIPSEC modules. This session is a brief overview of CHIPSEC, limitations of the tool, failures seen on different types of firmware, and information on developing new test modules.

https://2019ocpglobalsummit.sched.com/event/JinT

6 Intel security advisories

INTEL-SA-00212
Intel® System Support Utility for Windows Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00212.html

INTEL-SA-00207
Intel® SSD Data Center Tool Vulnerability Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00207.html

INTEL-SA-00203
Intel® SGX Platform Software and Intel® SGX SDK Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00203.html

INTEL-SA-00182
Intel® PROSet/Wireless WiFi Software Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00182.html

INTEL-SA-00175
Intel® Optane™ SSD DC P4800X Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00175.html

INTEL-SA-00144
Intel® NUC Firmware Security Advisory
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00144.html

AngoraFuzzer: efficient fuzzing by principled search

Angora: Efficient Fuzzing by Principled Search
Peng Chen, Hao Chen
(Submitted on 4 Mar 2018 (v1), last revised 27 Mar 2018 (this version, v2))

Fuzzing is a popular technique for finding software bugs. However, the performance of the state-of-the-art fuzzers leaves a lot to be desired. Fuzzers based on symbolic execution produce quality inputs but run slow, while fuzzers based on random mutation run fast but have difficulty producing quality inputs. We propose Angora, a new mutation-based fuzzer that outperforms the state-of-the-art fuzzers by a wide margin. The main goal of Angora is to increase branch coverage by solving path constraints without symbolic execution. To solve path constraints efficiently, we introduce several key techniques: scalable byte-level taint tracking, context-sensitive branch count, search based on gradient descent, and input length exploration. On the LAVA-M data set, Angora found almost all the injected bugs, found more bugs than any other fuzzer that we compared with, and found eight times as many bugs as the second-best fuzzer in the program who. Angora also found 103 bugs that the LAVA authors injected but could not trigger. We also tested Angora on eight popular, mature open source programs. Angora found 6, 52, 29, 40 and 48 new bugs in file, jhead, nm, objdump and size, respectively. We measured the coverage of Angora and evaluated how its key techniques contribute to its impressive performance.

https://github.com/AngoraFuzzer/Angora

https://arxiv.org/abs/1803.01307