Hardened Linux and firmware

I recently noticed Hardened Linux, because they were calling CHIPSEC. I just noticed they have some informational pages with info on Intel ME/AMT/UEFI and other technologies:

https://github.com/hardenedlinux/firmware-anatomy

https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/firmware_security.md

https://github.com/hardenedlinux/firmware-anatomy/tree/master/hack_ME

https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/me_info.md

https://hardenedlinux.github.io/about3/

https://hardenedlinux.github.io/system-security/2017/07/31/firmware_chipsec.html

https://translate.google.com/translate?hl=enu&u=https://hardenedlinux.github.io/system-security/2017/07/31/firmware_chipsec.html

 

AMI supports AMD Threadripper

AMI has a few press releases about AMD Rhyzen support:

https://ami.com/en/tech-blog/amd-ryzen–aptiov/

https://ami.com/en/news/press-releases/american-megatrends-aptio-v-uefi-firmware-supports-amd-ryzen-threadripper-highperformance-gaming-processor-product-line/

new book on Apple reversing/debugging

Advanced Apple Debugging & Reverse Engineering
Explore code through LLDB, Python and DTrace, to discover more about any program than you ever thought possible.

https://store.raywenderlich.com/products/advanced-apple-debugging-and-reverse-engineering?_ga=2.129698885.852507492.1502412840-255700375.1502412840

 

McAfee releases CHIPSEC 1.3.2

New or Updated Modules:
* Updated X64 Python for UEFI Shell

New or Updated Functionality:
* Updated FREG definitions
* Added mmap support to kernel module and chipsec device

Fixes:
* Fixed memory reads with kernel 4.8+
* Fixed version display in chipsec_util
* Fixed UEFI Shell X64 calling convention for SW SMI generation
* Fixed range check in bios_wp
* Fixed P2SB register accesses
* Fixed IOCTL_WRMMIO for x86_64 in Linux driver

Above relnotes aside, there are some other smaller features not listed above, in the changelog:
https://github.com/chipsec/chipsec/commits/master

I wish the CHIPSEC team signed their binary-only release of CPython 2.7x for UEFI, and/or included their build tree of the EDK2 that generates this, so we can build our own, hopefully ‘reproducably’.

I don’t see any ARM support[1]. Obviously, the title of below blog post was wrong, it was not released at Black Hat, AFAICT. Was this patch lost in Las Vegas? Is the ARM code a non-McAfee patch by Eclypsium that won’t be upstreamed into the GPL’ed CHIPSEC codebase? I wish I knew…

[1] https://firmwaresecurity.com/2017/07/25/chipsec-for-arm-to-be-released-at-black-hat/

AMD AGESA firmware concern?

AGESA is the set of binaries used by most AMD systems. Similar, in concept, to Intel’s FSP.

3mdeb points out that the AGESA docs seem to indicate that unbalanced allocation/free of some AGESA resources could have a negative system impact:

The creation and removal of the structure storage depends upon the host environment calling procedure using the AmdCreateStruct and AmdReleaseStruct procedures. Failure to release a structure can cause undesired outcomes.

AGESA – AMD Support & Drivers

Click to access 44065_Arch2008.pdf

Opal vulnerability in Intel/HPI/Lenovo/Dell drives.

Two security advisories from Intel on SSDs. Intel aside, a few OEMs are involved.

—-

Intel® SSD 540s, Intel® SSD Pro 5400s, Intel® SSD E 5400s, and Intel® SSD DC S3100 data corruption vulnerability

Intel ID: INTEL-SA-00079
Product family: Intel® Solid State Drive Consumer, Professional, Embedded, Data Center
Impact of vulnerability: Denial of Service
Severity rating: Moderate
Original release: Aug 08, 2017

A vulnerability was identified in the Intel® Solid-State Drive 540s Series, Intel® Solid State Drive Pro 5400s Series, Intel® Solid State Drive E 5400s Series and Intel® Solid State Drive DC S3100 Series leading to a potential data corruption issue. In the Intel® SSD 540s, Intel® Pro 5400s, Intel® E 5400s, and Intel® DC S3100 Series, a firmware issue in ATA locked and Opal activated drives may allow a physical attacker to cause data corruption or data loss leading to a denial of service condition. This issue applies only to systems with ATA locked and Opal activated drives.[…]

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

