Triton 0.5 released

Triton is a Dynamic Binary Analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint Engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, an SMT Solver Interface and, the last but not least, Python bindings.

https://github.com/JonathanSalwan/Triton/milestone/8
https://github.com/JonathanSalwan/Triton
https://triton.quarkslab.com/
https://triton.quarkslab.com/documentation/doxygen/

Triton's architecture

ARM IETF ID on IoT firmware update architecture

IETF Internet draft: draft-moran-fud-architecture-00:

A Firmware Update Architecture for Internet of Things Devices
July 18, 2017
Brendan Moran, Milosch Meriac, Hannes Tschofenig
ARM Limited

Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.

There’s a mailing list for FUD:

https://www1.ietf.org/mailman/listinfo/fud

https://tools.ietf.org/html/draft-moran-fud-architecture-00

PyREBox

PyREBox is a Python scriptable Reverse Engineering sandbox. It is based on QEMU, and its goal is to aid reverse engineering by providing dynamic analysis and debugging capabilities from a different perspective. PyREBox allows to inspect a running QEMU VM, modify its memory or registers, and to instrument its execution, by creating simple scripts in python to automate any kind of analysis. QEMU (when working as a whole-system-emulator) emulates a complete system (CPU, memory, devices…). By using VMI techniques, it does not require to perform any modification into the guest operating system, as it transparently retrieves information from its memory at run-time. Several academic projects such as DECAF, PANDA, S2E, or AVATAR, have previously leveraged QEMU based instrumentation to overcome reverse engineering tasks. These projects allow to write plugins in C/C++, and implement several advanced features such as dynamic taint analysis, symbolic execution, or even record and replay of execution traces. With PyREBox, we aim to apply this technology focusing on keeping the design simple, and on the usability of the system for threat analysts.

https://github.com/Cisco-Talos/pyrebox

Cisco on firmware malware

[…]Instead, security has to be comprehensive and pervasive on every network device (switches, routers, etc.) as hackers get more sophisticated and unpredictable and capable of exploiting both hardware and software vulnerabilities. These attackers, with cutting-edge techniques, can access memory chips, use tools to extract the contents of those chips and then use the content to build/configure systems to act as imposters on the customer’s networrk. Bottom line – Malware can be installed on a router or switch. Are you protected ?[…]

https://blogs.cisco.com/datacenter/building-data-center-trustworthy-systems

Attacking the kernel via its command line

Attacking the kernel via its command line
June 20, 2017
Nur Hussein

The kernel’s command line allows the specification of many operating parameters at boot time. A silly bug in command-line parsing was reported by Ilya Matveychikov on May 22; it can be exploited to force a stack buffer overflow with a controlled payload that can overwrite memory. The bug itself stems from a bounds-checking error that, while simple, has still been in the Linux kernel source since version 2.6.20. The subsequent disclosure post by Matveychikov in the oss-security list spawned a discussion on what constitutes a vulnerability, and what is, instead, merely a bug.[…]

https://lwn.net/Articles/725860/

Follow-up conversation is interesting, as well. Includes a pointer to a few things, such as this blog post:

On dm-verity and operating systems

 

ME Analyzer 1.16.3 released

