Category: Uncategorized

FreeScale, High Availability Boot, and U-Boot secure boot

~ hucktech ~ Leave a comment

Freescale Semiconductor, Inc. has a few Application Notes on their implementations of a U-Boot-based Secure Boot. One of these app notes is only a few days old. Excerpt:

Secure Boot on i.MX50, i.MX53, and i.MX 6 Series using HABv4

Executing trusted and authentic code on an applications processor starts with securely booting the device. The i.MX family of applications processors provides this capability with the High Availability Boot (HAB) component of the on-chip ROM. The ROM is responsible for loading the initial program image from the boot medium. HAB enables the ROM to authenticate the program image by using digital signatures. This initial program image is usually a bootloader. HAB provides a mechanism to establish a root of trust for the remaining software components and establishes a secure state on the i.MX IC’s secure state machine in hardware. The purpose of this application note is to provide a secure boot reference for i.MX applications processors that include HABv4. It demonstrates an example for generating a signed U-Boot image and configuring the IC to run securely. It is assumed that the reader is familiar with the basics of digital signatures and public key certificates.

This document covers secure boot using i.MX6. HABv4 is present on the following i.MX processors: i.MX50, i.MX53, and i.MX 6 Series. This document applies to all HABv4 processors. Secure boot features for other processors, such as i.MX25, i.MX35, and i.MX51, which use HABv3, are documented in Secure Boot on i.MX25, i.MX35, and i.MX51 using HAB3 application note (document AN4547). Secure boot features for i.MX28 are documented in Secure Boot with i.MX28 HAB v4 application note (document AN4555). i.MX28 supports HABv4, but its boot architecture is significantly different from other processors in the i.MX family.

More information:

Click to access AN4581.pdf

Click to access AN4547.pdf

Click to access AN4555.pdf

Apple updates iOS Security Guide

~ hucktech ~ Leave a comment

Recently, Apple updated the “iOS Security Whitepaper, for iOS 9.0 or later. A few excerpts:

Device Firmware Upgrade (DFU) mode:
Restoring a device after it enters DFU mode returns it to a known good state with the certainty that only unmodified Apple-signed code is present. DFU mode can be entered manually: First connect the device to a computer using a USB cable, then hold down both the Home and Sleep/Wake buttons. After 8 seconds, release the Sleep/Wake button while continuing to hold down the Home button. Note: Nothing will be displayed on the screen when the device is in DFU mode. If the Apple logo appears, the Sleep/Wake button was held down too long.

Secure boot chain:
Each step of the startup process contains components that are cryptographically signed by Apple to ensure integrity and that proceed only after verifying the chain of trust. This includes the bootloaders, kernel, kernel extensions, and baseband firmware. When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code, known as the hardware root of trust, is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. […]

Secure Enclave:
The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor. It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised. […]

Full whitepaper:

Click to access iOS_Security_Guide.pdf

https://support.apple.com/kb/HT1808
https://support.apple.com/kb/HT202739
https://support.apple.com/HT205212

EU restricts firmware modifications to wifi routers

~ hucktech ~ Leave a comment

https://twitter.com/ioptio/status/649821728718372864

Excerpt:

EU decides firmware lockdown

Mostly unnoticed the EU commission decided on a new bill which is supposed to forbid the replacement of the operating system (firmware) on devices with radio transmitters (for instance wifi routers): http://www.heise.de/netze/meldung/Funkregulierung-Angriff-auf-alternative-Software-2803189.html The US regulation agency FCC is currently discussing on a similar law. With this motion innovation in this area would be immensly thwarted. Initiatives like Freifunk but also commercial providers like DD-WRT (www.dd-wrt.com) or Hotsplots (www.hotsplots.de) would be unable to install their own firmware on wifi devices. Even laptops and PCs with wifi would be affected if they were running Linux.

http://blog.freifunk.net/2015/its-do-or-die-now

Rust for embedded use

~ hucktech ~ Leave a comment

There’s a new research paper out, on using the Rust programming language in embedded systems; the below blog post has more information as well.

Ownership is Theft: Experiences Building an Embedded OS in Rust
Amit Levy, Michael P Andersen, Bradford Campbell, David Culler, Prabal Dutta, Branden Ghena, Philip Levis, Pat Pannuto

