Purism BIOS efforts

Purism mentioned in a Tweet that they have 3 developers working on Intel Management Engine:

They have one document, from the summer, talking about how they’re trying to free the BIOS:

https://puri.sm/posts/freeing-the-bios-the-memory-init-stage/

And another more recently-updated status page:

https://puri.sm/road-to-fsf-ryf-endorsement-and-beyond/

Purism offers the first high-end privacy and freedom-respecting laptops by manufacturing the motherboard and sourcing daughter cards, where all chips are designed to run free software. Purism laptops are completely free from the bootloader through the kernel (with no mystery code, binary blobs, or firmware blobs), including the operating system and all software. We have yet to free the Intel FSP binary and ME binary from within the coreboot BIOS to move us toward FSF RYF endorsement. We are working diligently to free the BIOS, but our goal is to go further than that: Purism also intends to free the firmware within HDDs and SSDs.

I’m still unclear how this will result. I’m of two minds on this: I love the idea of having a system I can trust, so am happy to see projects like Novena and Purism. On the other hand, Purism is fighting Intel’s security mechanisms, and I’m a little concerned the result will remove some Intel defensive technology that makes the system more easily attackable.

Their current model has a kill switch, which is a nice feature. [I’d also like a case that closes access to the ports when closed, and has a LOCK, with a good quality lock, that can’t be easily picked. That’d be an issue for TSA checkpoints, though.] I might also consider getting ride of Suspend/Resume, a lot of attacks happen there, and systems are fast enough these days to live without this feature.

I wish other OEMs would compete with Purism, it would be nice to have more options than a handful of ancient refurbished Thinkpads and a handful of remaining Novenas. The current Purism model is nearly done with funding, only a few days left:

 

Embedded Programming with Android’s U-Boot chapter

From about a week ago on the Pearson InformIT web site, Roger Ye published an article on using U-Boot with embedded Android, “Embedded Programming with Android: Using U-Boot to Boot the Goldfish Kernel“. The article mentions that this is a chapter from Roger’s book, “Embedded Programming with Android“, which is news to me. It appears the book came out in April.

In this chapter from Embedded Programming with Android: Bringing Up an Android System from Scratch, Roger Ye shows you how to build a goldfish Linux kernel and then how to boot Android from NOR flash and NAND flash using U-Boot and this kernel.

Once we have U-Boot ready for the goldfish platform, we can use it to boot the Linux kernel in the Android emulator. Ideally, the boot process starts from nonvolatile memory (such as flash memory). Many kind of storage devices can be used in an embedded system, though NOR and NAND flash devices are the most popular options. In this chapter, we will build a goldfish Linux kernel first. We then explore how to boot Android from NOR flash and NAND flash using U-Boot and this kernel. […]

http://www.informit.com/articles/article.aspx?p=2431417
http://www.informit.com/store/embedded-programming-with-android-bringing-up-an-android-9780134030005

GreatScottGadgets on FCC regulations

Michael Ossman of GreatScottGadgets has written an excellent post to the FCC:

https://twitter.com/michaelossmann/status/641504135703998464

Excerpt:
I am the owner of Great Scott Gadgets, a US company that makes open source test equipment primarily for the information security industry. As a designer and manufacturer of communications equipment, I commend the Commission for seeking to clarify and streamline the rules for equipment authorization. I believe that, on the whole, the updated rules will benefit the electronics industry. However, I am concerned that the rules regarding software control of radio parameters place an undue burden on device manufacturers and unnecessarily restrict the actions of end users. My concerns arise from rules already in place for Software Defined Radio (SDR) devices. I am encouraged to see that the Commission is eliminating certain special rules for SDR equipment and seeks to treat SDR and non-SDR devices in the same way. However, while the Commission notes that “the existing SDR rules have proven to be insufficiently flexible,” the proposed rules broaden the reach of those rules to non-SDR equipment.

Full post:
http://greatscottgadgets.com/2015/09-08-comments-fcc-nprm/

I hope other Open Hardware vendors speak up against this!

I can’t find the quote location right now, but a few days ago someone posted a joke, something like below:

“Why don’t we ever see anything like: FCC announces all routers must be open hardware/source, vendors have 30 days to comment.”

ARM article on U-Boot

