Spectre/Meltdown 007 humor

https://twitter.com/GlennF/status/949483191789735936

a bit more on Spectre and Meltdown

News press release from Intel yesterday:
https://newsroom.intel.com/news/firmware-updates-and-initial-performance-data-for-data-center-systems/

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

https://www.hardocp.com/news/2018/01/17/uefi_bios_updates_for_spectre

https://twitter.com/daniel_bilar/status/953969149734252545

 

Yuriy working on new CHIPSEC Spectre test

Nice to see some recent CHIPSEC activity, given all the recent related CVEs…
…But this is not from the CHIPSEC team, it is from ex-CHIPSEC team member Yuriy of Eclypsium.

Added new module checking for Spectre variant 2
The module checks if system is affected by Speculative Execution Side Channel vulnerabilities. Specifically, the module verifies that the system supports hardware mitigations for Branch Target Injection a.k.a. Spectre Variant 2 (CVE-2017-5715)

See source comments for more info.

https://github.com/c7zero/chipsec/commit/b11bce8a0ed19cbe1d6319ef9928a297b9308840

 

system-bus-radio: Transmits AM radio on computers without radio transmitting hardware

Transmits AM radio on computers without radio transmitting hardware. Some computers are intentionally disconnected from the rest of the world. This includes having their internet, wireless, bluetooth, USB, external file storage and audio capabilities removed. This is called “air gapping”. Even in such a situation, this program can transmit radio. Publicly available documents already discuss exfiltration from secured systems using various electromagnetic radiations. Run this using a 2015 model MacBook Air. Then use a Sony STR-K670P radio receiver with the included antenna and tune it to 1580 kHz on AM. You should hear the “Mary Had a Little Lamb” tune playing repeatedly.

https://github.com/fulldecent/system-bus-radio

https://fulldecent.github.io/system-bus-radio/

Hacking the fx-CP400 part 1: getting the firmware

 

https://the6p4c.github.io/2018/01/15/hacking-the-gc-part-1.html

https://www.casio.com/products/calculators/graphing/classpad-fx-cp400

SPOILER alert:

[…]Soon enough, I’ll write a Part 2 exploring the firmware image itself and the interesting SuperH architecture it runs upon. Thanks for reading this far. If there’s anything I can improve on in my writing, I’d love to hear it, send your constructive criticism my way!

INTEL-001-04 security advisory: Intel NUC and Infineon TPM

Intel® NUC Kit with Infineon Trusted Platform Module

Intel ID: INTEL-SA-00104
Product family: Intel® NUC Kit
Impact of vulnerability: Information Disclosure
Severity rating: Important
Original release: Jan 16, 2018
Last revised: Jan 16, 2018

Certain Intel® NUC systems contain an Infineon Trusted Platform Module (TPM) that has an information disclosure vulnerability as described in CVE-2017-15361.

Recently, a research team developed advanced mathematical methods to exploit the characteristics of acceleration algorithms for prime number finding, which are common practice today for RSA key generation. For more information please reference the public advisory issued by Infineon.

Intel highly recommends users make sure they have the appropriate Windows operating system patches to work around this vulnerability.

For customers that require a firmware upgrade please contact Intel Customer Support at https://www.intel.com/content/www/us/en/support.html for assistance.

All newly manufactured Intel® NUC systems that contain the Infineon TPM have been updated with the updated firmware from Infineon.

 

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00104&languageid=en-fr

 

Tianocore Security Advisory 27: Minnowboard UEFI Variable Deletion/Corruption

Tianocore EDK2 security advisory page has been updated, for the first time since 2016! It looks like a single entry:

https://edk2-docs.gitbooks.io/security-advisory/content/

27. UEFI Variable Deletion/Corruption

Description: Input validation error in MinnowBoard 3 Firmware versions prior to 0.65 allow local attacker to cause denial of service via UEFI APIs.

Recommendation: This update improves input validation by firmware and is strongly recommended. For firmware development projects, incorporate the updates in https://github.com/tianocore/edk2-platforms/tree/devel-MinnowBoard3-UDK2017. When using MinnowBoard 3, update to version 0.65 or later. Updated firmware is available at https://firmware.intel.com/projects/minnowboard3

Acknowledgments: Reported by Intel.

References: CVE-2017-5699

The referenced CVE is still empty, hopefully someone at Intel/MITRE/NIST is going to take care of that sometime.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5699
https://nvd.nist.gov/vuln/detail/CVE-2017-5699

 

Redfish 2017.3 released

Redfish Specification v1.4.0 is released.

 

DMTF’s Redfish Version 2017.3 is now available. Version 2017.3 adds new schemas for BootOption, Assembly, Protocol, and more.

https://www.dmtf.org/sites/default/files/DSP8010_2017.3.zip
http://www.dmtf.org/standards/redfish
http://redfish.dmtf.org/
https://www.dmtf.org/content/redfish-release-january-2018

 

Opensource.com: analyzing the Linux boot process

Nice introductory article.