ME Analyzer Features:
Supports all Engine firmware generations (ME 1 – 11, TXE 1 – 3 & SPS 1 – 4)
Supports all types of file images (Engine Regions, SPI/BIOS images etc)
Detection of Family, Version, SKU, Date, Revision, Platform etc info
Detection of Production, Pre-Production, ROM-Bypass, MERecovery etc Releases
Detection of Region (Stock/clean or Extracted/dirty), Update etc Types
Detection of Security Version Number (SVN), Version Control Number (VCN) & PV
Detection of firmware’s Flash Image Tool platform configuration for ME 11 & up
Detection of Intel SPI Flash Descriptor region’s Access Permissions
Detection of whether the imported Engine firmware is updated
Detection of unusual Engine firmware (Corrupted, Compressed, OEM etc)
Detection of multiple Engine regions in input file, number only
Detection of special Engine firmware BIOS GUIDs via UEFIFind
Detection of unique mobile Apple Macintosh Engine firmware SKUs
Advanced detection & validation of Engine region’s firmware Size
Ability to analyze multiple files by drag & drop or by input path
Ability to unpack all Engine x86 firmware (ME >= 11, TXE >= 3, SPS >= 4)
Ability to detect & categorize firmware which require attention
Ability to validate Engine region’s $FPT checksums & entries counter
Ability to detect various important firmware problems and corruptions
Supports SoniX/LS_29’s UBU, Lordkag’s UEFIStrip & CodeRush’s UEFIFind
Reports all firmware which are not found at the Engine Repository Database
Reports any new, unknown, problematic, incomplete etc Engine firmware images
Features command line parameters to enhance functionality & assist research
Features user friendly messages & proper handling of unexpected code errors
Shows colored text to signify the importance of notes, warnings & errors
Open Source project licensed under GNU GPL v3, comment assisted code

https://github.com/platomav/MEAnalyzer/commits/master
https://github.com/platomav/MEAnalyzer

 

 

PRIVAT: secure smartphone?

PRIVAT – The world’s most secure smartphone
Keep control of your photos/videos and avoid spying through a 100% reliable hardware system.
$1,800 USD raised by 4 backers
4% of $50,000
4 days left

https://www.indiegogo.com/projects/privat-the-world-s-most-secure-smartphone-security-technology#/

 

Dmytro on Apple PCI-E Thunderbolt

XIOSim

https://twitter.com/corkmork/status/886197521797664769

XIOSim is a detailed user-mode microarchitectural simulator for the x86 architecture. It has detailed models for in-order (Atom-like) and out-of-order (Nehalem-like) cores and tightly-integrated power models. XIOSim supports multiprogram and multithreaded execution, regions-of-interest (including SimPoints). It runs at 100s KIPS per simulated core and uses cores on the simulation host to speed up multicore simulation (fastest runs use 2x the number of simulated cores). XIOSim builds up on and integrates a significant amount of others’ work:
* The out-of-order performance model from Zesto.
* The Pin binary instrumentation engine.
* The power models from McPAT.
* The DRAM models from DRAMSim2.

https://github.com/s-kanev/XIOSim

BootStomp: On the Security of Bootloaders in Mobile Devices

BootStomp: On the Security of Bootloaders in Mobile Devices

Nilo Redini, Aravind Machiry, Dipanjan Das, Yanick Fratantonio, Antonio Bianchi, Eric Gustafson, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna

Modern mobile bootloaders play an important role in both the function and the security of the device. They help ensure the Chain of Trust (CoT), where each stage of the boot process verifies the integrity and origin of the following stage before executing it. This process, in theory, should be immune even to attackers gaining full control over the operating system, and should prevent persistent compromise of a device’s CoT. However, not only do these bootloaders necessarily need to take untrusted input from an attacker in control of the OS in the process of performing their function, but also many of their verification steps can be disabled (“unlocked”) to allow for development and user customization. Applying traditional analyses on bootloaders is problematic, as hardware dependencies hinder dynamic analysis, and the size, complexity, and opacity of the code involved preclude the usage of many previous techniques. In this paper, we explore vulnerabilities in both the design and implementation of mobile bootloaders. We examine bootloaders from four popular manufacturers, and discuss the standards and design principles that they strive to achieve. We then propose BOOTSTOMP , a multi-tag taint analysis resulting from a novel combination of static analyses and dynamic symbolic execution, designed to locate problematic areas where input from an attacker in control of the OS can compromise the boot-loader’s execution, or its security features. Using our tool, we find six previously-unknown vulnerabilities (of which five have been confirmed by the respective vendors), as well as rediscover one that had been previously-reported. Some of these vulnerabilities would allow an attacker to execute arbitrary code as part of the boot-loader (thus compromising the entire chain of trust), or to perform permanent denial-of-service attacks. Our tool also identified two bootloader vulnerabilities that can be leveraged by an attacker with root privileges on the OS to unlock the device and break the CoT. We conclude by proposing simple mitigation steps that can be implemented by manufacturers to safeguard the bootloader and OS from all of the discovered attacks, using already-deployed hardware features.

