RMS blesses Crowd Supply for Open Hardware OEM use

Crowd Supply, the crowfunding platform for Open Hardware OEMs, was blessed this week by RMS and the FSF. Crowd Supply has helped new hardware startups and “Micro OEMs” like Bunnie Studios’ Novena, Purism’s Librem, and Inverse Path’s USB Armory.

“The FSF has selected Crowd Supply as its preferred crowdfunding platform, and will recommend Crowd Supply to hardware and software creators looking to crowdfund, sell or purchase products online. And third, Crowd Supply and the FSF will work together to promote and launch new software and hardware products that adhere to FSF’s guiding principles, with the first project to be announced soon.”

I am *VERY* eager to see more startups creating Open Hardware-based systems! I am looking forward to a few years from now when RISC-V-based devices start showing up on CrowdSupply…!

Going further, the FSF and Linux Foundation need to proactively start building the missing components, not waiting for Intel/ARM and OEMs to create Open Hardware, there’s little motivation for them to change their ways and their IP policies. The FSF needs to — first define, then… — fund Free Hardware, if they’re going in a separate direction from OSHWA’s Open Hardware. Personally, I wish the FSF would partner with OSHWA and focus on Open Hardware, instead of splintering the few non-closed hardware resources/efforts/funds.

More Information:
https://www.crowdsupply.com/free-software-foundation-endorses-crowd-supply-for-respecting-users-software-freedom
http://www.fsf.org/news/fsf-endorses-embedded-gnu-linux-distro-proteanos-as-fully-free
http://arstechnica.com/information-technology/2015/07/founder-of-gnu-bestows-blessing-upon-open-source-crowdfunding-site/

OSCON post-conference proceedings

OSCON2015, the O’Reilly Open Source Convention, just ended. In addition to Matthew’s TPM CloudOS talk, there were a few other interesting talks:

Building a trustworthy computer
Matthew Garrett (CoreOS)
As we become more and more reliant on our computers, attackers become more and more sophisticated. How can we build a computer that’s resilient to some of the more subtle attacks such as firmware modification?
http://cdn.oreillystatic.com/en/assets/1/event/129/Building%20a%20trustworthy%20computer%20Presentation.odp

Closed devices powered by open source software? The IoT Paradox.
Peter Hoddie (Marvell)
The Internet of Things is built on open source software, and yet the devices are far from open. This isn’t the future that free and open source contributors have been working toward. It’s a disappointment for the Open Source Community, but we can lead the way to freedom, transparency, and collaboration in IoT. And we must—to avert impending frustration for increasingly savvy consumers.
http://cdn.oreillystatic.com/en/assets/1/event/129/Closed%20devices%20powered%20by%20open%20source%20software_%20The%20IoT%20Paradox_%20Presentation.pdf

Hacking smart electronics
Robert Gallup (XOBXOB)
Prototypes allow us to see, touch, feel, and refine ideas and designs. Starting from zero, this hands-on workshop explores smart hardware prototyping using a micro-controller and basic electronic components. You’ll connect LEDs, buttons, and knobs, then program a micro-controller to define behavior. Through this you’ll better understand the tools and process of designing smart, connected products.
http://cdn.oreillystatic.com/en/assets/1/event/129/Hacking%20smart%20electronics%20Presentation.zip
http://robertgallup.github.io/get/OSCONCourseware.zip

Introduction to developing embedded Linux device drivers
Nick Gudman (Hewlett Packard)
Learning to develop device drivers can be intimidating, but Linux makes it simpler than ever to write your own device driver. Using a simple driver for a monochromatic character display as a guide, we will briefly explore important topics for developing embedded Linux device drivers.
http://cdn.oreillystatic.com/en/assets/1/event/129/Introduction%20to%20developing%20embedded%20Linux%20device%20drivers%20Presentation.odp

