https://twitter.com/MrChromebox/status/823740094158962690
“Custom coreboot firmware and firmware utilities for your Chromebook/Chromebox”
Category: Uncategorized
MalDuino: Arduino-based BadUSB
https://www.indiegogo.com/projects/malduino-badusb-arduino-usb#/
“MalDuino is an arduino-powered USB device which has keyboard injection capabilities. Once plugged in, MalDuino acts as a keyboard, typing commands at superhuman speeds. What’s the point? You could gain a reverse shell, change the desktop wallpaper, anything is possible. For penetration testers, hobbyists and pranksters the MalDuino will serve you well!”
EDK2 test harness
Michael Kinney of Intel has created an edk2-test branch, to focus on testing!
I am creating a new branch in edk2-staging called edk2-test. The purpose of this branch is to develop a test harness, test case SDK, and library of test cases that can be used as part of edk2 validation. The initial version of this test harness is compatible with binary releases of the PI SCTs and UEFI SCTs, are native edk2 packages with no dependencies on the EdkCompatibilityPkg, and the test harness runs using the latest version of the UEFI Shell.
Additional work items:
* Update to take advantage of latest edk2 features/libraries.
* Update for all supported CPU types
* Update for all supported compilers
* Review initial test harness features and determine what features should be dropped and what new features should be added.
* Determine where the test harness, test case SDK, and test cases should live once the initial functional and quality criteria are met. Could be packages in the edk2 repo or packages in a new edk2-test repo. Other options???
* Resolve compatibility issues with binary releases of the PI SCTs and UEFI SCTs.
* Update test harness to support PEI tests
* Update test harness to support Runtime tests
* Update test harness to support SMM tests
* Optimize performance of the test harness and tests.
librecore
Phoronix has a new article about librecore, a free-as-in-freedom firmware project:
librecore is a distribution of Free/Libre firmware recipes for compiling and generating firmware for devices. The intended targets for the firmware include only those which can be run in total freedom by the user. This means that librecore firmware is distributed as source code, and does not include any binary blobs. The purpose of this project is to push the limits of software freedom in boot firmware. librecore is free firmware not unlike coreboot however with a different focus. While we collaborate with coreboot and share mature code to further these goals, our focus is more around maintainability and feature completeness of more libre hardware platforms such as POWER, SPARC, RISC-V and other non-x86 ISA’s.
https://github.com/librecore-org/librecore-org.github.io
http://www.phoronix.com/scan.php?page=news_item&px=Librecore-Formation
Read the Reddit thread and the Phoronix Forums for more background beyond the main article.:
“[…]I am one of the core developers of librecore and I can confidently say everything you wrote in your article about our project is complete speculative garbage. The librecore and libreboot projects are completely independent projects that have no relationship what-so-ever. The librecore project is a fork from coreboot by some original coreboot developers such as myself with different technical objectives.[…]”
(Not to be confused with librecores (plural):
Hardware security training at Black Hat
Eurecom-S3 releases Intel TSX for CFI prototype
Towards hardware-assisted control flow integrity using transactional memory
Muench, Marius, Pagani, Fabio, Shoshitaishvili, Yan, Kruegel, Christopher; Vigna, Giovanni; Balzarotti, Davide
RAID 2016, 19th International Symposium on Research in Attacks, Intrusions and Defenses, September 19-21, 2016, Evry, France / Also published in LNCS, Vol. 9854
Control Flow Integrity (CFI) is a promising defense technique against code-reuse attacks. While proposals to use hardware features to support CFI already exist, there is still a growing demand for an architectural CFI support on commodity hardware. To tackle this problem, in this paper we demonstrate that the Transactional Synchronization Extensions (TSX) recently introduced by Intel in the x86-64 instruction set can be used to support CFI. The main idea of our approach is to map control flow transitions into transactions. This way, violations of the intended control flow graphs would then trigger transactional aborts, which constitutes the core of our TSX-based CFI solution. To prove the feasibility of our technique, we designed and implemented two coarse-grained CFI proof-of-concept implementations using the new TSX features. In particular, we show how hardware-supported transactions can be used to enforce both loose CFI (which does not need to extract the control flow graph in advance) and strict CFI (which requires pre-computed labels to achieve a better precision). All solutions are based on a compile-time instrumentation. We evaluate the effectiveness and overhead of our implementations to demonstrate that a TSX-based implementation contains useful concepts for architectural control flow integrity support.
https://github.com/eurecom-s3/tsxcfi
UEFI C++ Wrapper
Earlier I posted about a UEFI project to enable C++ code usage:
Back then it was just getting started and was not usable. However, now it appears that it usable today, for some things.
FWTS 17.01.00 released
Alex Hung of Canonical has announced the release of FWTS 17.01.00, the FirmWare Test Suite.
New Features:
* ACPICA: Update to version 20161222
* klog.json: Add kernel errors to the database
* fedora/fwts.spec: Add initial version of fwts.spec
* fedora/buildrpm.sh: Add build script for RPMs
See the full announcement for more details:
http://fwts.ubuntu.com/release/fwts-V17.01.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.01.00
https://launchpad.net/ubuntu/+source/fwts
Qualcomm Secure Boot whitepaper released
This whitepaper provides an in-depth look at our signed ELF images format, the process of loading and authenticating those images, certificate chain contents, and supported signature algorithms.
https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview
https://www.qualcomm.com/news/onq/2017/01/17/secure-boot-and-image-authentication-mobile-tech
Yuriy and Oleksandr at REcon
Baring the system: New vulnerabilities in SMM of Coreboot and UEFI based systems
By: Yuriy Bulygin, Oleksandr Bazhaniuk
Previously, we discovered a number of vulnerabilities in UEFI based firmware including software vulnerabilities in SMI handlers that could lead to SMM code execution, attacks on hypervisors like Xen, Hyper-V and bypassing modern security protections in Windows 10 such as Virtual Secure Mode with Credential and Device Guard. These issues led to changes in the way OS communicates with SMM on UEFI based systems and new Windows SMM Security Mitigations ACPI Table (WSMT). This research describes an entirely new class of vulnerabilities affecting SMI handlers on systems with Coreboot and UEFI based firmware. These issues are caused by incorrect trust assumptions between the firmware and underlying hardware which makes them applicable to any type of system firmware. We will describe impact and various mitigation techniques. We will also release a module for open source CHIPSEC framework to automatically detect this type of issues on a running system.
https://recon.cx/2017/brussels/talks/baring_the_system.html
Alexander on U-Boot+UEFI+GRUB on ARM
Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:
Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE
Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.
Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.
https://openiotelcna2017.sched.com/event/9IuS
https://openiotelcna2017.sched.com/?s=firmware
https://openiotelcna2017.sched.com/?s=u-boot
http://events.linuxfoundation.org/events/openiot-summit
http://events.linuxfoundation.org/events/embedded-linux-conference
FSF increases focus on firmware
The Free Software Foundation has updated their list of Campaigns, which includes mention of reversing firmware, and a blob-free version of Coreboot:
[…]
Reverse engineering projects.
We haven’t analyzed these in detail yet, but more broadly free drivers and free firmware (the goals of nearly all of the listed projects) have all four of our characteristics. Reverse engineering is one way to obtain free drivers and firmware, but the ideal is for manufacturers to publish full specifications and ship free drivers and free firmware, and this is what users should demand. We may want to reframe this page around free drivers, firmware, and hardware designs, noting priority reverse engineering tasks, but also encouraging users to make requests to vendors. The page also lists Replicant, a free version of Android. Phone operating systems were one of the most popular suggestions and merit their own entry (see potential additions below).
[…]
Coreboot.
A free BIOS has at least the universal and frontier characteristics. Several people suggested adding “and Libreboot,” the project to ship a version of Coreboot with no blobs, pushing further in the frontier direction. We intend to take this suggestion. We are also discussing whether to move this listing to the reframed page about free drivers, firmware, and hardware designs mentioned above.
[…]
Free software drivers for network routers.
The text of this listing concerns mesh networking, which may be too narrow to satisfy our criteria. In general free drivers for network routers probably meet the universal and frontier criteria, but it may make sense to fold this listing into a listing/page concerning free drivers and firmware for a large category of hardware (see reverse engineering above).
[…]
https://www.fsf.org/campaigns/priority-projects/changelog
https://media.libreplanet.org/u/libreplanet/m/the-state-of-free-revising-the-high-priority-projects-list/
https://www.fsf.org/blogs/community/a-preliminary-analysis-of-high-priority-projects-feedback
firmware-security list on Twitter
Back when this blog was first started, Jacob Torrey created a firmware-security list on Twitter to help. Newer readers of the blog may not be aware of that list. If you’re on Twitter, and have sources of firmware news, please consider using that list. Thanks.
Intel debugging interface vulnerable to USB attacks
New Intel processors contain a debugging interface accessible via USB 3.0 ports that can be used to obtain full control over a system and perform attacks that are undetectable by current security tools. A talk on the mechanisms needed for such attacks and ways to protect against them was given by Positive Technologies experts Maxim Goryachy and Mark Ermolov at the 33rd Chaos Communication Congress (33C3) in Hamburg, Germany. […]
http://blog.ptsecurity.com/2017/01/intel-debugger-interface-open-to.html
Some background on these interfaces:
Google documents internals firmware usage
Worth reading:
[…]
Secure Boot Stack and Machine Identity
Google server machines use a variety of technologies to ensure that they are booting the correct software stack. We use cryptographic signatures over low-level components like the BIOS, bootloader, kernel, and base operating system image. These signatures can be validated during each boot or update. The components are all Google-controlled, built, and hardened. With each new generation of hardware we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above mentioned Google-designed security chip. Each server machine in the data center has its own specific identity that can be tied to the hardware root of trust and the software with which the machine booted. This identity is used to authenticate API calls to and from low-level management services on the machine. Google has authored automated systems to ensure servers run up-to-date versions of their software stacks (including security patches), to detect and diagnose hardware and software problems, and to remove machines from service if necessary.
[…]
https://cloud.google.com/security/security-design/
IBM on attacking Android Custom Boot Modes
IBM’s SecurityIntelligence has a story on attacking Android’s Custom Boot Modes.
Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
By Roee Hay
Co-authored by Michael Goberman.
In recent months, the X-Force Application Security Research Team has discovered several previously undisclosed Android vulnerabilities. The November 2016 and January 2017 Android Security Bulletins included patches to one high-severity vulnerability, CVE-2016-8467, in Nexus 6 and 6P. Our new paper, “Attacking Nexus 6 & 6P Custom Bootmodes,” discusses this vulnerability as well as CVE-2016-6678.[…]
Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
TCG on network hardware security
“Firewalls and gateway routers are already important components of any organization’s network security strategy. But network architects can often overlook the fact that the networking equipment itself can be attacked. Ensuring these devices are resistant to attacks is just as important as conventional security mechanisms that protect PCs and servers.”
Establishing Network Equipment Security
Click to access Establishing-Network-Equipment-Security.pdf
TCG Guidance for Securing Network Equipment Preview Synopsis
Click to access NetEq-Synopsis_1_0r3.pdf
More info:
http://www.trustedcomputinggroup.org/establishing-network-equipment-security/
Bare-metal UEFI sample app
There is a new “bare-metal” UEFI sample, a standalone C program with no use of external (eg, Tianocore) headers. It is also an example of showing how to write and run a UEFI inside OVMF.
https://github.com/cupnes/bare_metal_uefi
https://github.com/utshina/uefi-simple
http://d.hatena.ne.jp/shina_ecc/20140819/1408434995
http://wiki.osdev.org/UEFI_Bare_Bones
http://wiki.osdev.org/Bare_Bones
Tactical Network Solutions’ training
I don’t know much about their product/service details, but Tactical Network Solutions has Centrifuge:
And it looks like they have some new training:
Changes in Tianocore’s UEFI HTTP[S] Boot
After UEFI HTTP Boot was added to spec, HTTP support was added to the public Tianocore EDK2 tree. But initially there was no HTTPS support. Fast forward through a bunch of other branches and work, and now it looks like there’s nearly ready to have HTTPS in the EDK2 tree, given below patch. If you are using UEFI HTTP Boot withOUT httpS support, ask your vendor for an update!
Subject: [edk2] [Patch 0/2] Enable the HTTP switch
If the value of PcdHttpEnable is TRUE, HTTP is enabled. Both the “http://” and “https://” schemes are acceptable. Otherwise, HTTP is disabled. The “http://” scheme will be denied.
Firmware Security 
You must be logged in to post a comment.