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

 

NISTIR 8176: Linux app container security

Application Containers are slowly finding adoption in enterprise IT infrastructures. Security guidelines and countermeasures have been proposed to address security concerns associated with the deployment of application container platforms. To assess the effectiveness of the security solutions implemented based on these recommendations, it is necessary to analyze those solutions and outline the security assurance requirements they must satisfy to meet their intended objectives. This is the contribution of this document. The focus is on application containers on a Linux platform.

Keywords: application container; capabilities; Cgroups; container image; container registry; kernel loadable module; Linux kernel; namespace; TPM

 

https://csrc.nist.gov/publications/detail/nistir/8176/final

https://csrc.nist.gov/News/2017/NIST-Releases-NISTIR-8176

http://doi.org/10.6028/NIST.IR.8176

 

Dell seeks firmware architect

Platform Software Senior Principal Engineer/BIOS Architect (17000X39)

[…]You’ll apply skills and experience across the full cycle of software development (specification development and review, debug and validation) to enable features and capabilitiesof platforms in areas like UEFI drivers, thermal, power management, security, manageability, manufacturability, configurability and embedded controllers.
[…]
* Work with Industry forums for spec development like UEFI, DMTF, PCI Sig, ACPI, etc
* Ability to take ownership of overall UEFI platform design throughout the platform lifecycle
* 12+ years experience in BIOS / firmware SW development
* UEFI Programming expertise
* Low level programming capability -system/motherboard/device/chipset level
* Experience with analyzers and other HW tools to debug complex system SW issues
[…]

https://jobs.dell.com/job/-/-/375/5929831

PreOS presentation from SeaGL online

Last week Paul English of PreOS Security gave a presentation at SeaGL Conference (spelled with the RMS-preferred prefix, “Seattle GNU/Linux Conference”, pronounced like the bird “Seagull”). The presentation was about about firmware defensive skills. Whereas my previous presentation presumed an audience of enterprise (SysAdmins, SREs, Blue Teams, or DFIR), Paul’s talk presumed an audience of end-users, with no enterprise to back them up.

Alas, with most SeaGL presentations, this presentation was not video/audio-taped. His blog post has pointer to his slides.

His blog post also mentions brief status update on the sysadmin ebook that Paul is driving, he’s nearly ready, it’ll be nice to have this resource available.

Also, note that the PreOS Security web site has been revamped. All known HTTP/HTTPS problems have been resolved, and the blog backlog is getting flushed.

https://preossec.com/SeaGL-2017/