Ironic: A modern approach to hardware provisioning
Devananda van der Veen (HP Cloud)
Ironic is a modern tool for hardware provisioning. Combining a RESTful API, scalable control plane, and pluggable hardware drivers, Ironic installs operating systems efficiently and repeatably on diverse hardware. We will demonstrate Ironic with Ansible, install, build, and deploy a machine image, and discuss the project’s architecture, history, and goals. Deep knowledge is not required.
http://cdn.oreillystatic.com/en/assets/1/event/129/Ironic_%20A%20modern%20approach%20to%20hardware%20provisioning%20Presentation.pdf

Raspberry Pi hacks
Ruth Suehle (Red Hat), Tom “spot” Callaway (Red Hat)
Ruth Suehle and Tom Callaway, authors of _Raspberry Pi Hacks_ (O’Reilly, December 2013) offer technical tips for makers, hackers, and tinkerers who want to take advantage of the Raspberry Pi. You’ll learn universally useful things, like how to add a power switch, followed by a show-and-tell of fun things that Ruth and Tom as well as many others have built.
http://cdn.oreillystatic.com/en/assets/1/event/129/Raspberry%20Pi%20hacks%20Presentation.pdf

Using open source tools to secure containers and clouds
Derek Thurston (Booz Allen Hamilton)
Is your cloud secure? Is your cloud of containers secure? Security should be built-in from Day Zero, and not layered in as an afterthought. What open source tools are out there now to help you in your quest to not be on the front page of the news? How are all of the latest hacks happening, and how can we put tools in place to prevent these from happening again?
http://cdn.oreillystatic.com/en/assets/1/event/129/Using%20open%20source%20tools%20to%20secure%20containers%20and%20clouds%20Presentation.ppt

I’m sure there’re some other gems too, the above list is what caught my eye… Mr. O’Reilly, please make the video — or at least audio — publicly-available too, don’t just for post-conference proceedings!

http://www.oscon.com/open-source-2015/public/schedule/proceedings

What is the safest firmware solution?

Stephan of the coreboot project is currently having a Twitter conversation with some others. It includes this post:

This makes me wonder, has anyone compared Chrome’s Verified Boot with UEFI’s Secure Boot. With and w/o TPM chip on Intel or TrustZone on ARM. It would be nice if some cyypto-savvy researchers could analyze the crypto used in both implementations and give a comparison, including how these solutions meet the NIST and NSA/CC criteria for securing BIOS.

In terms of code size, coreboot has a much smaller codebase than tianocore, even with the all the additional size that Chrome brings to it’s coreboot dialect. But both Secure Boot and Verified Boot are nearly the same in terms of PKI.

On a related not, I’ll do a future blog post looking into the various boot flavors: Trusted Boot, Secure Boot, Measured Boot, Verified Boot, etc.

LUV 2.0-RC2 released

[[ UPDATE: Comment from Ricardo Neri of Intel on the checksums: The checksum file is in the same directory as the source tarball:
https://download.01.org/linux-uefi-validation/v2.0/
https://download.01.org/linux-uefi-validation/v2.0/sha256_sums.asc
I thought I checked there before commenting on this, but I probably missed it. Sorry! ]]

Today Ricardo Neri of the Intel LUV team announced the release of LUV 2.0-RC2 release.

It updates the bits to fresher ones: Yocto Fido, Linux kernel 4.1, FTWS 15.7.0, BITS 1219, and CHIPSEC 1.2.1, as well as improvements in the HTML output of LUV’s test manager. IMO, fresh test suites are reason enough for updates, beyond additional changes, especially CHIPSEC 1.2.1 update…

PS: There was no checksum in the announce email, nor any on the web site which I could find. It would be nice to include that kind of information in future releases.

More Information:
https://download.01.org/linux-uefi-validation/v2.0/luv-live-v2.0-rc2.tar.bz2
http://lists.01.org/pipermail/luv/
https://01.org/linux-uefi-validation

Hacking Team had other bootkits

Vlad Tsyrklevich wrote an excellent aritcle on the 0-day market via analyzing the Wikileak’ed Hacking Team emails:

http://tsyrklevich.net/2015/07/22/hacking-team-0day-market/
https://twitter.com/vlad902/status/623950714247749632

Most have already read about the UEFI malware that it used, including this Intel ATR analysis:
http://www.intelsecurity.com/advanced-threat-research/blog.html