Rust, a new systems programming language, provides compile-time memory safety checks to help eliminate runtime bugs that manifest from improper memory management. This feature is advantageous for operating system development, and especially for embedded OS development, where recovery and debugging are particularly challenging. However, embedded platforms are highly event-based, and Rust’s memory safety mechanisms largely presume threads. In our experience developing an operating system for embedded systems in Rust, we have found that Rust’s ownership model prevents otherwise safe resource sharing common in the embedded domain, conflicts with the reality of hardware resources, and hinders using closures for programming asynchronously. We describe these experiences and how they relate to memory safety as well as illustrate our workarounds that preserve the safety guarantees to the largest extent possible. In addition, we draw from our experience to propose a new language extension to Rust that would enable it to provide better memory safety tools for event-driven platforms.

Rust is apparently popular. I did one short post the other month[1], describing some existing Rust bindings for UEFI. Weeks later, that blog post is *still* one of the most-viewed posts every day.

More information:

https://mostlytyped.com/posts/experiences-building-an-os-in-ru

Click to access tock-plos2015.pdf

http://www.rust-lang.org
[1] https://firmwaresecurity.com/2015/09/04/rust-and-uefi/

Clarification of Matthew Garrett’s Linux fork

~ hucktech ~ Leave a comment

Some irresponsible bloggers have been commenting about Matthew’s fork of Linux:

Matthew Garrett’s new Linux fork

MJG on Linux securelevel

ZDNet has a story with comments from Matthew explaining things:

“I wouldn’t say I’m forking. I’d say that I’m doing my own development work away from LKML. Right now it’s got the securelevel work in it because that’s the only code I have that I feel is ready for public use, but it’ll pick up other bits of code that I’m working on as they become mature.”

http://www.zdnet.com/article/matthew-garrett-is-not-forking-linux/

I guess I look at Matthew’s fork is like the GRSecurity patch for Linux kernel: Matthew’s got the patchset that enables UEFI Secure Boot to be secure on Linux. I hope Tails, Qubes, and other security-minded distros use Matthew’s kernel, at least in builds for UEFI-based systems.

[One of the causes of the above issue is Linus having to deal with Microsoft as a CA. UEFI Forum could also deal with this by putting in place a CA that is not an OSV/OEM. OEMs could be making Linux-friendly sytsems, not just Windows- or Chrome boxes, where Linux is an afterthought second install, which is a lot harder to do with UEFI/Windows Secure Boot — and even Chrome Verified Boot. Linux Foundation could also be helping, by working with OEMs.]

Intel on UDK2015

~ hucktech ~ Leave a comment

UDK2015 was released the other day. There is a new blog post from Briand Richardson of Intel on usage of the UDK, and the main download page on the wiki has been updated to support it:

https://twitter.com/Intel_UEFI/status/652253984225394688

https://twitter.com/Intel_UEFI/status/652212808961138688

http://blogs.intel.com/evangelists/2015/10/08/using-udk2015-for-uefi-2-5-development/

http://www.tianocore.org/udk/udk2015/

http://sourceforge.net/projects/edk2/files/UDK2015_Releases/UDK2015/UDK2015-ReleaseNotes-MyWorkSpace.txt/download

Broken, Abandoned, and Forgotten firmware Code

~ hucktech ~ Leave a comment

There’s a series of blog posts that’ve been happening since April, zcutlip just posted part 13. There is a github project with the sample code. Here’s excerpt from part 1:

Broken, Abandoned, and Forgotten Code, Part 1

This series of posts describes how abandoned, partially implemented functionality can be exploited to gain complete, persistent control of Netgear wireless routers. I’ll describe a hidden SOAP method in the UPnP stack that, at first glance, appeared to allow unauthenticated remote firmware upload to the router. After some reverse engineering, it became apparent this functionality was never fully implemented, and could never work properly given a well formed SOAP request and firmware image. If it could work at all, it would be with only the most contrived of inputs. Someone may have thought shipping dead code was okay because an exploit scenario would be so contrived. Someone may not have considered that contrived inputs are the stock-in-trade of vulnerability researchers. In this series, I’ll describe the process of specially crafting a malicious firmware image and a SOAP request in order to route around the many artifacts of incomplete implementation in order to gain persistent control of the router. I’ll discuss reverse engineering the proper firmware header format, as well as the the improper one that will work with the broken code. Together, we’ll go from discovery to complete, persistent compromise.

More information:
https://github.com/zcutlip/broken_abandoned
http://shadow-file.blogspot.com/2015/10/abandoned-part-13.html
http://shadow-file.blogspot.com/2015/04/abandoned-part-01.html

Huawei 3G routers

~ hucktech ~ Leave a comment

Multiple news sites are pointing to a blog bost by Pierre Kim, on Huawei 3G router security:

A comprehensive study of Huawei 3G routers – XSS, CSRF, DoS, unauthenticated firmware update, RCE

Huawei Technologies Co. Ltd. is a Chinese multinational networking and telecommunications equipment and services company. It is the largest telecommunications equipment manufacturer in the world. The Huawei B260A device is a 3g modem / access point overall badly designed with a lot of vulnerabilities. The device is provided by Orange Tunisia as a “Flybox”. It’s available in a lot of countries to provide Internet with a 3G network (Vodafone provides this device, for example). The tests below are done using the last available firmware (firmware 846.11.15.08.115 – Feb 20 2013). Note: This firmware seems to be used for these 14 Huawei devices (from http://192.168.1.1/js/u_version.js ) which, therefore, are likely to be vulnerable to the same threats: ]…]

https://pierrekim.github.io/blog/2015-10-07-Huawei-routers-vulnerable-to-multiple-threats.html

Microsoft Threat Modeling Tool 2016 released

~ hucktech ~ Leave a comment

Microsoft has updated their Threat Modelling Tool. It appears to be a few years since the last release.

This latest release simplifies working with threats and provides a new editor for defining your own threats.  Microsoft Threat Modeling Tool 2016 has several improvements: a New Threat Grid, a Template Editor, and Migrating Existing Data Flow Diagrams.

If you don’t have a Windows box, you can at least use their EOP card game. 🙂

http://blogs.microsoft.com/cybertrust/2015/10/07/whats-new-with-microsoft-threat-modeling-tool-2016/
http://www.microsoft.com/en-us/sdl/
http://www.microsoft.com/en-us/sdl/adopt/eop.aspx
http://threatmodelingbook.com/

iPXE adds UEFI HTTP Boot support

~ hucktech ~ 1 Comment

Samer El-Haj-Mahmoud of HP posted a message to the EFI development list, with an update on iPXE, supporting UEFI HTTP Boot:

It looks like iPXE has been updated to work with UEFI 2.5 HTTP Boot, and tested with OVMF. Their page also includes instructions for configuring the DHCP server to enable HTTP Boot, and building OVMF with HTTP_BOOT enabled. It would be interesting to see if iPXE EFI version will directly use EFI_HTTP_PROTOCOL or carry its own TCP/IP HTTP code.

Excerpt from iPXE site:

Version 2.5 of the UEFI specification introduces the UEFI HTTP Boot feature. You can use the basic UEFI HTTP Boot client to chainload iPXE from an HTTP server, eliminating the need for a separate TFTP server in your boot infrastructure. The simple UEFI HTTP Boot client will download and boot iPXE. You can then use any of iPXE’s more advanced features such as HTTPS, Digest authentication, POST requests, scripts, menus, customisable code signing etc. to download and boot your operating system. UEFI HTTP chainloading provides a way to load iPXE on systems which do not have iPXE present as part of the UEFI firmware. If your system already provides iPXE as part of the UEFI firmware, then you do not need to use UEFI HTTP chainloading.

More information:
http://ipxe.org/appnote/uefihttp
http://article.gmane.org/gmane.comp.bios.edk2.devel/2756

EFI Mixed Mode patchset for Android-IA

~ hucktech ~ Leave a comment

Christopher Price posted availability of a patchset to restore EFI Mixed Mode to the latest Android-IA release. Excerpt of announcement:

Enclosed you will find 19 patches that restore EFI Mixed Mode to the latest Android-IA release. We are still running through a BFD linker bug in KernelFlinger that is preventing activation – but it has tested well with GMIN64 and does not appear to block the kernel. Testing and review appreciated. We’d like it committed upstream because it would be very difficult without trunk access to maintain these patches going forward. While we’d like to take credit, Mark Gross and Intel UK really did an excellent job reviving this work – we’ve been incubating and testing for the past few months. This will allow Android-IA to run on the millions of BayTrail-T production tablets that depend on EFI Mixed Mode. Without these patches, Android-IA cannot run on virtually any Bay Trail tablet today, except for maybe IRDA, which isn’t available in many countries currently. These patches should no longer be necessary once Kernel 3.15 is integrated, at which point Mixed Mode will hit mainline… or at least, should hit mainline.

http://console.com.co/wp-content/uploads/mixed-mode.zip

https://lists.01.org/pipermail/android-ia/2015-October/001003.html
http://www.phoronix.com/scan.php?page=news_item&px=MTY0OTI
https://lwn.net/Articles/589193/