Author: hucktech

khwasan: kernel hardware assisted address sanitizer

~ hucktech ~ Leave a comment

“Kernel HardWare-assisted AddressSANitiser (KHWASAN). It’s a much less RAM-hungry ASAN for your kernel, AArch64-only”

https://twitter.com/kayseesee/status/969681048391962624

This patchset adds a new mode to KASAN, which is called KHWASAN (Kernel
HardWare assisted Address SANitizer). There’s still some work to do and
there are a few TODOs in the code, so I’m publishing this as a RFC to
collect some initial feedback.

The plan is to implement HWASan [1] for the kernel with the incentive,
that it’s going to have comparable performance, but in the same time
consume much less memory, trading that off for somewhat imprecise bug
detection and being supported only for arm64.[…]

https://groups.google.com/forum/#!topic/kasan-dev/XXflR8Qy6g0

https://github.com/xairy/kasan-prototype/tree/khwasan

http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

UEFI Python: CPython 3.x or MicroPython 3.4?

~ hucktech ~ Leave a comment

In the beginning, Intel maintained CPython 2.x for UEFI. Current version is 2.7x. It looks like they may have stopped porting it, I am unclear.

In addition to Intel’s CPython 2.7x port, recently Google has proposed updating CPython 3.x to support UEFI, see:

Proposal for CPython v3.x for UEFI

I may’ve missed it, but I not sure Intel is involved with this effort.

At the UEFI Plugfest later this month, Intel is giving a talk about MicroPython for UEFI, “Implementing MicroPython in UEFI”.  So I am *guessing* that Intel has chosen MicroPython over CPython. I presume this means that CPython 2.7x port is now abandonware. I hope the CPython 3.x proposal is not dead, because of this MicroPython effort. Hoping both get traction, but will not hold my breath…

https://micropython.org/
https://github.com/micropython/micropython

Differences between CPython and MicroPython:
http://docs.micropython.org/en/latest/pyboard/genrst/index.html
https://pypi.python.org/pypi?%3Aaction=search&term=micropython

Once once of these Python 3.x implementations works, and the CHIPSEC project ports from 2.x to 3.c, I can finally stop using v2!!

MicroPython Logo

 

UEFI Forum Spring 2018 plugfest agenda

~ hucktech ~ Leave a comment

The UEFI Plugfest is in Seattle later this month.

I guess I missed the CFP, as the agenda is now available… 😦

* Intel: An Introduction to Platform Security
* Phoenix: TBD
* Arm:UEFI Updates, Secure Firmware and Secure Services on Arm
* Intel: The State of ASL Programming
* Intel: Implementing MicroPython in UEFI
* Insyde Software: UEFI and the Security Development Lifecycle
* Intel: Attacking and Defending the Platform
* Microsoft: Microsoft Security Features and Firmware Configurations
* Arm: Dynamic Tables Framework: A Step Towards Automatic Generation of ACPI & SMBIOS Tables
* Microsoft: Microsoft Sample Code on GitHub and Walkthrough on Firmware Updates and WU
* Linaro: Edk2-Platforms Overview
* AMI: Enabling Advanced NVMe Features Through UEFI

http://uefi.org/SpringPlugfest2018

ShowSLIC.efi: Access ACPI-based Windows SLIC License Key

~ hucktech ~ Leave a comment

FPMurphy has a new blog post with source to a new tool, and mentions plans for 3-4 new tools/year!

Those who follow my work in the UEFI Shell space are aware that I usually develop a number of new, and hopefully useful, UEFI shell utilities each year. This year, I plan to write three or four new utilities and enhance a number of existing utilities. This is the first of these new utilities. In this post, I describe the ShowSLIC utility. It is the first of my new utilities and came about from license and booting issues caused by a disk failure on a friend’s laptop that was running Windows 7. ShowSLIC is designed to enable you to retrieve SLIC (System License Internal Certificate) information from a UEFI-based Microsoft Windows PC or laptop. Such information is accessible (exposed) via the ACPI (Advanced Configuration and Power Interface) SLIP table.[…]

https://blog.fpmurphy.com/2018/01/accessing-acpi-slic-from-uefi-shell.html#ixzz58Wq6TSMw

https://blog.fpmurphy.com/

Looks like you have to scrape the source from the HTML blog post, not included in latest UEFI-Utilities, AFAICT:

https://github.com/fpmurphy/UEFI-Utilities-2016/commits/master

DMTF Releases New PLDM for Redfish Device Enablement Specification

~ hucktech ~ Leave a comment

The DMTF has released its new Platform Level Data Model (PLDM) for Redfish® Device Enablement Specification [1] as a Work in Progress, inviting public review and comment. This standard enables a management controller to present Redfish -conformant management of I/O adapters in a server, without the need for code specific to each adapter family/vendor/model. PLDM for Redfish Device Enablement describes the operation and format of request messages (also referred to as commands) and response messages, designed to be delivered using PLDM messaging. Using Redfish, messages are generated by a Redfish client through interactions with a user or a script, and communicated via JSON over HTTP or HTTPS to a management controller. Using the new standard, the management controller will encode the message into a binary format (Binary Encoded JSON, or BEJ) and communicate it using PLDM to an appropriate device for servicing. The device processes the message and returns the response back using PLDM to the management controller, again in binary format. The management controller then decodes the response and constructs a standard Redfish response in JSON over HTTP or HTTPS for delivery back to the client. PLDM for Redfish Device Enablement is developed by the DMTF’s Platform Management Components Intercommunications (PMCI) Working Group [2], which defines standards to address “inside the box” communication and functional interfaces. It can be used in conjunction with other PMCI standards, such as the PLDM Firmware Update Specification, to provide a comprehensive, common architecture for improved communication between management subsystem components. The new WIP release is the latest example of the ongoing hard work and close collaboration between DMTF Working Groups (including PMCI, SMBIOS and SPMF) to seamlessly address both internal- and external-facing interfaces and protocols for system management.

