OpenPOWER firmware updates using ZMODEM

Stewart Smith of IBM has a new blog post about adding ZMODEM support to OpenPOWER firmware.

From checkin: This enables the use of rz/sz to send/receive files using ZMODEM. This enables error detection and correction when using the console to transfer files to/from the host.

From blog:

ZMODEM saves the day! Or, why my firmware for a machine with a CPU from 2017 contains a serial file transfer protocol from the 1980s

Recently, I added the package lrzsz to op-build in this commit. This package provides the rz and sz commands – for receive zmodem and send zmodem respectively. For those who don’t know, op-build builds a firmware image for OpenPOWER machines, and adding this package adds the commands to the petitboot shell (the busybox environment you get when you “exit to shell” from the boot menu).[…]

ZMODEM saves the day! Or, why my firmware for a machine with a CPU from 2017 contains a serial file transfer protocol from the 1980s


https://en.wikipedia.org/wiki/ZMODEM

 

What’s next, a UEFI runtime service for Kermit, using CKermit? UEFI NNTP Boot, using signed images on alt.binaries.firmware.*? 🙂

more on Infineon TPM issue (ROCA)

http://blog.ptsecurity.com/2017/10/a-major-flaw-in-popular-encryption.html

ROCA: Vulnerable RSA generation (CVE-2017-15361)

A newly discovered vulnerability in generation of RSA keys used by a software library adopted in cryptographic smartcards, security tokens and other secure hardware chips manufactured by Infineon Technologies AG allows for a practical factorization attack, in which the attacker computes the private part of an RSA key. The attack is feasible for commonly used key lengths, including 1024 and 2048 bits, and affects chips manufactured as early as 2012, that are now commonplace. Assess your keys now with the provided offline and online detection tools and contact your vendor if you are affected. Major vendors including Microsoft, Google, HP, Lenovo, Fujitsu already released the software updates and guidelines for a mitigation. Full details including the factorization method will be released in 2 weeks at the ACM CCS conference as ‘The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli’ (ROCA) research paper.

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

 

Where there’s a JTAG, there’s a way: obtaining full system access via USB

WHERE THERE’S A JTAG, THERE’S A WAY: OBTAINING FULL SYSTEM ACCESS VIA USB
Maxim Goryachy and Mark Ermolov
Everyone makes mistakes. These words are certainly true for developers involved in low-level coding, where such common tools as print debugging and software debuggers run into limits. To solve this problem, hardware developers use in-circuit emulators or, if available on the target platform, the JTAG debugging interface (IEEE1149.1 [1]). Such debugging mechanisms first appeared in the 1980s [2]. Over time, microchip vendors extended the functionality of these interfaces. This allowed developers to obtain detailed information on power consumption, find bottlenecks in high-performance algorithms, and perform many other useful tasks. Hardware debugging tools are also of interest to security researchers. These tools grant low-level system access and bypass important security protections, making it easier for researchers to study a platform’s behavior and undocumented features. Unsurprisingly, these abilities have attracted the attention of intelligence services as well.[…]

Click to access Where-theres-a-JTAG-theres-a-way.pdf

 

OpenXT

Linux.com has a nice article on Xen, Linux, TPM, and TXT. It also mentions the OpenXT toolkit.

https://www.linux.com/blog/event/elce/2017/10/device-we-trust-measure-twice-compute-once-xen-linux-tpm-20-and-txt

OpenXT is an open-source development toolkit for hardware-assisted security research and appliance integration. Released as Open-Source Software (OSS) in June 2014, OpenXT stands on the shoulders of Xen Project and OpenEmbedded. It is derived from XenClient XT, which was first released in May 2011. It includes hardened Xen VMs that can be configured as a user-facing virtualization appliance, for client devices with Linux and/or Windows guests. It has been used to develop managed software appliances to isolate demanding graphics workloads, untrusted workloads and multiple networks on a single laptop or desktop. OpenXT is optimized for x86 devices with Intel VT-d, TXT (Trusted Execution Technology) and a TPM. OpenXT is being developed to meet the varied needs of the security and virtualization communities, as a toolkit for the configurable disaggregation of operating systems and user workflows. Client appliances developed on OpenXT can contain a mixture of open-source and proprietary software, supporting a range of business models.[…]

https://openxt.atlassian.net/wiki/spaces/OD/pages/10747915/What+is+OpenXT

 

PlayStation4 kernel exploit

https://twitter.com/revskills/status/921387165862518784

2017-10-19
The First PS4 Kernel Exploit: Adieu

