AMD-SEV: Platform DH key recovery via invalid curve attack (CVE-2019-9836)

[…]Through ongoing collaboration with industry researchers AMD became aware that, if using the user-selectable AMD secure encryption feature on a virtual machine running the Linux operating system, an encryption key could be compromised by manipulating the encryption technology’s behavior.[…]

This vulnerability was discovered and reported to AMD by Cfir Cohen of the
Google Cloud security team.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836

edk2-gdb-server: Open Source EDK2 GDB Server

For a long time Intel has offered a “freeware” (not open source) solution to debug UEFI with a 2-system solution, one running either Linux/GDB or Windows/Windbg:

https://firmware.intel.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool

Last updated in 2017, it used to work on the old TunnelMountain desktop systems, I’ve been meaning to see if it works on MinnowBoard2 systems. And this is Intel-centric (and I presume it may also work on AMD), but, I’m not aware of ARM — nor UEFI Forum’s Tianocore — having a similar offering, which I’d like to be able to use on a UEFI-based Rasberry Pi. HOWEVER… I just noticed this, which came out LAST YEAR, somehow I missed it, an open source solution!!

This is a open code replacement for Intel’s binary only GDB server that comes as part of the ‘Intel UEFI Development Kit Debugger Tool’. Since that tool is Intel x86/64 Linux/Windows only this allows more flexibility. E.g. you can run this on any ARM based SoC with python3 and a USB OTG port connected directly to your target via a USB2.0 EHCI Debug port using the Linux USB OTG Debug Port gadget. You can then connect to that target remotely from your build box, etc. This also allows you to tweak the debugger itself. I’ve already added some additional functionality here to assist when using SourceLevelDebugPkg on non-EDK2 (i.e. no source available) firmwares such as AMI Aptio IV.

https://github.com/night199uk/edk2-gdb-server

Now it just needs also add LLDB support (especially for the Clang-centric HBFA branch)… 🙂 Given this is open source, unlike the Intel solution, this is a possiblity!

A Comprehensive Formal Security Analysis and Revision of the Two-phase Key Exchange Primitive of TPM 2.0


Qianying Zhang, Shijun Zhao, Zhiping Shi, Yong Guan, Guohui Wang
(Submitted on 16 Jun 2019)
The Trusted Platform Module (TPM) version 2.0, which has been demonstrated as a key element of Industry 4.0, presents a two-phase key exchange primitive for secure communications between Industry 4.0 components. The key exchange primitive of TPM 2.0 can be used to implement three widely-standardized authenticated key exchange protocols: the Full Unified Model, the Full MQV, and the SM2 key exchange protocols. However, vulnerabilities have been found in all of these protocols. Fortunately, it seems that the protections offered by TPM chips can mitigate these vulnerabilities. In this paper, we present a security model which captures TPM's protections on keys and protocols' computation environments and in which multiple protocols can be analyzed in a unified way. Based on the unified security model, we give the first formal security analysis of the key exchange primitive of TPM 2.0, and the analysis results show that, with the help of hardware protections of TPM chips, the key exchange primitive indeed satisfies the well-defined security property of our security model, but unfortunately under some impractical limiting conditions, which would prevent the application of the key exchange primitive in real-world networks. To make TPM 2.0 applicable to real-world networks, we present a revision of the key exchange primitive of TPM 2.0, which can keep secure without the limiting conditions. We give a rigorous analysis of our revision, and the results show that our revision achieves not only the basic security property of modern AKE security models but also some further security properties.

https://arxiv.org/abs/1906.06653

FreeBSD: call for testing: UEFI HTTPS boot

The FreeBSD project needs some testing help:

[…]I’ve discovered a couple of bugs in the TianoCore EDK2 firmware, so I’d appreciate any testing people can do on various different systems to check how well they work. In theory HTTPS is also supported, but at least on TianoCore firmware it looks like TLS has a bug which means the second connection causes the system to crash.[…]

https://lists.freebsd.org/pipermail/freebsd-current/2019-June/073593.html

QuarksLab: LLDBagility: practical macOS kernel debugging



Date Tue 18 June 2019 By Francesco Cagnin Category macOS. Tags macOS XNU kernel hypervisor debugging FDP LLDBagility
This is the second of two blog posts about macOS kernel debugging. In the previous post, we defined most of the terminology used in both articles, described how kernel debugging is implemented for the macOS kernel and discussed the limitations of the available tools; here, we present LLDBagility, our solution for an easier and more functional macOS debugging experience.[…]


https://blog.quarkslab.com/lldbagility-practical-macos-kernel-debugging.html

NSA document updated, Boot Security Modes and Recommendations

I not positive, but I think that one of the NSA’s guidance documents has been recently updated:

https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-boot-security-modes-and-recommendations.pdf