[1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0218_0.8.0a.pdf
[2] https://www.dmtf.org/standards/pmci
https://www.dmtf.org/standards/redfish
http://www.dmtf.org/standards/smbioswg
http://www.dmtf.org/standards/spmf

IDA Pro 7.1 released

~ hucktech ~ Leave a comment

“With this version of IDA we publish the decompiler intermediate language: the microcode. We were planning to do it since very long time but the microcode was constantly evolving, we could not do it. After ten years of evolution it looks mature and ready to be published. We believe that it will permit our users to implement much more powerful and higher level analysis algorithms than before. In the future we plan to use the microcode in IDA too: if the decompiler is present, the analysis will be improved automatically. “

https://hex-rays.com/products/ida/7.1/index.shtml

https://hex-rays.com/products/ida/7.1/microcode.png

 

IoT, Security and Automotive: Who’s Responsible For Security?

~ hucktech ~ Leave a comment

IoT, Security & Automotive: Who’s Responsible For Security?

Experts at the Table, part 2: Cheap components contaminating the supply chain, the need for platforms and certifications, and the futility of trying to future-proof devices.
February 28th, 2018 – By: Ed Sperling

Semiconductor Engineering sat down to discuss security issues and how to fix them with Mark Schaeffer, senior product marketing manager for secure solutions at Renesas Electronics; Haydn Povey, CTO of Secure Thingz; Marc Canel, vice president of security systems and technologies at Arm; Richard Hayton, CTO of Trustonic; Anders Holmberg, director of corporate development at IAR Systems. What follows are excerpts of that conversation.[…]

Who’s Responsible For Security?

Who’s Responsible For Security?

add-to-efi.sh – script to add boot entries to native EFI loader

~ hucktech ~ Leave a comment

This script allows users and administrators to automatically add their EFISTUB-enabled Linux system to the system’s native EFI bootloader without the need of any additional bootloader. It’s required that all files needed to perform the boot process (e.g. vmlinuz-xxx, initramfs-xxx.img) reside on the EFI system partition, which has to be mounted somewhere. The tool searches for the EFI partition by its partition type, then for installed kernels and finally for suitable initrds (including Intel Microcode). Furthermore, the tool is able to detect if the root filesystem is encrypted and adds appropriate kernel parameters. If you want to use (PART)UUID for booting, this tool will also do.[…]

 

https://github.com/stertingen/add-to-efi.sh

OpenRAM project: open-source memory compiler for VLSI circuits

~ hucktech ~ Leave a comment

The OpenRAM project aims to provide a free, open-source memory compiler development framework for Random-Access Memories (RAMs). It is a joint development project between University of California Santa Cruz and Oklahoma State University to enable memory and computer system research by creating an open-source compiler infrastructure.

https://openram.soe.ucsc.edu/

Click to access OpenRAM_ICCAD_2016_paper.pdf

Click to access OpenRAM_ICCAD_2016_presentation.pdf

https://github.com/mguthaus/OpenRAM

Reusable Firmware Development: A Practical Approach to APIs, HALs and Drivers

~ hucktech ~ Leave a comment

Available: December 8, 2017
Reusable Firmware Development: A Practical Approach to APIs, HALs and Drivers
Jacob Beningo

Gain the knowledge and skills necessary to improve your embedded software and benefit from author Jacob Beningo’s more than 15 years developing reusable and portable software for resource-constrained microcontroller-based systems. You will explore APIs, HALs, and driver development among other topics to acquire a solid foundation for improving your own software. Reusable Firmware Development: A Practical Approach to APIs, HALs and Drivers not only explains critical concepts, but also provides a plethora of examples, exercises, and case studies on how to use and implement the concepts.

What You’ll Learn
* Develop portable firmware using the C programming language
* Discover APIs and HALs, explore their differences, and see why they are important to developers of resource-constrained software
* Master microcontroller driver development concepts, strategies, and examples
* Write drivers that are reusable across multiple MCU families and vendors
* Improve the way software documented
* Design APIs and HALs for microcontroller-based systems

Microsoft Device Health Attestation protocol

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2018/02/22/hp-including-expected-pcr0-values-in-firmware-releases/

Microsoft Device Health Attestation protocol

Device Health Attestation
https://technet.microsoft.com/en-us/library/mt750346.aspx

[MS-DHA]: Device Health Attestation Protocol
https://msdn.microsoft.com/en-us/library/mt766195.aspx

IOTA crypto issues

~ hucktech ~ Leave a comment

http://iota.org/
https://github.com/IOTAledger
https://en.wikipedia.org/wiki/IOTA_(cryptocurrency)
https://blog.iota.org/official-statement-regarding-the-mit-dci-email-leaks-ea3cacd6699a
https://blog.iota.org/iota-foundation-hires-cybercrypt-615d2df79001

“IOTA is a public distributed ledger and data transfer layer that allows transactional settlement for the Internet of Things. IOTA utilizes the Tangle, a data structure based on a Directed Acyclic Graph (DAG).”

https://spectrum.ieee.org/tech-talk/computing/networks/cryptographers-urge-users-and-researchers-to-abandon-iota-after-leaked-emails

https://github.com/mit-dci/tangled-curl/blob/master/vuln-iota.md

View at Medium.com

Hardware Security: A Hands-On Learning Approach 1st Edition (eta Nov2018)

~ hucktech ~ Leave a comment

Release date: November 15, 2018
Hardware Security: A Hands-On Learning Approach 1st Edition
Swarup Bhunia,‎ Mark Tehranipoor
ISBN-13: 978-0128124772
ISBN-10: 0128124776
$89.95
Paperback: 432 pages
Publisher: Morgan Kaufmann

Hardware Security: A Hands-On Learning Approach provides a broad, comprehensive, and practical overview of hardware security encompassing all levels of our electronic hardware infrastructure. It covers basic concepts through advanced attack techniques and countermeasures, as illustrated through theory, case studies, and well-designed hands-on laboratory exercises for each key concept. The book is primarily intended to serve as a textbook for upper-level undergraduate students studying computer engineering, computer science, electrical engineering, and biomedical engineering, as well as a handy reference for graduate students, researchers and industry professionals.

For academic courses, the book contains a robust suite of teaching ancillaries, including:
* Schematic, layout and design files for a printed circuit board for hardware hacking (i.e. the HaHa board) that can be used by instructors to fabricate boards and provide to students for hands-on experiments
* A suite of videos demonstrating different hardware vulnerabilities, hardware attacks and countermeasures (downloadable from Elsevier website)
* Register transfer level (RTL) hardware code for AES to implement side-channel attacks (downloadable from Elsevier website)

 

https://www.elsevier.com/books/hardware-security/bhunia/978-0-12-812477-2

Firmware Test Suite 18.02.00 is released

~ hucktech ~ Leave a comment

New Features:
* ACPICA: Update to version 20180209
* uefirtvariable: add test for EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS attribute

See full announcement for list of bugfixes.

In related news, LUV has picked up the latest FWTS.

http://fwts.ubuntu.com/release/fwts-V18.02.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.02.00
https://launchpad.net/ubuntu/+source/fwts
https://lists.ubuntu.com/mailman/listinfo/fwts-announce

EFIDroid’s Qt port working on Intel now

~ hucktech ~ Leave a comment

The author of EFIDroid posted a comment, in reply to another EFIDroid query comment.  Previously, UEFI Qt of EFIDroid was ARM-centric, now:

“I’ve even recently started adding X64 support so it can be used on regular computers – I only have to add X64 support to UEFIThreads to complete that(which is required by QML).”

Looking forward to seeing UEFITool GUI app working as a UEFI app. 🙂

Qtbase: EFIDroid port of Qt to UEFI!

https://github.com/efidroid/qtbase

Purism has Heads working on Librem laptops

~ hucktech ~ Leave a comment

And newer Librems have TPMs bulit-in now.

https://puri.sm/posts/librem-now-most-secure-laptop-under-full-user-with-tamper-evident-features/

Heads booting on a Librem 13v2 TPM

SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution

~ hucktech ~ Leave a comment

SgxPectre Attacks: Leaking Enclave Secrets via Speculative Execution
Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, Ten H. Lai
(Submitted on 25 Feb 2018)

This paper presents SgxPectre Attacks that exploit the recently disclosed CPU bugs to subvert the confidentiality of SGX enclaves. Particularly, we show that when branch prediction of the enclave code can be influenced by programs outside the enclave, the control flow of the enclave program can be temporarily altered to execute instructions that lead to observable cache-state changes. An adversary observing such changes can learn secrets inside the enclave memory or its internal registers, thus completely defeating the confidentiality guarantee offered by SGX. To demonstrate the practicality of our SgxPectre Attacks, we have systematically explored the possible attack vectors of branch target injection, approaches to win the race condition during enclave’s speculative execution, and techniques to automatically search for code patterns required for launching the attacks. Our study suggests that any enclave program could be vulnerable to SgxPectre Attacks since the desired code patterns are available in most SGX runtimes (e.g., Intel SGX SDK, Rust-SGX, and Graphene-SGX).

https://arxiv.org/abs/1802.09085

 

ASUS doesn’t care about Linux [Firmware]

~ hucktech ~ Leave a comment

See image in below tweet. A tweet with a bug report about ACPI and TPM2 on ASUS systems.

Linux users: remember that you’re not using a Linux box, you’re using a Windows box, or a Chrome box, and reinstalling an OS, which the OEM doesn’t support, so they won’t be offering you any way to update your firmware with that OS. Unless you’re buying your machine from an OEM that installs Linux. If you are a Linux user, stop buying Windows/Chrome PCs and buy Linux PCs.

https://twitter.com/orionwl/status/968517661704556545

Amazon [Snowball] seeks Senior Hardware Security Engineer

~ hucktech ~ Leave a comment

Sr. Hardware Security Engineer

AWS Security is looking for an experienced Senior Security Engineer, specializing in hardware technologies, to help ensure AWS services are designed and implemented to the highest possible security standards. You will be responsible for supporting AWS service teams in the secure design of services, including customer-facing services with hardware components such as AWS Snowball. As the primary technical and strategic advocate for a variety of AWS-wide security initiatives, you will help internal and external partners to design from the beginning with security in mind.This is not an entry-level position, and a confident understanding of hardware/firmware security and the ability to collaborate with other leaders across the industry are essential to success in this role.
[…]
* Demonstrate *exceptional* judgment, integrity, business acumen, and communication skills
* Minimum 4 years of experience with two or more of the following categories:
— IoT network technologies (Z-Wave, Zigbee, Bluetooth/BLE, WLAN, identity/auth security)
— Hardware security (PCB, JTAG, UART, SPI, ROM, microcode, custom ASIC/FPGA)
— x86 and/or ARM chipset and firmware security (TPM, UEFI, TrustZone, secure boot)
— Local encryption and key management (LUKS, BitLocker, self-encrypting drives, etc)
— PKI and code signing architecture (X.509, EV SSL, certificate pinning, OCSP, CRL, etc)

https://us-amazon.icims.com/jobs/626253/sr.-hardware-security-engineer/job

See-also:

AWS Snowball:
https://aws.amazon.com/snowball/