Click to access 2017_sec_bootstomp.pdf

https://www.usenix.org/biblio-177

Reverse Engineering Hardware of Embedded Devices

Reverse Engineering Hardware of Embedded Devices: From China to the World
This article covers some basic hardware reverse engineering techniques on PCB-level, which are applicable to any electronic embedded device to showcase how to analyze a previously unknown (to the researcher or public white-hat community) hardware device. SEC Consult operates a dedicated Hardware Security Lab as part of its SEC Consult Vulnerability Lab. The presented material is a glimpse into ongoing research at the SEC Consult Hardware Security Lab and pentests that involve hardware hacking techniques.[…]

http://blog.sec-consult.com/2017/07/reverse-engineering-hardware.html

The Threat of Virtualization: Hypervisor-Based Rootkits on the ARM Architecture

The Threat of Virtualization: Hypervisor-Based Rootkits on the ARM Architecture
Robert Buhren, Julian Vetter, Jan C. Nordholz

The virtualization capabilities of today’s systems offer rootk-its excellent hideouts, where they are fairly immune to countermeasures. In this paper, we evaluate the vulnerability to hypervisor-based rootkits of ARM-based platforms, considering both ARMv7 and ARMv8. We implement a proof-of-concept rootkit to prove the validity of our findings. We then detail the anatomy of an attack wherein a hypervisor rootkit and a userspace process collaborate to undermine the isolation properties enforced by the Linux kernel. Based on our discoveries, we explore the possibilities of mitigating each attack vector. Finally, we discuss methods to detect such highly privileged rootkits so as to conceive more effective countermeasures.

https://www.researchgate.net/publication/309770683_The_Threat_of_Virtualization_Hypervisor-Based_Rootkits_on_the_ARM_Architecture

 

Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.

https://github.com/gencymex/smmtestbuildscript

