Category: Uncategorized

Hardware EU 2015

~ hucktech ~ Leave a comment

This year is the first “Hardware Security Conference and Training”, Sep29-Oct2, with 2 days of training, and 2 days of conference, in The Hague, Netherlands.

Hardware.io is the conference for hardware security researchers and companies to brainstorm on breaking and securing hardware: backdoors, exploits, trust, assurance and attacks on hardware equipment, firmware and related protocols. The objective of the conference revolves around four key concerns in hardware, firmware and related protocols i.e. backdoors, exploits, trust and attacks (BETA). Hardwear is owned and managed by the team behind nullcon, one of the premier security events in Asia.

Some of the talks:
* got HW crypto? On the (in)security of a Self-Encrypting Drive series, Christian Kison & Gunnar Alendal
* Security of Medical Devices, Florian Grunow
* Hardware Hacking with the Beaglebone (Bl|H)ack, Joseph FitzPatrick & Jeremy Richards
* Advanced Attack Methodologies against Security Microcontrollers, Marcus Janke & Dr. Peter Laackmann
* Demystifying the Sagemcom ECGI420 OneBox, Tamir Bahar
* Scan and Destroy: Opening A New Attack Surface With Barcode Scanners, Nitay Artenstein
* Advanced IC Reverse Engineering Techniques : In Depth Analysis of A Modern Smart Card, Olivier Thomas

Training:
* IC Security 101, Olivier Thomas & Dmitry Nedospasov
* Low level Hardware reversing, Javier Vazquez Vidal & Henrik Ferdinand Nölscher
* Applied Physical Attacks on X86 Systems, Joseph FitzPatrick

More Information:
http://hardwear.io/

Windows 10 and Secure Boot

~ hucktech ~ Leave a comment

Microsoft made Windows 10 available today, free upgrade for v7 and v8 users. The spec says:

“Secure boot requires firmware that supports UEFI v2.3.1 Errata B and has the Microsoft Windows Certification Authority in the UEFI signature database.”

For more information on Window 10’s firmware/hardware security requirements, look at Microsoft’s talk from the last UEFI Forum plugfest, from May: “Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot“, by Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft):

More Information:

http://www.microsoft.com/en-us/windows/windows-10-specifications

Click to access UEFI_Plugfest_May_2015%20Windows%2010%20Requirements%20for%20TPM%2C%20HVCI%20and%20SecureBoot.pdf

http://blogs.windows.com/bloggingwindows/2015/07/28/windows-10-free-upgrade-available-in-190-countries-today/

RISC-V Privileged Architecture Draft seeks feedback

~ hucktech ~ Leave a comment

RISC-V is an up-and-coming alternative Open Hardware architecture, BSD-licensed, with no IP. It isn’t ready for use today, may grow into a viable alternative in the coming months. Currently, they are looking for feedback for their Privileged Architecture Draft Specification:

“This is only a proposal at this point, and we welcome community feedback and comments on this draft. Please participate in the discussion on the public sw-dev and hw-dev RISC-V mailing lists, to which you can subscribe on the http://www.riscv.org website. We hope to freeze the core parts of this privileged architecture specification later this year. We will very shortly be releasing an updated Spike simulator and Linux port conforming to the proposed standard, along with QEMU updates to follow. A draft version of v1.8 of the spec is expected this summer, with a frozen v2.0 targeted for the fall. The draft Supervisor Binary Interface will be released with the next privileged ISA draft. It includes common functionality for TLB shootdowns, reboot/shutdown, sending inter-processor interrupts etc etc. This is a similar idea to the PALCode on the Alpha.”

They’re quite eager for some security feedback, in case there’re any hardware security experts here willing to help them out:

More Information:

Click to access riscv-privileged-spec-v1.7.pdf

Click to access riscv-privileged-workshop-june2015.pdf

https://blog.riscv.org/2015/05/risc-v-draft-privileged-architecture-version-1-7-released/
http://riscv.org/
http://www.lowrisc.org/

DEF CON 23

~ hucktech ~ Leave a comment

In DEF CON is happening shortly, or maybe it’s cancelled, I’m not sure. 🙂 Two talks immediately jump out:

ThunderStrike 2: Sith Strike

Trammel Hudson Vice President, Two Sigma Investments
Xeno Kovah Co-founder, LegbaCore, LLC
Corey Kallenberg Co-Founder, LegbaCore, LLC

