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

UEFI Forum recommends FWTS for it’s ACPI tests

FWTS has had ACPI tests for a while, and it’s basically the best public set of ACPI tests available. Better than anything the UEFI Forum has, like the SCTs. They’ve been using FWTS in the UEFI plugfests for a while, for ACPI purposes. Now the UEFI Forum is more formally recommending FWTS. Alex Hung of Canonical announces a new milestone for FWTS, the FirmWare Test Suite:

FWTS 17.03.00 is recommended as the ACPI 6.1 SCT

We have achieved another important milestone! The UEFI Board of Directors recommends Firmware Test Suite (FWTS) release 17.03.00 as the ACPI v6.1 Self-Certification Test (SCT), More information is available at:
http://www.uefi.org/testtools
Thank you all for who contributed patches, reported bugs, provided feedbacks and used FWTS in your work.

Thanks, FWTS, for having the best ACPI tests available!

 

Full announcement:
https://lists.ubuntu.com/mailman/listinfo/fwts-announce

 

Intel AMT and JavaScript

Now that Intel® AMT 11.6 is released, it’s finally time to circle back and highlight a big new feature of 11.6 that has been in the works for a long time: Web Storage and the ability for the default Intel® AMT web UI to be replaced. Ever since the start, Intel® AMT has always had a basic web page you could access with any browser. Because it’s all out-of-band, you could access the web page from a browser even if the target computer was soft-off, sleeping or had a non-functioning operating system. Over the last 10 years, the web has come a long way. The built-in Intel® AMT web page offers basic capabilities, but we can do a lot better now with HTML5 and WebSockets.[…]

https://software.intel.com/en-us/blogs/2017/02/13/meshcommander-v044-released

https://software.intel.com/en-us/search/site/language/en?query=AMT

Pinczakko’s AMIBIOS Utils moves to Github

There’s a blog post about this, as well:

http://bioshacking.blogspot.sg/2017/07/migrating-amibios-1b-module-utilities.html

The utilities produced by the source code ONLY work with AMIBIOS8 (legacy BIOS) 1B module. You can obtain the 1B module from AMIBIOS8 BIOS binary by using AMI Module Management Tool (MMTool) utility (https://ami.com/en/products/bios-uefi-tools-and-utilities/bios-uefi-utilities/).

https://github.com/pinczakko/AMIBIOS8_1B_Utils

Alex at Black Hat: Where the Guardians of the BIOS Are Failing

Black Hat Vegas: Where the Guardians of the BIOS Are Failing
By Alex Matrosov
In our upcoming Black Hat Vegas talk, we will summarize our research about the UEFI firmware protections and our newly-discovered security problems. This talk raises awareness of these security challenges for hardware vendors, BIOS-level security researchers and defenders, and sophisticated stakeholders who want to know the current state of UEFI exposure and threats. The situation is serious but, with the right tools and knowledge, we can prevail.[…]

https://www.blackhat.com/us-17/briefings.html#betraying-the-bios-where-the-guardians-of-the-bios-are-failing

https://www.cylance.com/en_us/blog/black-hat-vegas-where-the-guardians-of-the-bios-are-failing.html