[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

 

Firmware Test Suite 17.07.00 released

Today Alex Hung of Canonical announced the latest release of FWTS. The list of New Features appears to all be ACPI-centric:

* acpi: bgrt: update according to acpi 6.1 errata (mantis 1577)
* acpi: method: update _PSD and _TSD tests according to ACPI 6.1 errata
* acpi: rsdp: revision 1 must have length 20 according to ACPI 6.1 errata
* acpi: method: Add _CPC revision 3 according to ACPI 6.2 (mantis 1611)
* acpi: hest: add new type 11 introduced in ACPI 6.2 (mantis 1649)
* acpi: srat: add new type 4 according to ACPI 6.2 (mantis 1656)
* acpi: method: update _GCP according to ACPI 6.2 (mantis 1703)
* acpi: hest: add notification type 11 according to ACPI 6.2 (mantis 1731)
* acpi: fadt: update minor version to 2 for ACPI 6.2 (mantis 1769)
* acpi: hest: add checks for GHES_ASSIST flag value in ACPI 6.2 (mantis 1674)
* acpi: wsmt: add wsmt test according to ACPI 6.2 (mantis 1585)
* ACPICA: Update to version 20170629
* acpi: tpm2: Add additional start method values
* acpi: iort: Add PMCG support

See the full announcement for list of Fixed Bugs (which aren’t ACPI-centric).

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V17.07.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.07.00

UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:

http://wiki.qemu.org/ChangeLog/2.9

The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:
https://getfedora.org/
https://en.wikipedia.org/wiki/System_Management_Mode

Intel releases LUV (Linux UEFI Validation) v2.1

Today Ricardo Neri of Intel announced the 2.1 release of LUV. In additon to updating Linux to v4.11, FWTS to V17.06.00, CHIPSEC to v1.3.1, BITS to v2079, and NDCTL v56, they also started doing nightly builds. Here are some of the other highlights of this release, from the announcement:

Gayatri Kammela won the prize of the most active contributor with many bug fixes and a new feature. She fixed our netboot image, which was missing the ramdisk(!). She added support for debugging and logging of BITS output via network. Likewise, she reworked the LUV configuration file to make more sense to both humans and computers by making clear when parameters are not used. She also investigated and fixed dependencies in systemd that caused delays in the execution of tests. Lastly, she fixed a couple of build-time bugs.

Naresh Bhat updated our Linux kernel recipe to retrieve the kernel configuration directly from the source tree rather than manually updating it. This helped us to remove those eyesore patches for updating our configuration that needed to be sent every time we bumped to a new kernel version. The overall result looks great and is closer to the intended use of the kernel and Yocto Projects’s scripts to merge multiple configuration fragments. I took this opportunity to sanitize the configuration for x86 to add missing configurations and reorganize them.

Sai Praneeth Prakhya added functionality to dump relevant and useful dumps as part of the testing results. Now LUV is capable of dumping the kernel’s boot log, the contents of the ACPI tables as well as the properties of the CPUs in the system. Very useful! Also, he helped us to bump to Linux v4.11. He also took burden of rebasing our implementation to detect firmware’s illegal memory access in this new version of Linux.

Matt Hart updated our GRUB configuration to automate boots across all CPU architectures by not waiting for human intervention to complete boots.

See the full announcement for lists of Known and Fixed Issues:
https://lists.01.org/mailman/listinfo/luv

In addition to stuff mentioned in LUV announcement, LUV also did some updates to how LUV calls CHIPSEC, see these posts:
https://lists.01.org/pipermail/chipsec/2017-July/thread.html

These days, LUV-live ships with BIOS MBR or UEFI GPT partition types, local or network boot types, and x86 or x64 architecture type, multiple choices for the image:
https://download.01.org/linux-uefi-validation/v2.1/
https://download.01.org/linux-uefi-validation/v2.1/sha256sums.asc

 

Grub UEFI Settings Entry Adder

Grub UEFI Settings Entry Adder

The following repository adds a grub bootloader entry to boot into your UEFI/BIOS firmware settings. The underlying grub entry script (uefi-firmware) is a trimmed down version of this[1] script distributed by jsherz.com. The conditions have been removed as they no longer apply to recent linux versions. It shall be noted that I have NOT replaced the conditions, but rather removed them, hence I should remind you that the grub entry may not function on every device, depending on it’s linux setup, version and the hardware.

 

https://github.com/CTXz/grub-uefi-settings-entry

[1] https://jsherz.com/centos/grub/grub2/bios/uefi/boot/2015/11/21/centos-uefi-firmware-option.html

Gigabyte update for Intel AMT vulnerability

https://www.gigabyte.com/Press/News/1562

 

GIGABYTE Updating BIOS for Q270 and Q170 Series Motherboards in Response to Intel Updates

2017/07/12

Taipei, Taiwan, July 12th, 2017 – GIGABYTE TECHNOLOGY Co. Ltd., a leading manufacturer of motherboards and graphics cards, announces that it is in the process to update BIOS for Q270, Q170, and X170-WS ECC Series Motherboards. Based on latest Intel ME firmware updates, GIGABYTE will update BIOS for Q270 and models of previous chipsets accordingly to ensure the models meet latest security standards. GIGABYTE updated the BIOS for X170, X150, B150 and B250 models that are already available on GBT website. On the other hand, GIGABYTE is also updating Q87, Q85, B85, and other impacted models. The updates will be available shortly on the GBT website. For updates to these Motherboards please visit their respective product pages or speak with your technical support team for assistance. GIGABYTE strives to make sure users receive the best-in-class performance while maintaining the upmost security for all products.

http://techreport.com/news/32237/gigabyte-begins-rolling-out-bios-updates-to-close-intel-amt-hole

GIGABYTE Issues BIOS Update to Fix Intel Manageability Firmware Vulnerability