—-

Intel® SSD Pro 6000p Series data corruption vulnerability

Intel ID: INTEL-SA-00078
Product family: Intel® Solid State Drive Professional
Impact of vulnerability: Denial of Service
Severity rating: Moderate
Original release: Aug 08, 2017

A vulnerability was identified in the Intel® Solid State Pro 6000p Series leading to a potential data corruption issue. Intel® SSD Pro 6000p Series contains a firmware issue in Opal activated drives which allows a physical attacker to cause data corruption or data loss leading to a denial of service condition. This issue applies only to systems with Opal activated drives.[…]

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

A Life Without Vendors Binary Blobs, part1

This blogpost will be about my first steps with coreboot and libreboot and a life with as few proprietary firmware blobs as possible. My main motivation were the latest headlines about fancy firmware things like Intel ME, Computrace and UEFI backdoors. This post is not intended to be about a as much as possible hardened system or about coreboot/libreboot being more secure, but rather to be able to look into every part of software running on that system if you want to.[…]A followup will involve different payloads like SeaBios or Tiano Core (UEFI) to be tested, maybe I can get even more from this old piece of hardware! So look out for my next blog post about my journey into coreboot! -Jann

A Life Without Vendors Binary Blobs

 

Barr Group’s Embedded C Coding Standard how has free options

Book available in 4 flavors, 2 are free, online HTML and downloadable PDF.

Barr Group’s Embedded C Coding Standard was developed to minimize bugs in firmware by focusing on practical rules that keep bugs out–while also improving the maintainability and portability of embedded software. The coding standard details a set of guiding principles as well as specific naming conventions and other rules for the use of data types, functions, preprocessor macros, variables and much more. Individual rules that have been demonstrated to reduce or eliminate certain types of bugs are highlighted.

https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard

https://barrgroup.com/blog-category/coding-standards

https://barrgroup.com/blog

 

Corona-X UEFI Bootloader

Corona makes a cross-platform 2D game engine. Wikipedia says: “Corona SDK is a software development kit (SDK) developed by Corona Labs Inc. Corona SDK allows software programmers to build mobile applications for iOS, Android, and Kindle, desktop applications for Windows and OS X, and connected TV applications for Apple TV and Android TV. Corona uses integrated Lua layered on top of C++/OpenGL to build graphic applications. The software has two subscription tiers: the free Corona SDK and the paid Corona Enterprise. A Corona Enterprise subscription adds the ability to use native code in app development.”

They also have a UEFI-based bootloader, not sure how this ties into their game engine…

Corona-X UEFI Bootloader and Kernel Loader
https://github.com/Corona-X/CXSystemLoader

https://coronalabs.com/

HellsRansomeware virus, aka UEFI ransomeware

I don’t know much about this other than below text. Heck, the below web site may be malware-laden, I’m not sure, click at your own risk.

https://twitter.com/2spyware/status/894859391979196416

http://www.2-spyware.com/remove-hellsransomware-virus.html

“HellsRansomware virus, or alternatively called as UEFI ransomware, is another file-encrypting threat ready to lock sensitive users’ data. To IT security specialists’ amusement, the developers claim the virus to be “the only legit ransomware which will give you your files back unlike the others which do not.”

 

uEmu: Unicorn-based emulator plugin for IDA

uEmu is a tiny cute emulator plugin for IDA based on unicorn engine.

Supports following architectures out of the box: x86, x64, ARM, ARM64.

What is it GOOD for?
* Emulate bare metal code (bootloaders, embedded firmware etc)
* Emulate standalone functions

https://github.com/alexhude/uEmu

UEFI BoF at LPC

UEFI Forum member Harry Hsiung of Intel will be presenting a Birds of a Feather presentation titled “The State of UEFI Technology.” The session will cover the latest UEFI specifications and variables, as well as features like HTTP Boot, Wi-Fi, Bluetooth, NVDIMM, Secure Boot and capsule update. Attendees will also learn about the latest UEFI SCT updates and other tests like the Linux UEFI Validation (LUV) and the Linux Firmware Test Suite (FWTS).

http://www.uefi.org/events/upcoming

http://www.uefi.org/node/3738

https://www.linuxplumbersconf.org/2017/

Insignary launches TruthIsInTheBinary.com service for OEMs