Beyond this UEFI malware, Vlad’s analysis of the Wikileaks email revealed at least 2 other firmware exploits that Hacker Team appeared to have been using:

08/19/13,  ASUS BIOS device driver LPE, Firefox RCE added

02/24/14, “Apple iOS Remote Forced Access-Point Association”/“Apple iOS Remote Forced Firmware Update Avoidance” no longer available, OpenPAM (used on BSDs) LPE added

See Vlad’s blog for pointers to other Wikileaks.org-based email articles on these two entries.

I wish there was a list of former 0-days, at least the firmware subset… I also wish there was a safe place to download the “Uefi_windows_persistent.zip” and “Z5WE1X64.fd” files listed in the Intel ATR blog.

Matthew Garrett hardware talk at OSCON

As reported on by Seth on the Cypherpunks list, Matthew Garrett of CoreOS gave a talk earlier today at OSCON, on open hardware design, with a security background. OSCON is The O’Reilly Open Source Convention, probably the largest open source convention in North America. The slides are online, no audio/video yet, AFAICT. (I hope OSCON doesn’t continue to charge for access to post-conference video…)

http://www.oscon.com/open-source-2015/public/schedule/detail/41536

http://cdn.oreillystatic.com/en/assets/1/event/129/Building%20a%20trustworthy%20computer%20Presentation.odp

 

Building a trustworthy computer
Matthew Garrett (CoreOS)
11:10am–11:50am Friday, 07/24/2015

The Snowden revelations demonstrated the lengths that government agencies  
were willing and able to go to in order to subvert computers. But these  
attacks aren’t limited to state-level actors – security researchers  
continue to demonstrate new vulnerabilities and weaknesses that would  
permit sophisticated criminals to achieve the same goals.

In the face of these advanced attacks, what can we do to detect and  
mitigate them? How can we make use of existing security features, and what  
changes can we make to system design? In short, how can we ensure that a  
user can trust that their computer is acting in their interests rather  
than somebody else’s?

This presentation will cover some of the existing security features and  
recent design changes in systems that can make it easier to detect  
attacks, and provide mechanisms for defending against them in the first  
place, along with simple design changes that would make it easier for  
users to ensure that components haven’t been backdoored. In addition it  
will discuss some of the remaining challenges that don’t have solid  
answers as yet. Topics covered will include: Firmware security, Trusted
platform modules, attestation, and associated privacy risks, Hardware
design to support offline verification, Remaining components that could
act against the interests of the  hardware owner

Matthew Garrett is a security developer at CoreOS, specializing in the  
areas where software starts knowing a little more about hardware than  
you’d like. He implemented much of Linux’s support for UEFI Secure Boot,  
does things with TPMs and has found more bugs in system firmware than he’s  
entirely comfortable with.

Tianocore web site updated

As reported by the Intel UEFI Twitter feed, the UEFI Forum’s web team have done a complete overhaul to the TianoCore.org web site:

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

http://www.tianocore.org/
http://www.tianocore.org/contrib/
http://www.tianocore.org/contrib/getting-started.html
http://www.tianocore.org/edk2/
http://www.tianocore.org/news/feed.xml

There are a few other web pages, not many more; most others are github-hosted web pages now.

This news was found on the Twitter feed of Brian Richardson of Intel, which was not on my previous 0.3 release of Twitter feeds, but will be in next 0.4 release:
https://twitter.com/Intel_Brian

On a related note, the edk2-devel mailing list finally moved from SourceForge to 01.org:
https://github.com/tianocore/tianocore.github.io/wiki/edk2-devel

Bunnie on closed phone platforms

Earlier this week, bunnie Huang, creator of Bunnie Studios and the open hardware-based Novena system, created a video on YouTube that helps remind people about how closed phone-based computers are, how little options consumers have, and the need for more openly-available (unlocked), Open Source Hardware, firmware, and software options, for the community to be able to drive things, not just a handful of corporations.

“The phone lies at the foundation of 21st century human (and non-human) communication, and shapes these exchanges for the hand, for the eye, and in the mind. The video was created by bunnie huang and Kevin Slavin. 