A few weeks ago Linus Walleij of Linaro wrote an article talking about boot loader technology options for AArch32 and AArch64. Besides going into detail on U-Boot,  the blog mentions some boot loaders from Qualcomm and elsewhere:

https://www.linaro.org/blog/core-dump/u-boot-on-arm32-aarch64-and-beyond/

Microsoft and ARM collaborate on DRM/secure media solutions

ARM and Microsoft have announced support of integration of technologies that enable DERM on ARM systems, using Microsoft PlayReady and W3C Encrypted Media Extensions (EME):

Press release excerpt:

The major development in this solution is the integration of Microsoft’s PlayReady DRM with W3C EME, OpenCDM, Chromium and Linaro’s Open Portable Trusted Execution Environment (OP-TEE) on ARM TrustZone® technology. The secure media solution has been implemented on an STMicroelectronics STiH410 SoC with an ARM Cortex®-A9 processor at its core. The new solution integrates the following key components: W3C EME, Microsoft PlayReady DRM Porting Kit v3.0, OP-TEE, OpenCDM, and Chromium v43.

“The Linaro Digital Home Group is extremely pleased to deliver this open source secure media solution to the embedded developer community” said Mark Gregotski, Director of the Linaro Digital Home Group. “This collaboration demonstrates how a commercial DRM, such as Microsoft’s PlayReady, can be integrated into a security framework comprised of open-source components, including the Linaro Open Portable TEE running on ARM TrustZone. We hope this will be the catalyst to accelerate the deployment of secure DRM solutions employing open source software.”

“This is a key milestone that showcases how Microsoft PlayReady DRM works cross-platform in a standard way. We are excited about the collaboration with Linaro, ARM, OP-TEE and OpenCDM. This reference implementation simplifies and accelerates the ability of partners to build rich experiences to deliver secure media solutions, while providing market leading content protection using Microsoft PlayReady” said Dave Bossio, Group Program Manager, Windows Devices Group, Security at Microsoft Corporation.

“Trust is key to future media business models, as valuable content must be protected from server to screen,” said Shiv Ramamurthi, Director, Home Segment Marketing, ARM. “The pay TV ecosystem will see immediate content security benefits from the integration of ARM TrustZone and Microsoft PlayReady DRM technology. This latest open source initiative led by the Linaro Home Group is a milestone in the enablement of next-generation secure content and media experiences for consumers.”

“ST has been a strong contributor to the Open Portable Trusted Execution Environment (OP-TEE) in open source, a key enabler for this integration. As a natural step forward, ST is pleased its STiH410 platform is being used as a vehicle for this effort and for an exciting demo at IBC 2015,” said Yingchih Yang, Advanced System and Security Officer of the Consumer Product Division in STMicroelectronics. “Such Linaro contributions will facilitate premium content consumption across various devices including smartphones, tablets, and set-top-boxes, meeting strong market expectations.”

http://www.linaro.org/news/linaro-and-microsoft-collaborate-on-secure-media-solutions-for-arm-based-socs/?sf40842573=1
http://www.microsoft.com/playready/
https://github.com/fraunhoferfokus/open-content-decryption-module
https://github.com/w3c/encrypted-media/
http://www.w3.org/TR/encrypted-media/
https://github.com/OP-TEE

mbed

ARM has a new embedded OS called mbed, for use with the IoT. Beta was announced today:

IBM is partnering with ARM on mbed:
https://www-03.ibm.com/press/us/en/pressrelease/47579.wss
http://www.ibm.com/IoT

See this link for the various Github URLs to the source:
http://www.mbed.com/en/development/getting-started/get-code/
https://github.com/ARMmbed

More Info:
http://www.mbed.com/
http://community.arm.com/groups/internet-of-things/blog/2015/09/08/mbed-os-beta-is-here
http://community.arm.com/groups/internet-of-things/blog/tags#/?tags=mbed

(FYI, mbed.org, which is often used in the press release URLs, merely redirects to mbed.com.)

I haven’t looked at the code or the license yet. I have no idea about what firmware and boot technologies it uses… 😦

Reminder: Seattle-area sysadmin firmware talk Thursday

This SASAG talk on firmware security for system administrators is this Thursday.

It will be an attempt to integrate NIST SP147’s firmware lifecycle model with the various hardware/software models sysadmins use (Hardware Lifecycle Model, ITIL, ITAM, etc.), to better represent firmware in that model, as well as recommend some open source tools to use.