Code Scanning Service To Neutralize the IoT Security Ticking Time-Bomb
Aug. 8, 2017, 02:00 AM
SUNNYVALE, CA–(Marketwired – August 08, 2017) – Insignary, the global leader in binary-level open source software security and compliance, unveiled today its free, open source software binary code scanning service TruthIsIntheBinary.com. Powered by Insignary Clarity™ binary code scanning software, TruthIsIntheBinary.com enables OEMs, developers and users to quickly and easily scan open source software in their embedded applications and IoT devices. TruthIsIntheBinary.com identifies SambaCry, Devil’s Ivy, Heartbleed, Ghost and Venom, among more than 91,000 known security vulnerabilities — helping to neutralize what industry experts see as an IoT security “ticking time-bomb.” TruthIsIntheBinary.com is easy to use. OEMs and developers start by uploading an uncompressed binary file to the site. Any executable file created to run on 99% of existing computing platforms may be scanned — including smart phone apps people download from app stores. The service scans the software in just a few minutes. Users receive a report of the scanned software that includes the number of potential security issues and their level of severity. With this information, OEMs and developers can look to address the security vulnerabilities with patches or newer versions of the software.[…]

https://www.insignary.com/

https://testyourbinary.insignary.com/#/trial

http://markets.businessinsider.com/news/stocks/Insignary-Unveils-TruthIsIntheBinary-TM-A-No-Cost-Open-Source-Software-Binary-Code-Scanning-Service-To-Neutralize-the-IoT-Security-Ticking-Time-Bomb-1002239042

vTZ: Virtualizing ARM TrustZone

https://twitter.com/security_Kiwi/status/894174335493124096

vTZ: Virtualizing ARM TrustZone
Zhichao Hua, Jinyu Gu, Yubin Xia, Haibo Chen, Binyu Zang, Haibing Guan

ARM TrustZone, a security extension that provides a secure world, a trusted execution environment (TEE), to run security-sensitive code, has been widely adopted in mobile platforms. With the increasing momentum of ARM64 being adopted in server markets like cloud, it is likely to see TrustZone being adopted as a key pillar for cloud security. Unfortunately, TrustZone is not designed to be virtualizable as there is only one TEE provided by the hardware, which prevents it from being securely shared by multiple virtual machines (VMs). This paper conducts a study on variable approaches to virtualizing TrustZone in virtualized environments and then presents vTZ, a solution that securely provides each guest VM with a virtualized guest TEE using existing hardware. vTZ leverages the idea of separating functionality from protection by maintaining a secure co-running VM to serve as a guest TEE, while using the hardware TrustZone to enforce strong isolation among guest TEEs and the untrusted hypervisor. Specifically, vTZ uses a tiny monitor running within the physical TrustZone that securely interposes and virtualizes memory mapping and world switching. vTZ further leverages a few pieces of protected, self-contained code running in a Constrained Isolated Execution Environment (CIEE) to provide secure virtualization and isolation among multiple guest TEEs. We have implemented vTZ on Xen 4.8 on both ARMv7 and ARMv8 development boards. Evaluation using two common TEE-kernels (secure kernel running in TEE) such as seL4 1 and OP-TEE shows that vTZ provides strong security with small performance overhead.

Click to access fetch.php

Alex on Intel segmentation

https://twitter.com/aionescu/status/894547724904931328

https://twitter.com/aionescu/status/894547838717366272

https://twitter.com/aionescu/status/894475252625018882

[…]What I discovered completely changed my understanding of 64-bit Long Mode semantics and challenged many assumptions I was making – pinging a few other experts, it seems they were as equally surprised as I was (even Mateusz”j00ru” Jurczyk wasn’t aware!). Throughout this blog post, you’ll see how x64 processors, even when operating in 64-bit long mode[…]

http://www.alex-ionescu.com/?p=340

See-also:

HTTP Boot support in Tianocore

 

 

Dorian Cussen’s Android Security Reference

I just noticed this Android Security Reference. It has a few pages on boot phase:

https://github.com/doridori/Android-Security-Reference

https://github.com/doridori/Android-Security-Reference/blob/master/boot/verified_boot.md

https://github.com/doridori/Android-Security-Reference/blob/master/boot/bootloader.md

https://github.com/doridori/Android-Security-Reference/blob/master/boot/boot_process.md

http://kodroid.com/