http://www.bunniestudios.com/
https://www.crowdsupply.com/sutajio-kosagi/novena

‘Silicon autopsy’ tools for ARM

Earlier this week Eoin McCann posted a new article in the ARM Processors blog about ‘silicon autopsy’: dealing with silicon errors on ARM systems. Of course it’s a bit of a product pitch for ARM’s CoreSight and related products, but product pitch aside the blog give a good description of the various problems and tools available for those performing ARM-based silicon autopsies. ARM has a free Community Edition as well as an expensive Ultimate Edition of DS-5, ARM’s Eclipse-based Developer Studio IDE for firmware.

Excerpt:
Silicon autopsy: Understanding when chips fail: In a lot of ways debug is similar to being a medical doctor. A patient comes in with some complaints and lists their symptoms, but you need to run tests in order to properly diagnose the issue before focusing the mind on how to fix it. A lot has been written and discussed in the past about debugging hardware, but most of the attention is dedicated to the pre-silicon stage when issues can be identified close to the source and rectified before it is too late. These bugs are similar to performing an autopsy on a body, sifting through all of the potential clues to narrow down what has gone wrong, and how it can be rectified. Bugs that are found in the silicon itself are typically much more difficult to identify, and can drain an enormous amount of time and resources to fix properly. Today I will speak about silicon debug, the challenges associated with it and what can be done to improve it.

More Information:
http://ds.arm.com/
http://community.arm.com/groups/processors/blog/2015/07/20/silicon-autopsy-understanding-when-chips-fail

tool mini-review: untermensch UEFI Windows Secure Boot injection tools

Back in 2013, Untermensch wrote a series of tools to help with Windows8 UEFI Secure Boot testing.

Since I mostly use Unix-based platforms these days, I haven’t dug deep into this tool.

If you’re a security researcher who is looking into vulnerablties in Windows use of Secure Boot, these tools may be very useful to you.

Be very careful using the tools, they come with a strong warning:

CAUTION: this module is experimental!!! Be prepared to recover a bricked motherboard!
For best results use MMTool to replace module!!

WindSLIC:
WindSLIC SLIC injectors: includes UEFI, NTFS, bootmgr SLIC injectors and installers.

Injector:
UEFI SLIC injector alternate method: uses alternate method to inject SLIC into ACPI tables use LicenseData.exe to add key, marker & slp string to nvram.

FirmwareModule:
UEFI SLIC injector firmware module: build process generates an ffs image. use MMtool.exe to replace MSOA in target firmware. flash modified firmware use InstallData.cmd to write Marker, Key, Slp string to NVRAM.

More Information:
https://github.com/untermensch/WindSLIC
https://github.com/untermensch/Injector
https://github.com/untermensch/FirmwareModule

Post 4.1 improvements in coreboot

The other day, coreboot 4.1 was released. The coreboot blog recently summarized some recent new changes and features, covering 4.1 up to current (commit 406effd5). Summarizing new features and support:

* 1 new chipset: Intel Skylake SoC
* 4 mobos: google/cyan, intel/kunimitsu, intel/sklrvp, and intel/strago
* Some build script improvements.
* USB host drivers in libpayload have multiple improvements.
* Changes to the CBFS format.
* Many bugfixes, especialy in ARM64 and Nvidia Tegra210, and Google Foster and Smaug boards.

See the coreboot blog for more details.

coreboot changelog – Week of 2015-07-13

There’s also a “summer of code” for coreboot, with multiple projects, that’ve been happening for weeks now. I’ve not covered those yet, I was going to wait for the end-of-Summer, but if you haven’t looked at the projects, they’re in older entries in the coreboot blog.

tool mini-review: BIO Unpack

BIO Unpack is a small Python tool written by By Anton Kochkov (XVilka) in late 2013. The tool unpacks *.BIO and *.CAP EFI capsule files.

Usage: bio_unpack.py bios.rom [start offset]

Hmm, WordPress doesn’t let me use an HTTPS-prefixed URL for gist.github.com-based URLs, it omits the URL entirely. I had to remove the https prefix to make the below line appear on WordPress:

gist.github.com/XVilka/8163272

PS: I didn’t know about Github’s gist snippets service until today; thanks to DC206’s Osman for the indirect pointer! 🙂

Apple issues firmware update

Today, Apple issues an update for MacBook Pro systems:

“MacBook Pro Flash Storage Firmware Update 1.0

This update is recommended for MacBook Pro (mid 2015) models. This update addresses a storage firmware issue that, in rare cases, may cause data corruption.”

I don’t know any more details of any security fixes…

https://support.apple.com/kb/DL1830?locale=en_US
https://support.apple.com/downloads/DL1830/en_US/macbookproflashstoragefwupd1.0.dmg

LegbaCore Mac firmware bricking demo and upcoming training

Yesterday LegbaCore published a video of a bricking demo of a a Mac Mini firmware vulnerability.

https://www.youtube.com/watch?v=LEEEazuc8Dg&feature=youtu.be

“Apple does not follow Intel’s recommended best practices for protecting their firmware. Consequently Macs are vulnerable to being disabled in such a way that they can never be made bootable again either by attempting to boot off external media (like a DVD/USB) and reinstalling the OS, or by changing the entire HD/SSD with a known working one. The only way to recover from such attacks is to reflash the SPI flash chip with a known-clean copy of the firmware. This attack does not require physical presence. It can be launched via a remote connection to the system (e.g. SSH/VNC).”

https://twitter.com/legbacore/status/624062348324528128

LegbaCore has some upcoming training at HackInTheBox Singapore in October, and it appears this 3-day training will cover some of this new Apple EFI research:

https://twitter.com/coreykal/status/624210503766663168

http://www.legbacore.com/Training.html
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/

LegbaCore Summer Tour announced

AMIDebug

[UDPATE: comment from a smart reader:
AMIDebug technology is not useful for end users and researchers because it’s support should be specifically compiled in in a special DEBUG build. The AMI DebugRX hardware part is OK to get port 80h codes via USB, mediocre source-level debugging. Intel XDP or Arium-ITP are similar to AMIDebug, both nice products, and don’t require any firmware changes or special build modes.
BTW, I don’t know why Comments don’t show up on blog web site, working on trying to fix that… ]

Earlier this week AMI announced USB3 support for their AMIDebug for UEFI product.

Apparently AMI has 3 versions of this: 1) AMIDebug for UEFI software for Aptio V, 2) the AMIDebug Rx handheld USB debug device, and 3) Aptio V UEFI Firmware from AMI.

Press release excerpts:

American Megatrends, Inc. (AMI), a global leader in BIOS, remote management, network data storage products and solutions for the Android(TM) operating system, is pleased to announce support for USB 3.0 controllers in the latest release of its AMIDebug(TM) for UEFI debugging solution for Aptio(R) V UEFI Firmware.

AMIDebug for UEFI from American Megatrends is a powerful software-based solution for debugging UEFI projects based on Aptio or the UEFI Shell, offering source-level symbolic (C and Assembler) debugging without the need for expensive JTAG hardware debug tools.

The latest AMIDebug for UEFI release, developed specifically for the company’s flagship Aptio V UEFI Firmware, adds support for USB 3.0 debug among other important features. These newly-added features signify a key development in the evolution of this debug software, since many chipsets now only support USB 3.0 (XHCI) and in many cases no longer incorporate older USB standards (EHCI) in their hardware designs, such as the Intel(R) Atom(TM) x5-Z8300 series processors.

What remains unchanged in AMIDebug for UEFI is its ability to facilitate firmware development for AMI OEM and ODM customers in unprecedented ways thanks to its deep integration into the entire UEFI development ecosystem. AMIDebug for UEFI continues to offer standard debugging features like Break, Step, Step Over, Step Into, Step, run to cursor and set next statement, in addition to UEFI-specific debugging features like Stop at Driver Name Entry, Stop at PEIM Name Entry, Stop at CheckPoint, Stop at beginning of PEI/DXE, SMM Debugging and disassembly view. Moreover, many different firmware development viewers are supported including memory, CPU registers, PCI Bus, call stack, I/O and Indirect I/O.

