Patching Yourself into Windows Code Integrity, Part 1: On-Disk Patching

I started this whole thing because I wanted to run my own kernel-mode code while still having access games protected by anti-cheat that don’t allow test signing, and I didn’t want to shell out the time and money required to get an EV certificate. […]I’m going to start out by patching binaries on disk, but the end result will be a UEFI application that patches all binaries in memory. […]

https://github.com/Avery3R/re-writeups/blob/master/windows-ci/part1_on_disk_patching.md

RIP: Dave Beaver

[This is off-topic of firmware security.]

Dave Beaver passed away Saturday. He was a friend of mine. He was a Developer at DEC, who was one of the initial NT developers who came over to MSFT with Dave Cutler. He created the initial dev kit for NT file system filter vendors, so all the NT antivirus security products had him to thank for their NT products. Here’s a more detailed remembrance:

https://community.osr.com/discussion/290973/rip-dave-beaver/

CVE-2019-6260: PantsDown: Gaining control of BMC from the host processor

CVE-2019-6260: Gaining control of BMC from the host processor
Posted on 23/01/2019 by Stewart Smith

This is details for CVE-2019-6260 – which has been nicknamed “pantsdown” due to the nature of feeling that we feel that we’ve “caught chunks of the industry with their…” and combined with the fact that naming things is hard, so if you pick a bad name somebody would have to come up with a better one before we publish.

I expect OpenBMC to have a statement shortly.[…]

CVE-2019-6260: Gaining control of BMC from the host processor

 

Sculpt OS: based on Genode

“Sculpt is an open-source general-purpose OS. It combines Genode’s microkernel architecture, capability-based security, sandboxed device drivers, and virtual machines in a novel operating system for commodity PC hardware. Sculpt is used as day-to-day OS by the Genode developers.”

https://genode.org/download/sculpt

Linux kernel patch: x86/speculation: add L1 Terminal Fault / Foreshadow demo

https://lkml.org/lkml/2019/1/21/606

Raymond Chen: The Intel 80386, blog series

Part 1: https://blogs.msdn.microsoft.com/oldnewthing/20190121-00/?p=100745

Part 2: https://blogs.msdn.microsoft.com/oldnewthing/20190122-00/?p=100755

https://blogs.msdn.microsoft.com/oldnewthing/

BlackHat Asia: Ghosts in a Nutshell

Claudio Canella, Moritz Lipp

At the beginning of 2018, two severe attacks, called Meltdown and Spectre, have been published. These attacks exploit that the CPU either lazily enforces exceptions or speculates on the outcome of branch predictions or data dependencies. While the results of those computations are never made visible on the architectural level, secret data can still leak on the microarchitectural level and be observed by an attacker. Since then, many different versions of these attacks have been found by various research teams around the world, e.g., Spectre Variant 1, Spectre Variant 2, Variant 4, Meltdown, Foreshadow, Foreshadow-NG, LazyFP. Due to the confusing naming scheme and the large amounts of papers and articles published, it has quickly become difficult to differentiate them all. Additionally, researchers, as well as companies, have proposed various countermeasures to mitigate these attacks, making it even more confusing and difficult to keep a clear overview of the current state. Many of the proposed mitigation techniques involve substantial overhead, basically reducing the processing power of modern CPUs. With all these defences, one question remains: Do they actually work or are they just reducing the performance of our CPUs? Did the operating system implement them correctly? Is everything fixed now or are there even more variants that have so far been overlooked? In this talk, we will discuss all existing variants and introduce a newer, easier to understand naming scheme based on the microarchitectural element the attacks exploit. We will discuss all mitigation techniques proposed so far and classify them based on how they attempt to stop leakage. We will also discuss which of those mitigations work in practice and which ones we were able to circumvent with our experiments. We will present new variants of Meltdown and Spectre attacks that have not been published so far and which we were able to discover due to our systematisation.

https://www.blackhat.com/asia-19/briefings/schedule/#ghosts-in-a-nutshell-13755

BlackHat Asia: Modern Secure Boot Attacks: Bypassing Hardware Root of Trust from Software

Modern Secure Boot Attacks: Bypassing Hardware Root of Trust from Software
Alex Matrosov | Offensive Security Lead, NVIDIA