The number of vulnerabilities in firmware disclosed as affecting Wintel PC vendors has been rising over the past few years. Although several attacks have been presented against Mac firmware, unlike their PC counterparts, all of them required physical presence to perform. Interestingly, when contacted with the details of previously disclosed PC firmware attacks, Apple systematically declared themselves not vulnerable. This talk will provide conclusive evidence that Mac’s are in fact vulnerable to many of the software only firmware attacks that also affect PC systems. In addition, to emphasize the consequences of successful exploitation of these attack vectors, we will demonstrate the power of the dark side by showing what Mac firmware malware is capable of.

and:

 
Attacking Hypervisors Using Firmware and Hardware

Yuriy Bulygin Advanced Threat Research, Intel Security
Mikhail Gorobets Advanced Threat Research, Intel Security
Alexander Matrosov Advanced Threat Research, Intel Security
Oleksandr Bazhaniuk Advanced Threat Research, Intel Security
Andrew Furtak Security Researcher

In this presentation, we explore the attack surface of modern hypervisors from the perspective of vulnerabilities in system firmware such as BIOS and in hardware emulation. We will demonstrate a number of new attacks on hypervisors based on system firmware vulnerabilities with impacts ranging from VMM DoS to hypervisor privilege escalation to SMM privilege escalation from within the virtual machines. We will also show how a firmware rootkit based on these vulnerabilities could expose secrets within virtual machines and explain how firmware issues can be used for analysis of hypervisor-protected content such as VMCS structures, EPT tables, host physical addresses (HPA) map, IOMMU page tables etc. To enable further hypervisor security testing, we will also be releasing new modules in the open source CHIPSEC framework to test issues in hypervisors when virtualizing hardware.

And that’s just the ‘tip of the iceberg, for talks… Teddy Reed (author of UEFI Firmware Parser) has a talk. Joe FitzPatrick (of SecuringHardware.com) has a talk. There’s a talk on hardware side-channel attacks, one on BadUSB-like security, one on hardware trust, on medical device security, and a few other firmware-related talks, around 31 hits to ‘firmware’ in the schedule! Amongst the Workshops, there are some fun ones, including: ARM for pentesters, and Embedded System Design. In the Villages, the Hardware Hacking Village and the IoT Village sound interesting.

More Information:
https://www.defcon.org/html/defcon-23/dc-23-schedule.html

https://plus.google.com/+DefconOrgplus/posts
https://www.defcon.org/html/links/dc-goons.html

SMM for OVMF

~ hucktech ~ Leave a comment

Earlier this month, Laszlo Ersek of Redhat contributed a large patch to the TianoCore project, adding SMM support to OVMF.

“OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure, and in the UEFI variable driver stack. The purpose is (virtual) hardware separation between the runtime guest OS and the firmware (OVMF), with the intent to make Secure Boot actually secure, by preventing the runtime guest OS from tampering with the variable store and S3 areas.”

The changes require QEMU usage with these flags:

qemu-system-i386-machine q35,smm=on,accel=(tcg|kvm)-global driver=cfi.pflash01,property=secure,value=on -smp cpus=1 …

This new OVMF SMM works on the q35 machine, only in uniprocessor guests, and with TCG acceleration it only works on x86 not x64. Apparently the lack of 64-bit support is due to 64-bit code not available in TianoCore(?):

“In addition, using OvmfPkgIa32X64.dsc or OvmfPkgX64.dsc, the patch set even stops building after a point, *if* -D SMM_REQUIRE is passed. This is due to the unavailability of 64-bit open source components from Intel, and the build breakage is fully intentional — it shows that the -D SMM_REQUIRE feature is build-level incomplete for OvmfPkgIa32X64.dsc and OvmfPkgX64.dsc, and marks precisely where further development is needed.”

More Information:

Check out the 58-part patch on the mailing list, the first and last messages have a lot more documentation:

https://lists.01.org/mailman/listinfo/edk2-devel

Android M Verified Boot UI changes

~ hucktech ~ Leave a comment

As reported by multiple online news sources, Android is getting some UI changes related to Verified Boot. Quoting Android Police article:

“Google has just added an interesting page to the Nexus support site that lists new operating system safety warnings. According to the page, this is a boot verification system that checks the integrity of your device software during each startup. You probably haven’t seen this on any devices yet, but Android M is right around the corner.”

More Information:
http://www.ibtimes.co.uk/android-m-introduce-googles-new-boot-verification-system-1512937
http://www.androidpolice.com/2015/07/27/google-posts-details-of-user-facing-verified-boot-system-probably-coming-in-android-m/
https://source.android.com/devices/tech/security/verifiedboot/index.html
https://support.google.com/nexus/answer/6185381