It appears I had the location confused (correct address, incorrect name) in my initial post. The SASAG post has the proper name of and a Google Maps pointer to the event location:

Stamatatos Lab, 2211 Elliot Ave, 1st Floor, Seattle WA

http://www.sasag.org/2015/08/14/sept-10th-mtg-defending-intel-uefi-systems-from-firmware-attackers/

Seattle-area SysAdmin firmware talk 9/10

mobile device hacking resources

The InfoSec Institute has a nice blog series on using embedded devices (eg Beagles, RPIs) and mobile devices for security testing. It isn’t a new article, but it has good background for those interested in this topic.

http://resources.infosecinstitute.com/handy-devices-hacking-part-1/
http://resources.infosecinstitute.com/handy-pentesting-and-hacking-part-ii/
http://resources.infosecinstitute.com/handy-pentesting-hacking-part-iii/

Hardware hacking methods

As found on Vincent’s Twitter feed, SparkFun has an article on hardware hacking techniques:

It’s not a new article, but I’ve never seen it, and it’s informative, so I don’t care when it was written. 🙂

The Common Methods of Hardware Hacking. The article describes 4 methods of modifying hardware: Patching Into I/O, Replacing a Component, Logic Analyzer, and JTAG Hex Dump Voodoo

https://www.sparkfun.com/news/1314

HP Security: HDD firmware hacking

Oleg Petrovsky of HP posted a good article on hard disk firmware hacking on the HP Security Research Blog. Long post, lots of pictures, very informative!

“In light of the recent publicity around malware that can remain persistent in hard drive firmware, it seems reasonable to seek a better understanding of what actually happens inside the hard drive – specifically, an understanding of the firmware. […]”

http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/HDD-firmware-Hacking-in-the-dark/ba-p/6780246

Sp3ctr3’s Hardware Security Resources page

Yashin Mehaboobe has a very nice web page of hardware resources.

It is not new, I just noticed it, most of you probably already know about it…

“Here are some whitepapers and blogpapers that should help you get started/learn more about hardware security. I’ve divided the page into divisions for easier viewing. I’ll keep adding to the list when I remember any other sites/papers that I refer to. Please let me know of any mistakes/suggestions down in the comments!”

Hardware Security Resources

The IoT Security Foundation

As reported by Peter Clarke in EETimes, The Internet of Things Security Foundation has just been created. It is a UK-based organization with the backing of over 30 organisations including: Broadcom, Freescale, Imagination Technologies, Inside Secure, Tokyo Electron, Vodafone, uBlox and many other companies and academic institutions. The IoTSF launch formally at an event in London on Sept. 23. Their initial statement:

The economic impact of the Internet of Things will be measured in $trillions.
The number of connected devices will be measured in billions.
The resultant benefits of a connected society are significant, disruptive and transformational.
Yet, along with the opportunity, there are fears and concerns about the security of IoT systems.
The international IoT Security Foundation (IoTSF) has been established as a response to those concerns.

Home

http://www.electronics-eetimes.com/en/iot-security-foundation-formed.html?cmp_id=7&news_id=222925954&vID=8

New Loongson MIPS chip runs ARM and x86 code

Loongson Technology has created the Loongson-3A2000 and Loongson-3B2000 chips, 64-bit quad-core MIPS64-based CPUs.

In addition to MIPS, these CPUs also run Intel x86 and ARM code, using LoongBT, a binary translation technology for Linux. The mind boggles with legal/IP complications…

I don’t know what firmware these new CPUs will use. There is an unofficial MIPS port of UEFI, but AFAIK but nothing official going on, so I presume the CPUs will use U-Boot or coreboot, but no details available AFAICT. I can’t find any details on LoongBT technology, either…

http://www.electronics-eetimes.com/en/chinese-processor-builder-discloses-mips64-ip-based-4-core-designs.html?cmp_id=7&news_id=222925960&vID=8

http://blog.imgtec.com/mips-processors/loongson-mips64-processors-performance-barrier

tool: ThunderGate

I just learned about ThunderGate, by Saul St John, The current version is 0.8.499, initial release was 4 months ago. It is a Python RE tool for Apple Thunderbolt Ethernet (and other) controllers, with PCI Option ROM, and UEFI support! I’m excerpting the readme and usage output below, see the URLs for full details, including omitted scary warning disclaimers:

ThunderGate is a collection of tools for the manipulation of Tigon3 Gigabit Ethernet controllers, with special emphasis on the Broadcom NetLink 57762, such as is found in Apple Thunderbolt Gigabit Ethernet adapters. Tigon3 controllers contain a variety of architectural blocks, including a PCI endpoint, an 802.3 media access controller, on-chip ram, DMA read and write engines, nonvolatile storage, and one or more MIPS processors. These features are exposed by ThunderGate through an easy-to-use Python interface, allowing for reverse engineering, development, and deployment of custom firmware and applications. Examples provided include a userspace VFIO tap driver, a firmware application capable of monitoring and manipulating network traffic and host memory, and a PCI option rom containing an EFI boot services driver which can either inhibit the employ or compromise the effectivity of Intel I/O MMU address translation (VT-d). The ThunderGate firmware implements a network protocol allowing for remote control of the device and host system by an Ethernet-connected peer. Currently supported actions include reading and writing from device and host memory, forging network traffic, sending host interrupts, and manipulation of PCI capabilities configuration.

$ py/main.py -h
usage: main.py [-h] [-v] [-d] [-t] [-s] device
  device        BDF of tg3 PCI device
  -h, –help     show this help message and exit
  -i, –install  install thundergate firmware
  -u, –uio      use uio pci generic interface
  -v, –vfio     use vfio interface
  -d, –driver   load userspace tap driver
  -t, –tests    run tests
  -s, –shell    ipython cli

More Information:
https://github.com/sstjohn/thundergate
http://thundergate.io/

ReactOS adds UEFI support

Excerpting Wikipedia, ReactOS is: an open-source operating system intended to be binary-compatible with computer programs and device drivers made for Windows.  ReactOS is primarily written in C. The project has been ported to the ARM and AMD64 processor architectures, and partially implements Windows API functionality. The latter is assisted by including parts from the Wine compatibility layer. The main goal of the ReactOS project is to provide an operating system which is binary compatible with Windows … such that people accustomed to the familiar user interface of Windows would find using ReactOS straightforward. The ultimate goal of ReactOS is to allow you to remove Windows and install ReactOS without the end user noticing the change.

http://www.reactos.org/wiki/UEFI

http://code.reactos.org/browse/reactos/trunk/reactos/boot/environ/lib/firmware/efi/firmware.c?r=69045

UEFITool 0.21.0 released

Nikolaj Schlej has released  UEFITool v0.21.0.

Features improved Skylake support, among other things:
– added support for new Intel descriptor type, based on [this](http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1f7fd720c81755144423f2d4062c39cc651adc0a) coreboot commit, thanks to lordkag for issue #32
– solved a bug with incorrect volume free space item placement during volume replace, now works as expected
– solved an issue with incorrect Aptio capsule parsing introduced in 0.20.8

https://github.com/LongSoft/UEFITool
https://firmwaresecurity.com/tag/uefitool/

RedHelix-1: Java library for DMTF Redfish

Hank Bruning of JBlade has released a new Java-based library to interact with Redfish. He announced it today on the Open Compute Project’s Hardware Management mailing list. He’s also looking for vendors with actual hardware, beyond the DMTF RedFish Mockup; if you can help him out, please get in touch with Hank.

https://github.com/RedHelixOrg/RedHelix-1
http://jblade.com
http://opencompute.org
http://www.dmtf.org/standards/redfish
https://firmwaresecurity.com/tag/redfish/

book review: The Art of Memory Forensics

I just read The Art of Memory Forensics.  Great book! I’m reviewing the book w/r/t/ firmware coverage. As the book promises, it covers OS-level memory issues. It wasn’t scoped to cover firmware and hardware issues, and only has a bit on this topic.

In a nutshell, the book teaches you Intel x86/x64 memory, and how Microsoft Windows, Apple Mac OS X, and Linux use memory, for forensic examinations. From this scope, the book is excellent, very well-written coverage of Intel memory details, hard to find other documentation that describes it so well. There focuses more on Windows than Unix-flavored OSes. It is well-written, better than most technology books.

…But Hacking Team’s UEFI-centric malware is an example that OS-level memory forensics are not the state of the art anymore, forensics needs to cover firmware a LOT better.

I’m not picking on this book or Volatility, I mean in general, computer forensics is too OS/app-focused.

