My latest little 1-day project: generating a Z3 SAT model of x86 intrinsics from Intel's documentation. This can help prove SIMD code correct, find lookup table values, etc. https://t.co/9LHTdr5wk6

— Zach Wegner (@zwegner) December 17, 2019

This is a rudimentary attempt to build an autogenerated formal-ish model of x86 intrinsics by interpreting Intel’s instruction pseudocode, transforming it into a model for Z3.

https://github.com/zwegner/x86-sat

If you use the LLVM LLDB debugger, you should also be using lldbinit, and there’s an updated release out!

https://twitter.com/osxreverser/status/1211727989102256128

https://github.com/gdbinit/lldbinit

Binary-only, no source code, so be careful if you use experiment with this tool:

https://github.com/ASparkOfFire/lenovo-u1-tool

Z. Weissman et al., “JackHammer: Efficient Rowhammer on Heterogeneous FPGA-CPU Platforms” […we analyze the memory and cache subsystem and study Rowhammer and cache attacks enabled on two proposed heterogeneous FPGA-CPU platforms by Intel…]https://t.co/WO2MMat2UE

— Arrigo Triulzi (@cynicalsecurity) December 30, 2019

https://arxiv.org/abs/1912.11523

[…]Further, we demonstrate JackHammer, a novel and efficient Rowhammer from the FPGA to the host’s main memory. Our results indicate that a malicious FPGA can perform twice as fast as a typical Rowhammer attack from the CPU on the same system and causes around four times as many bit flips as the CPU attack. We demonstrate the efficacy of JackHammer from the FPGA through a realistic fault attack on the WolfSSL RSA signing implementation that reliably causes a fault after an average of fifty-eight RSA signatures, 25% faster than a CPU rowhammer attack. In some scenarios our JackHammer attack produces faulty signatures more than three times more often and almost three times faster than a conventional CPU rowhammer attack.

Merry XMass!! The source code is out: https://t.co/fbZJqU2fgA https://t.co/3cM3q7BWiK

— Daniel Moghimi (@flowyroll) December 26, 2019

The source code is now available:

https://github.com/vernamlab/TPM-FAIL

https://tpm.fail/

New blogpost: Sanitized Emulation with QEMU-AddressSanitizerhttps://t.co/UGqOCcKJkF
I just open-sourced my QEMU patches to fuzz binaries with ASan, QASan. You can also use it with ARM targets on Linux, a thing that you can't do with LLVM ASan!

— Andrea Fioraldi (@andreafioraldi) December 26, 2019