ZFS for FreeBSD’s for UEFI boot loader

~ hucktech ~ Leave a comment

From the FreeBSD Quarterly Status Report, FreeBSD’s boot loaders have a patch to support ZFS booting:

ZFS Support for UEFI Boot/Loader: UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem. The patch currently works with buildworld, and successfully boots on a test machine with a ZFS partition. In addition, the ZFS-enabled loader.efi can be treated as a chainloader using ZFS-enabled GRUB. The work on boot1.efi also reorganizes the code somewhat, splitting out the filesystem-specific parts into a modular framework. Open tasks:
1) More testing is needed for the following use cases: ZFS with GRUB+loader.efi, ZFS with boot1+loader.efi, UFS with boot1+loader.efi (to test the modularization of boot1.efi)
2) Have boot1.efi check partition type GUIDs before probing for filesystems.
3) Get patch accepted upstream and committed.

More Information:
https://www.freebsd.org/news/status/report-2015-04-2015-06.html#ZFS-Support-for-UEFI-Boot/Loader
https://wiki.freebsd.org/IdeasPage#ZFS_Boot_Environment_menu_for_GPT.2FEFI_boot
http://lists.freebsd.org/pipermail/freebsd-hackers/2015-March/047486.html
https://wiki.freebsd.org/UEFI#Tasks

index to tool review blogs

~ hucktech ~ Leave a comment

A reader asked for a list of tools I’ve written about. Sorry, I still need to learn WordPress to have an archives section here. In the mean time, below is a list of most of tools I’ve written blog entries on. I still have a few dozen that I need to write up…

tool mini-review: UEFI Reverse

tool mini-review: radare2

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

tool mini-review: BIO Unpack

tool mini-review: UEFI Xmod

tool review: uefi-spider (and firmware_vault)

Tool review: UBU-helpers

Two UEFI Form tools, plus one UEFI C Module complexity tool

tool mini-review: UEFI Firmware Parser

New LAVA tool from Collabora

Firmware Test Suite 15.06.00 released

mini-tool review: rEFInd

Ruby for UEFI

Lua for UEFI

Upcoming features in UEFI Python port

tool mini-review: UEFITool

MITRE Copernicus

Tool mini-review: bios_diff.py

tool mini-review: UEFI Reverse

~ hucktech ~ Leave a comment

UEFI Reverse (uefireverse) is a collection of tools to help with analysis of UEFI-based firwmare, written by Jethro Beekman (jethrogb). It consists of four tools.

1) EFI PE Run (efiperun): Load and run EFI PE image files on Linux.

DISCLAIMER: This program loads and runs PE image files. It does this without any protection mechanisms. Certain memory sections will be mapped writable and executable simultaneously. Do not run this on untrusted software. Think carefully before running this on trusted software. Load and run EFI PE image files on your favorite operation system (Linux). PE images are just x86 code that will run fine as long as the environment is correct. efiperun is to EFI as Wine is to Windows, but much less advanced. This tool is not meant for long-term use and only for debugging. There’s instrumentation everywhere, which is great for debugging but makes things slow.Memory generally doesn’t get freed. Most EFI functionality is not implemented. Functions that are implemented only provide the bare minimum. This tool aims to aid in debugging/reverse engineering by providing a framework that you can extend as necessary. By default, this program will load a PE image specified on the command-line, call the entry point, and exit once that returns. If the entry point does not return in 10 seconds, the program will abort with SIGALRM. Beyond running images, you can also extend this execution, with a “debug module”, an extension to efiperun that can run code before and after loading a PE image. This is useful to install protocols beforehand that the PE image will use or to access the protocols that the PE image installed afterwards.

See the tool’s readme, there are more ways to hook into the execution process.

2) GUID DataBase (guiddb): Create C source listing of TianoCore GUIDs.

A few programs that Scan EDK-II .DEC build files for GUIDs, and output them in C-source file format.

(There are about 4 GUID tools by different authors. One of these days, I’ll need to compare the various UEFI GUID tools’s output to see which’re more accurate…)

3) Memory Dump (memdmp): Tools to dump UEFI memory.

First, there’s a patch against UEFI Shell’s “memmap” dump memory command to pipe that to a file called “mdmp”. Then, run “dmp2seg” to convert that output file into many files with the actual memory contents. Then, run “make_elf.rb” to make a single ELF file with all the memory contents. The ELF file is not executable or anything, it’s just a convenient format to store memory segments.

4) Tree (tree): Ruby firmware tree on your filesystem.