Analyzing the Linux boot process
16 Jan 2018
Alison Chaiken
The oldest joke in open source software is the statement that “the code is self-documenting.” Experience shows that reading the source is akin to listening to the weather forecast: sensible people still go outside and check the sky. What follows are some tips on how to inspect and observe Linux systems at boot by leveraging knowledge of familiar debugging tools. Analyzing the boot processes of systems that are functioning well prepares users and developers to deal with the inevitable failures.[…]

https://opensource.com/article/18/1/analyzing-linux-boot-process

Summary of early kernel boot process.

AptioFix: drivers for using Aptio to boot macOS

AptioFix: AptioFixPkg drivers fixing certain UEFI APTIO Firmware issues relevant to booting macOS.

WARNING: The code in this repository should be considered to be a proof of concept draft quality, and is only intended to be used as a software implementation guide. Due to the lack of time, this codebase may contain partially understood reverse-engineering samples, almost no documentation, hacks, and absolute ignorance of EDK2 codestyle.

AptioInputFix: Reference driver to shim AMI APTIO proprietary mouse & keyboard protocols for File Vault 2 GUI input support.

Features
* Sends pressed keys to APPLE_KEY_MAP_DATABASE_PROTOCOL
* Fixes mouse movement via EFI_SIMPLE_POINTER_PROTOCOL
[…]

https://github.com/vit9696/AptioFixPkg

Dumping the Playstation4 kernel

Dumping a PS4 Kernel in “Only” 6 Days

Filed under ps4 vulnerability exploit

What if a secure device had an attacker-viewable crashdump format?
What if that same device allowed putting arbitrary memory into the crashdump?
Amazingly, the ps4 tempted fate by supporting both of these features!
Let’s see how that turned out…
Crashdumps on PS4

The crash handling infrastructure of the ps4 kernel is interesting for 2 main reasons:
It is ps4-specific code (likely to be buggy)
If the crashdump can be decoded, we will gain very useful info for finding bugs and creating reliable exploits

On a normal FreeBSD system, a kernel panic will create a dump by calling kern_reboot with the RB_DUMP flag. This then leads to doadump being called, which will dump a rather tiny amount of information about the kernel image itself to some storage device. On ps4, the replacement for doadump is mdbg_run_dump, which can be called from panic or directly from trap_fatal. The amount of information stored into the dump is gigantic by comparison – kernel state for all process, thread, and vm objects are included, along with some metadata about loaded libraries. Other obvious changes from the vanilla FreeBSD method are that the mdbg_run_dump encodes data recorded into the dump on a field-by-field basis and additionally encrypts the resulting buffer before finally storing it to disk.[…]

https://fail0verflow.com/blog/2017/ps4-crashdump-dump/

 

NVidia symbol server for Windows binaries

Microsoft’s debugger stores symbols in sidecar files separate from the executable. They are stored on the Microsoft Symbol Server. For third party symbols, things are not as good. NVidia has improved things for their drivers, though:

https://developer.nvidia.com/nvidia-driver-symbol-server

https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588(v=vs.85).aspx
https://support.microsoft.com/en-us/help/311503/use-the-microsoft-symbol-server-to-obtain-debug-symbol-files
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/microsoft-public-symbols

See-also:

AFAIK, Mozilla was the first open source project to setup a symbol server:
https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server

https://gpuopen.com/amd-driver-symbol-server/
https://support.citrix.com/article/CTX118622

Firmware update for Fuji X-T1 devices


http://www.symbolsource.org/Public/Home/VisualStudio
https://nuget.smbsrc.net/
https://github.com/electron/electron/blob/master/docs/development/setting-up-symbol-server.md
https://area.autodesk.com/blogs/the-3ds-max-blog/debug_symbol_server_for_3ds_max_2012/
https://www.chromium.org/developers/how-tos/debugging-on-windows

 

Eclypsium at OPCDE: UEFI BIOS firmware analysis at scale

UEFI BIOS firmware analysis at scale
By Oleksandr Bazhaniuk Chief Technology Officer, Eclypsium

Vulnerabilities in system firmware allow adversaries to bypass almost any protection used in the operating system, virtual machine manager and other software. System firmware attacks bypass Secure Boot, software based full-disk encryption and virtualization-based security. Threats exploiting such vulnerabilities can extract secrets from operating system memory, subvert secure/trusted VMs and even hypervisors, install stealthy and persistent implants and even brick physical systems. We’ve discovered a number of such vulnerabilities in the past and developed an open source framework to automate analysis. Despite these risks there are still many modern systems which do not protect their main BIOS/UEFI firmware. We decided to analyze thousands of UEFI firmware updates from multiple platform vendors and discovered hundreds of vulnerabilities, indicating that corresponding systems lack any basic firmware protections in ROM or signed firmware updates. We’ll present the process, findings and limitations of such offline analysis of vendor firmware update images.

http://www.opcde.com/agenda/

EternalRed0’s Unicorn Engine tutorial

Unicorn Engine tutorial

Jan 14, 2018

In this tutorial you will learn how to use Unicorn Engine by solving practical exercises. There are 4 exercises and I will solve the first exercise for you. For the others I am providing hints and solutions, which you can obtain by clicking the spoiler buttons.[…]

http://eternal.red/2018/unicorn-engine-tutorial/

http://www.unicorn-engine.org/

https://github.com/unicorn-engine/unicorn