Many hardware vendors are armoring modern Secure Boot by moving Root of Trust to the hardware. While it is definitely the right direction to create more difficulties for the attacker, many layers of code exist between hardware and firmware. Also, hardware vendors are always fighting for boot performance, which creates interesting security issues in actual implementations. In this presentation, I’ll explain new security issues to bypass a specific implementation of Intel Boot Guard technology in one of the most common enterprise vendors. The actual vulnerability allows the attacker to bypass Intel Boot Guard security checks from OS without physical access to the hardware. Also, I’ll cover topics including Embedded Controller (EC) with focus on UEFI Firmware cooperation and Authenticated Code Module (ACM) runtime environment. It is brand new research not based on my previous Boot Guard discoveries.

https://www.blackhat.com/asia-19/briefings/schedule/index.html#modern-secure-boot-attacks-bypassing-hardware-root-of-trust-from-software-13950

Using SMM to Circumvent OS Security Functions

Using CPU System Management Mode to Circumvent Operating System Security Functions

Loı̈c Duflot, Daniel Etiemble, Olivier Grumelard

Abstract. In this paper we show how hardware functionalities can be misused by an attacker to extend her control over a system. The originality of our approach is that it exploits seldom used processor and chipset functionalities, such as switching to system management mode, to escalate local privileges in spite of security restrictions imposed by the operating system. As an example we present a new attack scheme against OpenBSD on x86-based architectures. On such a system the superuser is only granted limited privileges. The attack allows her to get full privileges over the system, including unrestricted access to physical memory. Our sample code shows how the superuser can lower the “secure level” from highly secure to permanently insecure mode. To the best of our knowledge, it is the first time that documented processor and chipset functionalities have been used to circumvent operating system security functions.

https://www.semanticscholar.org/paper/Using-CPU-System-Management-Mode-to-Circumvent-Duflot-Etiemble/62beba49b7a9eb50c0a860547cceb2863e994aa2

Microcode tools

Re: https://firmwaresecurity.com/2018/01/08/microcode/ I was recently asked why awesome-firmware-security doesn’t yet have a good list of microcode tools, and what are the available microcode tools… Here’s the list I can think of at the moment, I’ll have to update awesome-firmware-security with this list soon:

iucode-tool
https://gitlab.com/iucode-tool/iucode-tool

MCExtractor:
https://firmwaresecurity.com/tag/mcextractor/
https://github.com/platomav/MCExtractor

Microcode:

New x86 microcode tool


https://github.com/RUB-SysSec/Microcode

Microparse:
https://firmwaresecurity.com/tag/gail-joon-ahn/
https://github.com/ddcc/microparse

MicroRenovator:

MicroRenovator: Pre-OS microcode updater


https://github.com/syncsrc/MicroRenovator

< 2 unnamed scripts >:

Parsing Intel microcode


http://blog.fpmurphy.com/2016/12/python-3-utilities-for-parsing-intel-microcode.html

Please, leave a Comment on this blog post if you know of another tool.

This article gives the package names of the microcode tools for various Linux distros:
https://www.cyberciti.biz/faq/install-update-intel-microcode-firmware-linux/

These wiki pages have general info on microcode:
https://en.wikipedia.org/wiki/Intel_Microcode
https://wiki.archlinux.org/index.php/microcode
https://wiki.debian.org/Microcode
https://wiki.gentoo.org/wiki/Intel_microcode

Writing a Hyper-V “Bridge” for Fuzzing — Part 1: WDF

https://twitter.com/aionescu/status/1085559401149284352

After spending the better part of a weekend writing a specialized Windows driver for the purposes of allowing me to communicate with the Hyper-V hypervisor, as well as the Secure Kernel, from user-mode, I realized that there was a dearth of concise technical content on non-PnP driver development, and especially on how the Windows Driver Foundation (WDF) fundamentally changes how such drivers can be developed. While I’ll eventually release my full tool, once better polished, on GitHub, I figured I’d share some of the steps I took in getting there. Unlike my more usual low-level super-technical posts, this one is meant more as an introduction and tutorial, so if you already consider yourself experienced in WDF driver development, feel free to wait for Part 2.

Reminder: firmware talk/lab at July DC206 Meeting

firmware at FOSDEM…

There are a lot of interesting presentations at FOSDEM, such as Brian’s CHIPSEC talk. Look at the Security and Hardware Enablement tracks.

https://fosdem.org/2019/schedule/

https://fosdem.org/2019/schedule/event/chipsec/