Plenty of time has passed since we first demonstrated Linux running on the PS4. Now we will step back a bit and explain how we managed to jump from the browser process into the kernel such that ps4-kexec et al. are usable. Over time, ps4 firmware revisions have progressively added many mitigations and in general tried to lock down the system. This post will mainly touch on vulnerabilities and issues which are not present on the latest releases, but should still be useful for people wanting to investigate ps4 security. As previously explained, we were able to get a dump of the ps4 firmware 1.01 kernel via a PCIe man-in-the-middle attack. Like all FreeBSD kernels, this image included “export symbols” – symbols which are required to perform kernel and module initialization processes. However, the ps4 1.01 kernel also included full ELF symbols (obviously an oversight as they have been removed in later firmware versions). This oversight was beneficial to the reverse engineering process, although of course not a true prerequisite. Indeed, we began exploring the kernel by examining built-in metadata in the form of the syscall handler table – focusing on the ps4-specific entries. After some recovering of structures, we discovered that a large portion of the ps4-specific syscalls are little more than wrappers to what is essentially a hash table API. The API contains the following interface:[…]

https://fail0verflow.com/blog/2017/ps4-namedobj-exploit/

Linux kernel lockdown patch

David Howells of Red Hat has posted the latest version of the ‘kernel lockdown’ patch to the Linux-EFI mailing list. The latest patch includes a manpage, see the LWN article below for text. For more info, see the full 27-part patch on the linux-efi mailing list.

AFAICT, no Linux distros use this patch. Why?!

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available. Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysRq combination to lift the lockdown. On x86 this is SysRq+x. The keys must be pressed on an attached keyboard. Enabling CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT will cause EFI secure boot to trigger kernel lockdown.

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down
http://vger.kernel.org/majordomo-info.html
https://lwn.net/Articles/736910/

Qubes MSI support for PCI device pass-through with stub domains

MSI support for PCI device pass-through with stub domains
by Simon Gaiser
In this post, we will describe how we fixed MSI support for VMs running in HVM mode in Qubes 4.0. First, allow us to provide some background about the MSI feature and why we need it in the first place.[…]

https://www.qubes-os.org/news/2017/10/18/msi-support/

 

WeLiveSecurity: Malware in firmware: how to exploit a false sense of security

Malware in firmware: how to exploit a false sense of security

By Cassius Puodzius posted 19 Oct 2017 – 01:52PM

When it comes to cyberthreats, we in ESET-LATAM Research often see ransomware, banking trojans (especially in my home country – Brazil), botnets or worms. As a consequence, other types of dangerous malware that run inconspicuously might get less of our attention; as is the case with firmware malware or bootkits. Bootkits run before the OS loads and target OS components in order to modify or subvert their behavior. The fact that bootkits execute early in the system boot gives them the ability to remain stealthy and be persistent, surviving hard drive reformatting or OS reinstallation.[…]

https://www.welivesecurity.com/2017/10/19/malware-firmware-exploit-sense-security/

 

SMM presentation at ACSA2017

Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode

Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet

Highly privileged software, such as firmware, is an attractive target for attackers. Thus, BIOS vendors use cryptographic signatures to ensure firmware integrity at boot time. Nevertheless, such protection does not prevent an attacker from exploiting vulnerabilities at runtime. To detect runtime attacks, we propose an event-based behavior monitoring approach that relies on an isolated co-processor. We instrument the code executed on the main CPU to send information about its behavior to the monitor. This information helps to resolve the semantic gap issue. Our approach is generic. It can monitor different targets (e.g., firmware, kernel, or hypervisor) and does not depend on a specific model of the behavior. In this work, we apply this approach to detect attacks targeting the System Management Mode (SMM), a highly privileged x86 execution mode executing firmware code at runtime. We use the control-flow of the code as a model of its behavior. We instrument two open-source firmware implementations: EDK II and coreboot. We evaluate the ability of our approach to detect state-of-the-art attacks and its runtime execution overhead by simulating an x86 system coupled with an ARM Cortex A5 co-processor. The results show that our solution detects intrusions from the state of the art, without any false positives, while remaining acceptable in terms of performance overhead in the context of the SMM (i.e., less than the 150 µs threshold defined by Intel).

https://www.acsac.org/2017/openconf/modules/request.php?module=oc_program&action=summary.php&id=181

https://www.acsac.org/2017/

 

more on Infineon TPM issue

Re: the recent Infineon TPM problem, more and more downstream problems are being discovered. The main news presses have lots of stories on this now.

 

https://twitter.com/dangoodin001/status/920137950528135168

UK gov guidance on automating UEFI Firmware Updates

https://twitter.com/CysekSentinel/status/920640632271409152

 

Automating UEFI Firmware updates

In our previous blog post we talked about the state of UEFI firmware running on Windows laptops attached to one of our research networks. In case you don’t recall the conclusion: We were surprised that many of the devices were running out-of-date firmware and decided to investigate ways in which automated UEFI firmware updates could be scaled to meet the needs of an Enterprise. This blog tells the story of what happened next.[…]

https://www.ncsc.gov.uk/blog-post/automating-uefi-firmware-updates

 

Fastly Security Speaker Series