This book does not cover hardware/firmware-level memory forensics.

There is no BIOS UEFI, ACPI, or firmware in Index. There is no coverage of OptionROMs, Expansion ROMs, SMM, UEFI variables, etc.

There is one brief mention of EFI (not UEFI), a OSX-centric reference, using the OSXPmem and MacMemoryReader tools. No UEFI coverage outside Mac hardware.

There is no ACPI in Index, but there are a few ACPI references in the output of a handful of tools, mostly just to show the address of the tables.

On page 72, covering memory acquisition, it briefly mentions DMA, Firewire, Thunderbolt, ExpressCard, and PCI, and an US$8K WindowSCOPE tool.

On page 659, when discussing Linux memory resources, and how APIC can remap memory, the book says:

“Malware can hook the APIC data structures to redirect control flow of interrupts to attacker-controlled handler functions. Inspecting the memory maps can help you understand where the hoooks are pointing and their impact on thei system. Besides the APIC, a number of other hardware devies have also been targetted by malware, such as video cards and PCI network cards.”

That paragraph is about as low-level as the book gets, w/r/t hardware/firmware.

On pages 658-661, there is a brief section on ‘detecting hardware manipulation’, Linux-centric, with linux_dmesg and linux_iomem plugins. There is brief tangent on patching LiME to capture physical memory outside of system RAM range, they could be covering other tools that don’t need patching, not just focusing on tools which have Volatility plugins.

Again, this book wasn’t focuses on firmware, just OS-level forensics. This book is GREAT for OS-level forensics.

To be as constructive as possible, I’m hoping that the second edition of this book includes:
* Expand the system model from the ring0/ring3 model to include negative rings, more detail to silicon, firmware, and virtualized levels.
* Mention of unacquirable memory, such as data stored in TPM chip. Perhaps SMM’s LockBox.
* Like PE discussion has a section on packing, some IBVs have proprietary compression algorithms for their firmware.
* ARM, AArch32 and AARch64 memory, not just Intel systems.
* Expand disk coverage from Windows-centric NTFS to also include MBR and GPT partitions, and a bit more on non-NTFS file systems.
* There is brief mention of virtual machine software, VMWare, VirtualBox, Xen/KVM, QEMU. Second edition should have more discussion on virtual hardware/firmware issues, including ESP and pre-OS installed .efi drivers via UEFI Shell startup.ns.
* UEFI Shell pre-OS environment as a target, along with OS-level targets, including the shell commands to dump memory. Discuss the basics of capturing memory with tools like CHIPSEC, analysing ROMs with tools like UEFITool, UEFI Firmware Parser, and others, to search for strings, and figure out what modules are in the system.
* Discussion of Terse Executable (TE) variant of PE, which UEFI uses, along with Capsule update, firmware volume, FFS, and other containers for images.
* Discusses pre-OS memory issues along with OS memory issues. Enumerate the various forms of memory UEFI treats special, before and after OS handoff.
* There is brief discussion of malware hiding in video RAM. Add section discussing Option ROMs, Expansion ROMs, USB firmware, and additional firmware drivers/services optionally loaded via ESP and OEM/IHV flash. Discussion on different hardware busses that have these OpROMs, FFS and other formats used for storing drivers. Clarfication of the pre-UEFI ‘blobs’ and the UEFI PEIMs/DXE/UEFI drivers stored there.
* Discuss ACPI tables and how malware can use it, cover areas like WBPT which has Windows-centric PE executable image(s) in them.
* Cover UEFI’s variables, the different kinds and how they’re differently stored in memory and on disk/flash.

In summary, this book is great for OS-level memory forensics and using Volatility. I hope the second edition features a UEFI-aware Volatility and covers memory forensics for ‘negative rings’. And I hope the person who wrote the very nice Intel memory introduction does the same thing for ARM memory.

Book aside, Volatility also should port their project to run w/i UEFI Shell with UEFI’s Python, so it can directly acquire memory from this environment, and forensic examiners can use Volatility as a pre-OS tool, which has the best access to hardware/firmware areas where malware may be hiding. Also, Volatility needs plugins for CHIPSEC, UEFI Firmware Parser, and a half dozen other Python firmware parsing tools.

http://dl.acm.org/citation.cfm?id=2621971
http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118825098.html
https://github.com/volatilityfoundation
http://www.volatilityfoundation.org/