Hastily-written news/info on the firmware security/development communities, sorry for the typos.
https://github.com/rust-lang-nursery/embedded-wg/issues/56
https://github.com/rust-lang-nursery/embedded-wg
Note that ‘firmware’ does not appear to be in scope of this book, which is sad. In the current Rust future, we’ll still have to use C for firmware, then Rust for the OS-level embedded code.
Richard Wilkins of Phoenix Technologies has an article in Embedded Computing about UEFI-based IoT security:
[…]This article is focused on system startup/firmware and the potential security problems for IoT devices in that space. And most important, what to do about them.[…]
http://www.embedded-computing.com/articles/firmware-security-for-iot-devices
PS: RANT… for some reason, one sentence jumped out at me:
“So why isn’t everyone using UEFI firmware? If the UEFI architecture provides the “solution” to these security threats, why isn’t everyone using it?”
I think the answer: UEFI is *A* solution, there are other solutions. Coreboot with Heads is another solution. Coreboot with Verified Boot is another solution. Using TXT and TPM measurements are other layers. Hypervisors/TEEs/SEEs are another layer. Separate security processors are another way. What is the right way, why isn’t everyone using one way? While I am a UEFI Forum member, I don’t think UEFI everyone should be using it. I welcome firmware diversity. 🙂 IMO, there are multiple implementations of signed code, signed updates, and a signed boot-up process, controlled by multiple (not a single) organization. I’m still hoping to see some professor gets a grad student to write a report doing a proper comparision of the various modern firmware security implementations’ strengths, so someone can start to make a reasonale decision as to which firmware security architecture is the solution for them.
“My @offensive_con slides released! Include all 010 templates for Intel ACM and Boot Guard (KM + IBBM). All these details been REconstructed from AMI FW. Discovered few Intel Boot Guard bypasses: 2 SW + 1 HW. Never underestimate RE in your Threat Model!!”
Betraying the BIOS: Where the Guardians of the BIOS are Failing
For UEFI firmware, the barbarians are at the gate — and the gate is open. On the one hand, well-intentioned researchers are increasingly active in the UEFI security space; on the other hand, so are attackers. Information about UEFI implants — by HackingTeam and state-sponsored actors alike — hints at the magnitude of the problem, but are these isolated incidents, or are they indicative of a more dire lapse in security? Just how breachable is the BIOS? In this presentation, I’ll explain UEFI security from the competing perspectives of attacker and defender. I’ll cover topics including how hardware vendors have left SMM and SPI flash memory wide open to rootkits; how UEFI rootkits work, how technologies such as Intel Boot Guard and BIOS Guard (and the separate Authenticated Code Module CPU) aim to kill them; and weaknesses in these protective technologies. There are few public details; most of this information has been extracted by reverse engineering. This talk is a revisited version of the Black Hat Vegas 2017 research with new details about Intel BIOS Guard and Intel ACM’s including new vulnerabilities.
https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS
https://www.offensivecon.org/agenda/
Click to access Offensivecon_18%5Bv2.0%5D.pdf
010 editor templates:
https://github.com/REhints/Publications/tree/master/Conferences/Betraying%20the%20BIOS/010%20templates
https://www.sweetscape.com/010editor/
This white paper provides a technical comparison of the security features and attack surface of Google Chrome, Microsoft Edge, and Internet Explorer. We aim to identify which browser provides the highest level of security in common enterprise usage scenarios, and show how differences in design and implementation of various security technologies in modern web browsers might affect their security. Comparisons are done using a qualitative approach since many issues regarding browser security cannot easily be quantified. We focus on the weaknesses of different mitigations and hardening features and take an attacker’s point of view. This should give the reader an impression about how easy or hard it is to attack a certain browser. The analysis has been sponsored by Google. X41 D-Sec GmbH accepted this sponsorship on the condition that Google would not interfere with our testing methodology or control the content of our paper. We are aware that we could unconsciously be biased to produce results favorable to our sponsor, and have attempted to eliminate this by being as transparent as possible about our decision-making processes and testing methodologies.
Click to access X41-Browser-Security-White-Paper.pdf
https://www.x41-dsec.de/#about
https://www.x41-dsec.de/security/report/whitepaper/2017/09/18/whitepaper-x41-browser-security/
https://www.crowdsupply.com/grand-idea-studio/opticspy
Uses & Application Ideas:
Search for optical covert channels that may exist in modern devices
Add data exfiltration/transfer functionality into a project
Capture/decode/demodulate IR signals from remote controls
Discover Li-Fi networks or Visible Light Communication (VLC) systems
“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
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:
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!!
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
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
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
March 1, 2018 10:00 am
Update on Spectre and Meltdown security updates for Windows devices
By John Cable / Director of Program Management, Windows Servicing and Delivery
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
“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
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.[…]
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.[…]
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.
Click to access OpenRAM_ICCAD_2016_paper.pdf
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
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
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://github.com/mit-dci/tangled-curl/blob/master/vuln-iota.md
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
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
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Firmware Security 
You must be logged in to post a comment.