A class file that will provides a Ruby tree abstraction for a firmware tree on your filesystem previously extracted by UEFITool’s UEFIExtract tool.

UEFI Reverse is a collection of some specialized UEFI research tools that may help augment your toolbox.

UEFI Reverse-aside, Jethro also has some TPMv2 project as well, that is worth checking out, if you use Linux and are into TPMs…

More Information:

https://github.com/jethrogb/uefireverse
https://github.com/jethrogb/tpm2-utils

tool mini-review: radare2

~ hucktech ~ Leave a comment

[If you’re already familiar with radare2, and it’s firmware — and EBC — abilities, then skip this blog.]

In 2014, Anton Kochkov gave an interesting talk: “Reversing firmware using radare2”. The scope of ‘firmware’ used in the presentation includes a wide range, UEFI, BIOS, to peripherals. Actually, the talk isn’t that interesting for information on radare, since most of the fun stuff were in the demos, not shown in the slides. IMO, the most interesting parts are the first half of the slides, before radare is introduced, where the speaker gives an interesting overview of some known silicon and firmware attacks. The last few slides mention a few other firmware security tools besides radare: UEFI Tool, BIOS Extract, FlashROM, Bus Pirate, and a few QEMU-based emulators. The presentation has MANY pointers to more information, I’ve queued up about a dozen things to read as a result of reading this. 😦

Radare is an open source reverse engineering tool, it has GUI and command line interfaces. It is peer of IDA, disassembling code is the main focus.

It supports many architectures: 6502, 8051, CRIS, H8/300, LH5801, T8200, arc, arm, avr, bf, blackfin, csr, dalvik, dcpu16, gameboy, i386, i4004, i8080, m68k, malbolge, mips, mips, msil, nios II, powerpc, rar, sh, snes, sparc, tms320 (c54x c55x c55+), V810, x86-64, and zimg. It supports many file formats: bios, dex, elf, elf64, filesystem, java, fatmach0, mach0, mach0-64, MZ, PE, PE+, TE, COFF, plan9, bios, dyldcache, Gameboy and Nintendo DS ROMs. It supports many operating systems: Android, GNU/Linux, [Net|Free|Open]BSD, iOS, OSX, QNX, w32, w64, Solaris, Haiku, and FirefoxOS. It has multiple language bindings: Vala/Genie, Python (2, 3), NodeJS, LUA, Go, Perl, Guile, php5, newlisp, Ruby, Java, and OCAML.

Radare’s GUIs aside, the r2 command line UI offers nice use of colors and graphics to correlate assembly language features, somewhat like how Scapy does with network packets.

Radare definitely looks like a useful tool for firmware researchers. A Google Search for radare and firmware results in lots of existing research and tutorials. Apparently, I’m the last person to learn about radare. 😦

Best yet: radare supports EFI Bytecode (EBC)!! They added EBC support, started about 2 years ago. Search for TARGET_EBC in the code. They don’t list EBC in their architecture list (above), so I’ve yet to see how well it works.

Note also in above list, they support TE executable images, and some level of “BIOS” support (yet to determine what that means).

[I was about to write a paragarph about how UEFI Forum should sponsor EBC support in LLVM, so that radare can benefit from LLVM’s intermediate representation, as well as providing an alternative compiler to the single EBC-targetting compiler, the COMMERCIAL-ONLY Intel C Compiler. But since radare already manually added EBC support to their tool, the need for LLVM as a target is no longer as important, UEFI Forum could target either GCC or LLVM, since radare has dealt with EBC themselves. We still need an alternative, non-commercial, open source EBC-targetting C compiler, though!]

[[UPDATE: The above paragraph is wrong, w/r/t radare and LLVM: Capstone is the RE tool that uses LLVM intermediate language, not radare, sorry. http://www.capstone-engine.org/arch.html ]]

More Information:

Click to access h2hc2014-reversing-firmware-radare-slides.pdf

https://github.com/radare/radare2/search?q=EBC
http://www.radare.org/
https://github.com/radare/radare2

RMS blesses Crowd Supply for Open Hardware OEM use

~ hucktech ~ Leave a comment

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

~ hucktech ~ Leave a comment

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?

~ hucktech ~ Leave a comment

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

~ hucktech ~ 1 Comment

[[ 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

~ hucktech ~ Leave a comment

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

~ hucktech ~ Leave a comment

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

~ hucktech ~ Leave a comment

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

~ hucktech ~ Leave a comment

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

~ hucktech ~ Leave a comment

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