Sigh, I wish these were available for UEFI ISVs and UEFI Security Researchers, not just restricted to AMI’s UEFI OEM/ODMs! I want one. 😦

More Information:

http://www.ami.com/news/press-releases/?PressReleaseID=322&/American%20Megatrends%20Announces%20Support%20for%20USB%203.0%20Controllers%20in%20Aptio%20V%20AMIDebug%20for%20UEFI/
http://www.ami.com/products/bios-uefi-tools-and-utilities/amidebug-rx/
http://www.ami.com/resources/resource-library/?documentationSearch=amidebug

Firmware Twitter feeds, v0.3

2015-08-14 UPDATE: see also this EXCELLENT list:
https://twitter.com/JacobTorrey/lists/firmware-security/members

The below list is outdated, I’ll make a newer one soon…..

Firmware-related Twitter feeds, v0.3

Change from last release: added about half a dozen security researchers, with help from one of them (thanks!).

BIOS/UEFI security researchers:

https://twitter.com/JacobTorrey

Intel:

https://twitter.com/firmwareengine
https://twitter.com/intel_uefi

coreboot:

Other chips:

Hashtags:
https://twitter.com/hashtag/BIOS
https://twitter.com/hashtag/UEFI

TODO: AMD, ARM, other chip makers, OEMs, IHVs, IBVs, other UEFI Forum members…
TODO: Learn WordPress, store link resources on page not as blog entries.

Tutorial on using EDK-II’s Linux emulator

Today Jey Jay (LinuxKernelSeeker) has a blog post on how to use TianoCore with Linux, using the EDK2 emulator.

“This post will explains the steps involved in compiling EmulatorPkg of Tianocore EDK2. Who wish to learn UEFI can use this emulator for writing UEFI samples.” …

It is a good article, some of the Tianocore readmes for Linux are fairly vague (and/or referencing outdated distro releases that’re no longer available), so it is nice to have a tutorial talking about a fresh release, including some screenshots to be even more user-friendly.

More Information:

http://linuxseekernel.blogspot.com/2015/07/uefiedk2-emulatorpkg-in-ubuntu.html

Intel ATR posts RECon and CSW presentations

Yesterday, Intel Advanced Threat Research (ATR) released presentations of two recent talks they’ve given on BIOS/SMM/UEFI security.

1) Attacking and Defending BIOS in 2015
Advanced Threat Research, Intel Security
RECon 2015

In this presentation we will demonstrate multiple types of recently discovered BIOS vulnerabilities. We will detail how hardware configuration is restored upon resume from sleep and how BIOS can be attacked when waking up from sleep using “S3 resume boot script” vulnerabilities. Similarly, we will discuss the impact of insufficient protection of persistent configuration data in non-volatile storage and more. We’ll also describe how to extract contents of SMRAM using above vulnerabilities and advanced methods such as Graphics aperture DMA to further perform analysis of the SMM code that would otherwise be protected. Additionally, we will detail “SMI input pointer” and other new types of vulnerabilities specific to SMI handlers. Finally, we will describe how each class of issues is mitigated as a whole and introduce new modules to CHIPSEC framework to test systems for these types of issues

http://www.intelsecurity.com/advanced-threat-research/content/AttackingAndDefendingBIOS-RECon2015.pdf

2) A New Class of Vulnerabilities in SMI Handlers
Advanced Threat Research, Intel Security
CanSecWest 2015

This presentation will discuss security of SMI handler components of system firmware including the nature of a new class of vulnerabilities within the SMI handlers of BIOS/UEFI based firmware on various systems. It will also discuss how systems can be tested for these vulnerabilities and what can be done in firmware implementations to mitigate them. Additionally, the presentation will also discuss how S3 resume affects security of the system and problems with S3 resume boot script in some BIOS implementations recently discovered and presented at 31C3.

http://www.intelsecurity.com/advanced-threat-research/content/ANewClassOfVulnInSMIHandlers_csw2015.pdf

More Information:
http://www.intelsecurity.com/advanced-threat-research/index.html
and
http://c7zero.info/home.html#research