[…]I created QASan (QEMU-AddressSanitizer), a fork of user-mode QEMU that introduce AddressSanitizer for heap objects into QEMU. QASan not only enables AddressSanitizer on COTS x86/x86_64/ARM/ARM64 binaries on Linux/*BSD but allows also the instrumentation of code generated at runtime (e.g. JIT) that is, of course, not supported by source-level ASAN. Note also that at the time of writing AddressSanitizer doesn’t support ARM/ARM64 on Linux and QASan enables that for this class of binaries.[…]

https://github.com/andreafioraldi/qasan

https://andreafioraldi.github.io/articles/2019/12/20/sanitized-emulation-with-qasan.html

This is a project to collect hardware details of Linux-powered computers over the world and help Linux users and developers to collaboratively debug hardware related issues, check for Linux-compatibility and find drivers.

The web site has a tool, HW-Probe, and a Github repo of uploaded ACPI tables:

This is a repository of decoded ACPI tables for various computers collected by Linux users […] Everyone can contribute to this repository by uploading probes of their computers by the hw-probe tool:

https://github.com/linuxhw/ACPI

https://github.com/linuxhw/hw-probe

https://linux-hardware.org/

https://linux-hardware.org/?view=timeline

A new set of "Mac firmware security" pages are finally out, thanks to @XenoKovah.
Check it out, it's what me and my teammates at Apple had beet working on really damn hard for the last several years.https://t.co/Q2Kx8jx8wO

— Nikolaj Schlej (@NikolajSchlej) December 19, 2019

https://support.apple.com/guide/security/uefi-firmware-overview-seced055bcf6/web

In addition to above apple.com-hosted content, there are slides and videos from the last BlackHat USA on Apple security:

Video released: https://t.co/s1ATS1w2lU https://t.co/A5kk4Tq4Rq

— Xeno Kovah (@XenoKovah) December 13, 2019

Mac secure boot (with two world firsts: DMA defense from PCIe Bus 0, and the Option ROM sandbox), iOS kernel integrity, Pointer Auth Codes (PAC), APRR register, Page Protection Layer (PPL), and novel Find My crypto — all in my slides from Black Hat 2019! https://t.co/6vdAodGS3F

— Ivan Krstić (@radian) November 22, 2019

A new C# UEFI library:

https://github.com/sangwon090/dotEFI

Updated Signing Requirements for UEFI 3rd Party CA Key: https://t.co/pV9Qw6pLyt #firmware

— Brian Richardson (on LinkedIn) (@BrianOnChips) December 12, 2019

https://techcommunity.microsoft.com/t5/Hardware-Dev-Center/UPDATED-UEFI-Signing-Requirements/ba-p/1062916

Re: https://firmwaresecurity.com/2015/07/06/uefi-smm-vulnerability-research-smmbackdoor/

this project has been updated recently. Only a few checkins for 2015 and 2016. Now some bugfixes for 2019:

https://github.com/Cr4sh/SmmBackdoor

There is a branch of the Tianocore UEFI C codebase that is being ported to Rust!!

https://github.com/tianocore/edk2-staging/tree/edkii-rust

http://vzimmer.blogspot.com/2019/12/rust-oxide-corrosion.html

Interesting! I wonder how this will turn out. There is not a lot of Rust knowledge in the existing Firmware engineer community, but there is a lot of talk about Rust replacing C for low-level systems projects. While one Microsoft security researcher has posted a blog about Rust, I really don’t see Microsoft embracing Rust. They have to retrain their existing C developers to use a new language, and they’d need a language that they could control the direction of. I suspect the Microsoft systems team, if forced to migrate from their C89-era compiler to something modern, would probably use their CheckedC or Project Verona. I would love to be proven wrong. 🙂

My team has been working a lot with TPM hardware lately and found some pretty critical issues with the spec. Here's our 90-day disclosure of a vulnerability report we sent to @TrustedComputin. "Verifying TPM Boot Events and Untrusted Metadata" https://t.co/BrqpBVdooI

— Eric Chiang (@erchiang) December 10, 2019

Go-Attestation abstracts remote attestation operations across a variety of platforms and TPMs, enabling remote validation of machine identity and state. This project attempts to provide high level primitives for both client and server logic.[…]

Really great work from one of my teammates https://t.co/zltfrjOi7g

— Matthew Garrett (@mjg59@nondeterministic.computer) (@mjg59) December 10, 2019

https://github.com/google/go-attestation/blob/master/docs/event-log-disclosure.md

Today Intel released 9 new security advisories:

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

Unexpected Page Fault in Virtualized Environment Advisory
INTEL-SA-00317
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00317.html

Intel® SCS Platform Discovery Utility Advisory
INTEL-SA-00312
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00312.html

Intel® Quartus® Prime Pro Edition Advisory
INTEL-SA-00311
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00311.html

Control Center-I Advisory
INTEL-SA-00299
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00299.html

Intel® Processors Voltage Settings Modification Advisory
INTEL-SA-00289
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00289.html

Intel® Ethernet I218 Adapter Driver for Windows* Advisory
INTEL-SA-00253
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00253.html

Linux Administrative Tools for Intel® Network Adapters Advisory
INTEL-SA-00237
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00237.html

Intel® Dynamic Platform and Thermal Framework Advisory
INTEL-SA-00230
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00230.html

Using an Option ROM to overwrite SMM/SMI handlers in QEMU https://t.co/JfRFfP2pTN

— Anderson Nascimento (@andersonc0d3) December 4, 2019

This article explores PCI Expansion ROM (or Option ROM) execution within UEFI and walks through a practical scenario of using Option ROM code to modify SMM. In order to accomplish this goal we relax the security within EDK2. Note that this article does not reveal any security weaknesses. We begin with how to create a QEMU/OVMF/iPXE testing environment that boots Fedora with UEFI Secure Boot enabled and measures the pre-OS environment using a software TPM2. We then install an SMI handler by modifying our iPXE EFI Option ROM, which is the same as a DXE driver run during Boot Device Select (BDS). Finally, we again modify our Option ROM code and overwrite and reliably ‘shim’ an existing SMI’s handler with our own.[…]

https://casualhacking.io/blog/2019/12/3/using-optionrom-to-overwrite-smmsmi-handlers-in-qemu

My book chapter on side channels is now out – from Tempest though DPA, template attacks and TPM-fail, and all kinds of acoustic and optical leakage, to Meltdown and Spectre. Comments welcome: https://t.co/PSnvpt1ivv

— Ross Anderson (@rossjanderson) December 6, 2019

https://www.cl.cam.ac.uk/~rja14/book.html

Click to access SEv3-ch19-dec7.pdf