BOOT SECURITY MODES AND RECOMMENDATIONS
Modern computing platforms provide a variety of boot options. The security implications, advantages, and disadvantages are rarely identified in documentation. Some configuration options, such as Secure Boot and Trusted Platform Module (TPM) 1 may appear redundant despite serving complementary roles. Six different configurations are compared below. Recommendations for different use cases are presented at the end of this document.

GRUB2 patch lists …and preOS network security

I was just watching this presentation on GRUB from FOSDEM 2019:

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

and it mentions that Fedora has a large number of downstream patches. Before this, I didn’t realize how MANY PATCHES that GRUB2 has, in various distros. For example

https://src.fedoraproject.org/rpms/grub2/tree/master
https://build.opensuse.org/package/show/openSUSE:Factory/grub2
https://sources.debian.org/patches/grub2/2.04%7Erc1-2/

So I need to stop thinking all GRUBS are alike.

I also note this recent Debian bug report, which suggests some GRUB network security issues (which do not appear to be Debian-centric):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930217

I hope GRUB’s network issues can be improved, maybe the additional focus of firmware security researchers?

Yubikey: Security Advisory 2019-06-13 – Reduced initial randomness on FIPS keys

[…]This could allow an attacker who gains access to several signatures to reconstruct the private key.[…]

IDA 7.3 released


[…]You can also debug the UEFI firmware part of the boot process or even custom UEFI modules with source level debugging. Please check our XNU kernel debugging howto for more details on this feature. […]

BUT the URL referenced above is invalid (404). 😦
https://www.hex-rays.com/products/ida/support/tutorials/xnu_debugger_tutorial.pdf

https://www.hex-rays.com/products/ida/7.3/index.shtml

Eclypsium on firmware FISMA compliance

https://eclypsium.com/2019/05/13/fisma-compliance-firmware-security-best-practices/

William Leara on NIST 193

[…]The content of SP 800-193 should be considered required reading for professional BIOS/firmware engineers.[…]

William, a firmware engineer at Dell, has a new blog post summarizing NIST 193, NIST’s latest firmware security standard. It is nice to see someone else talking about it, other than myself. 😉 🙂

https://www.basicinputoutput.com/2019/06/nist-sp-800-193-platform-firmware.htm

https://csrc.nist.gov/publications/detail/sp/800-193/final

coreboot Coverity security fixes!

It appears the coreboot project has 2 Google Summer of Code projects going, one is this project, addressing security issues found by Coverity!

[…]My project is on making coreboot Coverity clean. Coverity is a free static-analysis tool for open source projects that searches for common coding mistakes and errors, such as buffer overruns, null pointer dereferences, and integer overflow. Coverity automatically analyzes the coreboot codebase and flags issues it finds, and my job is to classify them into bugs and false-positives and patch them if I can. You can check the Coverity overview for coreboot here, though seeing the issue tracker itself requires registration. At the beginning of the summer, coreboot had over 380 flagged issues, but it’s now down to 303, so we’re making progress! I plan to address 20-30 issues per week depending on the source component, which so far has gone surprisingly well (surprising, in the sense that coming into the summer I knew very little about coreboot or firmware development in general).[…]

Make magazine shuts down, Wayback Machine creates archive of issues

Make Magazine shuts down.

(AFAICT, no mention of this news on the official web site, but the Subscribe page is still taking orders.)

The Wayback Machine has started to create an archive.

https://archive.org/details/makemagazinearchive

Side Channel Attack Testbench Estimator (SCATE)

The US DoD has a new grant offered for a side-channel attack tool:

The Defense Advanced Research Projects Agency (DARPA) Small Business Programs Office (SBPO) is issuing an SBIR/STTR Opportunity (SBO) inviting submissions of innovative research concepts in the technical domain of side channel security. In particular, DARPA is interested in the feasibility of effective pre-silicon side channel and fault injection estimation. These vulnerabilities are of interest to this program only in the context of emissions from the parts of the design that perform on-chip cryptographic functions. This would permit these vulnerabilities to be identified and reduced to acceptable constraints at design time rather than with a costly chip re-spin after fabrication and test.

[…]The DARPA Common Evaluation Platform (CEP) is a publicly available RISC-V based System-on-a-Chip (SoC). It will be used as a reference design and may have to be extended for the purposes of this program. The reference point for the current state of the art of side channel attack simulation technology will be based on transistor level simulation with SPICE. All the baseline metrics will be based on leakage sources found with SPICE simulation of a meaningful number of traces on the cryptographic block(s) within the CEP.[…]

https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001119S0035-05/listing.html

GUSTAVE – Embedded OS kernel fuzzer


GUSTAVE is a fuzzing platform for embedded OS kernels. It is based on QEMU and AFL (and all of its forkserver siblings). It allows to fuzz OS kernels like simple applications. Thanks to QEMU, it is multi-platform. One can see GUSTAVE as a AFL forkserver implementation inside QEMU, with fine grain target inspection.

https://github.com/airbus-seclab/gustave

https://airbus-seclab.github.io/GUSTAVE_thcon/GUSTAVE_thcon.pdf