If you are in San Francisco later this month, the Fastly Security Speaker Series has a new event, with two firmware security-related presentations!

https://www.eventbrite.com/e/fastly-security-speaker-series-part-3-tickets-38787460338

We’re excited to announce the third installment of the Fastly Security Speaker Series. Fastly will bring some of the most innovative and thoughtful security researchers to San Francisco to share their work. Speakers include Alex Bazhaniuk, of Eclypsium, Inc. and Stephen Checkoway, whose most recent papers include: A Systematic Analysis of the Juniper Dual EC Incident, Run-DMA and On the Security of Mobile Cockpit Information Systems.

Talk 1: Exploring Your System Deeper
Alex Bazhaniuk of Eclypsium, Inc.

Ever wanted to explore deep corners of your system but didn’t know how? This could include system boot firmware, ROMs on expansion cards, I/O devices and their firmware, microprocessors, embedded controllers, memory devices, low-level hardware interfaces, virtualization and hypervisors — you could discover if any of these have known vulnerabilities, configured insecurely, or even discover new vulnerabilities and develop proof-of-concept exploits to test these vulnerabilities. Ultimately, you can verify security state of platform components of your system and how effective the platform security defenses are: hardware or virtualization based TEE, secure or trusted boot, firmware anti-tampering mechanisms, hypervisor based isolation… Or maybe you just want to explore hardware and firmware components your system has. CHIPSEC framework can help you with all of that. Since its release at CanSecWest 2014, significant improvements have been made in the framework — from making it easy to install and use to adding lots of new security capabilities. We’ll go over certain representative examples of what you can do with it such as finding vulnerabilities in SMM firmware, analyzing UEFI firmware vulnerabilities, testing hardware security mechanisms of the hypervisors, finding backdoors in UEFI images, and more.

Talk 2: The Juniper Dual EC incident
Stephen Checkoway, Assistant Professor at University of Illinois at Chicago

In December 2015, Juniper Networks announced that unknown attackers had added unauthorized code to ScreenOS, the operating system for their NetScreen VPN routers. This code created two vulnerabilities: an authentication bypass that enabled remote administrative access, and a second vulnerability that allowed passive decryption of VPN traffic. Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker. The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator’s output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack. In this talk, Stephen Checkoway presents the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. This work sits at the intersection of cryptography, protocol design, and forensics, and is a fascinating look at a problem that received a great deal of attention at the time but whose details are less well known.

KRACK Attacks: WPA2 vulnerability

Monday morning a new WiFi vulnerability is going to be released. Embedded devices and WiFi-enabled firmware is going to be needing your attention…

https://www.us-cert.gov/ncas/current-activity/2017/10/16/CERTCC-Reports-WPA2-Vulnerabilities

http://www.kb.cert.org/vuls/id/228519

https://www.krackattacks.com/

https://github.com/vanhoefm/krackattacks

https://char.gd/blog/2017/wifi-has-been-broken-heres-the-companies-that-have-already-fixed-it

ACPI 6.2 errata A released

FWTS is the recommended ACPI test tool by the UEFI Forum!

Here’s the info from the changelog:
Missing space in title of ACPI RAS Feature Table (RASF)
Typos in Extended PCC subspaces (types 3 and 4)
Add a new NFIT Platform Capabilities Structure
PPTT ID Type Structure offsets
Remove bits 2-4 in the Platform RAS Capabilities Bitmaptable
Region Format Interface Code description
Remove support for multiple GICD structures
PDTT typos and PPTT reference Revision History
Minor correction to Trigger Action Table
General Purpose Event Handling flow

http://uefi.org/specifications

If you really want to understand what has changed in the ACPI and UEFI specs, you need to join the UEFI Forum, so you can access the Mantis bug database and understand what the Mantis numbers in the ACPI and UEFI spec revision history refer to…

 

PCILeech FPGA released!

PCILeech FPGA contains software and HDL code for FPGA based devices that may be used together with the PCILeech Direct Memory Access (DMA) Attack Toolkit. Using FPGA based devices have many advantages over using the USB3380 hardware that have traditionally been supported by PCILeech. FPGA based hardware provides full access to 64-bit memory space without having to rely on a kernel module running on the target system. FPGA based devices are also more stable compared to the USB3380. FPGA based devices may also send raw PCIe Transaction Layer Packets TLPs – allowing for more specialized research. For information about PCILeech itself please check out the PCILeech project.

https://github.com/ufrisk/pcileech-fpga

 

Alex blogs and updates UEFITool!

Double entry for Alex: he’s got a new blog post on Intel Boot Guard, plus he’s updated UEFITool!

“[…]Today I released a new build of UEFITool with visual validation of Intel Boot Guard coverage. The code pushed to the github repository. A standalone binary of UEFITool can be downloaded here.[…]”

https://github.com/LongSoft/UEFITool

View at Medium.com