Month: July 2015

Jeff Thomas leaves Sage Engineering

~ hucktech ~ Leave a comment

Hmm, I don’t understand what is happening at Sage Engineering, it looks like there are are multiple coreboot people who are looking for a job(?), see below bold sentences (emphasis mine):

http://www.se-eng.com/2015/07/so-long-and-thanks-for-all-the-fish/

I woke up this morning dreaming about different chipsets and boot solutions, though quickly realizing there was no longer a reason. Because today I’m writing my last blog for Sage Electronic Engineering. Along with myself, the change the technical to non-technical writer, there are a lot of fine coreboot engineers now looking for work. I’d like to thank everyone who followed this blog, notably Vincent Zimmer at Intel, as it has meant a lot to me, as well as my company. I’d also like to thank Sage CEO Scott Hoot and VP of Marketing Dennis Batchelor for having me along, as well as the numerous engineers and managers, Drew Jensen and Steve Goodrich come to mind, I’ve bothered with questions along the way. I enjoyed working here very much. Mostly, I’d like to note that I never did get around to writing about owner/engineer  Kimarie Hoot, who certainly deserves an award for both a woman in software and a woman in business. Some publicist I am. Kimarie is much more than a credit to her gender and electronic engineering. I’m not sure what’s going to happen to some very fine engineering here at Sage, especially the SageBIOS for Intel and AMD processors, but I’d like to believe it will be available in some form. Seems like an incredible waste otherwise. Everyone I’ve worked with here has been a credit to x86 embedded development. When they asked me what I knew about BIOS and firmware when I interviewed here, I said, “Well I’ve updated BIOS on my laptop, pretty much know what that does, and I’ve flashed a couple of routers — that’s about it.” Hopefully, I’ve found my way around a bit since then. Anyway, my last stab at humor, and there have been some outstanding failures in this department, comes from the Hitchhiker’s Guide to the Galaxy series. So long, and thanks for all the fish.

New FCC requirements may impact use of open source firmware

~ hucktech ~ Leave a comment

The FCC has new regulation that may impact embedded system, unclear how this impacts UEFI’s WiFi usage on embedded systems. I’ve not looked into this yet, so I’ll defer to some existing news sources. Quoting the InfoQ article:

“The United States Federal Communications Commission (FCC) has introduced ‘software security requirements’ obliging WiFi device manufacturers to “ensure that only properly authenticated software is loaded and operating the device”. The document specifically calls out the DD-WRT open source router project, but clearly also applies to other popular distributions such as OpenWRT. This could become an early battle in ‘The war on general purpose computing’ as many smartphones and Internet of Things devices contain WiFi router capabilities that would be covered by the same rules. The rules are apparently motivated by a desire to ensure that devices operated within the US comply to FCC regulations on radio frequency spectrum management and power output. Given the size of the US market, and manufacturers’ desire to create products that reach a global market, the rules are likely to have a global impact. This regulation applies to U-NII devices operating in the 5GHz band, though as dual band systems have become more popular, in routers and phones, this will increasingly apply to most devices with WiFi.”

More Information:

New FCC Rules May Prevent Installing OpenWRT on WiFi Routers


http://www.infoq.com/news/2015/07/FCC-Blocks-Open-Source
https://news.ycombinator.com/item?id=9959088

ARM acquires Sansa Security for IoT security

~ hucktech ~ Leave a comment

Yesterday ARM Ltd announced acquisition of Sansa Security, the acquisition will offer hardware and software-based security features, boosting protection for sensitive data and content on any connected device. Press release:

ARM has acquired Israel-based Sansa Security, a provider of hardware security IP and software for advanced system-on-chip components deployed in IoT and mobile devices. The company currently enables security in more than 150 million products a year and Sansa Security technology is deployed across a range of smart connected devices and enterprise systems. The deal complements the ARM security portfolio, including ARM(R) TrustZone(R) technology and SecurCore(R) processor IP. Terms have not been disclosed.

“Any connected device could be a target for a malicious attack so we must embed security at every potential attack point,” said Mike Muller, CTO, ARM. “Protection against hackers works best when it is multi-layered, so we are extending our security technology capability into hardware subsystems and trusted software. This means our partners will be able to license a comprehensive security suite from a single source.”

Sansa Security technology makes it easier for manufacturers to build secure products by offering a complete hardware subsystem that adds additional isolation of security operations from the main application processor. This is complemented by software components operating on top of trusted execution environments to perform security-sensitive operations. The acquisition builds upon ARM’s embedded TrustZone technology, creating extra protection against malware and malicious software. It is a system-wide approach that underpins security-related chipset and trusted software needs. This enables the protection of any connected device and management of sensitive data and content.

“Our technology is already being used to protect data gathered and transmitted by a multitude of IoT and mobile devices,” said Coby Sella, CEO, Sansa Security. “Joining ARM will enable us to scale the business by helping ARM’s global technology partners to address their most pressing security needs. Aligning what we do with the world’s leading IP company, allows us to develop our products and capability to new levels.”

Security forms one of the main pillars of ARM’s business. The company offers the world’s most comprehensive IP security portfolio for smart connected devices. The acquisition of Sansa Security is the latest in a series of acquisitions and product launches aimed at simplifying the development and deployment of secure connected devices. Other activity in the development of ARM’s IoT business during the last 12 months includes:

    June 1, 2015: Launched a IoT sub-system IP package to de-risk the design cycle for IoT chips
    April 16, 2015: Launched ARM Cordio(R), the IT industry’s first sub-one-volt self-contained radio block and related firmware to simplify radio deployment in IoT devices
    Feb. 24, 2015: Launch the ARM mbed(TM) IoT starter kit to simplify the process of adding IoT capabilities and secure cloud connectivity for device manufacturers
    Feb. 9, 2015: Announced the acquisition of Offspark to integrate the world’s most pervasive embedded Transport Layer Security (TLS) solution in to the ARM mbed portfolio
    Oct. 1, 2014: Launched ARM mbed, a new software platform and free operating system to simplify and speed up the creation and deployment of Internet of Things (IoT) products.

Sansa Security is a world-leading provider of system-wide security operating from the silicon chipset level to provisioning security in the enterprise cloud. Its technology enables the creation of secure devices through hardware security IP that complements ARM TrustZone. The company’s trusted software security IP, running in TrustZone-based Trusted Execution Environments, also protects code and data assets. Sansa Security’s IP will be integrated in to ARM’s TrustZone and IoT portfolios.

More Information:
https://www.sansasecurity.com/

http://www.arm.com/about/newsroom/arm-expands-iot-security-capability-with-acquisition-of-sansa-security.php?utm_content=sf39691877&utm_medium=spredfast&utm_source=twitter&utm_campaign=ARM+Social+Media&sf39691877=1

Joe Fitzpatrick joins Xipiter

~ hucktech ~ Leave a comment

I didn’t know about this company until today. It looks like Joe Fitzpatrick of SecuringHardware is or soon will be joining them:

https://twitter.com/XipiterSec/status/616275086652235776

It appears Xipiter does security training, including Intel- and ARM-based hardware-level courses, including at upcoming DEF CON. They appear to have an upcoming Android course in the works, related to the Wiley Android Hacker’s Handbook, which has a nice chapter on ARM firmware hacking. They have other services besides training, and some hardware products as well.

http://www.xipiter.com/
http://www.xipiter.com/team.html
http://www.xipiter.com/training.html

http://securinghardware.com/

Intel ATR research on CERT VU 976132

~ hucktech ~ Leave a comment

Earlier today I posted on US-CERT’s recent vulnerability note for multiple UEFI vulnerabilties:

US CERT BIOS Vulnerability Note VU#577140!

Later today, Intel has released new research about this:

Technical Details of the S3 Resume Boot Script Vulnerability

“This paper describes technical details of a vulnerability (VU #976132 / CVE-2014-8274) in the protection of EFI based system firmware and platform configuration when resuming from the S3 sleep state.  The issue was independently discovered and presented at 31C3 in December 2014. After discovering this issue, the Advanced Threat Research team has been working to notify BIOS developers and ensure that mitigations are created. We are releasing a test module for the open source CHIPSEC platform security assessment framework. This will assist users in identifying whether their platforms might be affected by this issue.“

Read the full report here:

Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf

Note the part about a new CHIPSEC test, to test for this vulnerability, so watch the CHIPSEC Github for an update. I don’t see an update as of yet.

OEMS: please watch the security talk from Phoenix from the last UEFI Forum plugfest, especially the advise to run CHIPSEC before you ship any new systems. Please ensure your QA team uses fresh CHIPSEC builds.

Consumer Reports and other PC reviewers: Please add the CHIPSEC pass/fail data for any new systems. OEMs will improve their internal QA once they realize that the first thing the public reviewers will be calling out the OEMs on known-bad products.

More information:

US CERT BIOS Vulnerability Note VU#577140!

Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf

US CERT BIOS Vulnerability Note VU#577140!

~ hucktech ~ Leave a comment

Today, US CERT released a Vulernability Notice for UEFI firmware:

Vulnerability Note VU#577140
BIOS implementations fail to properly set UEFI write protections after waking from sleep mode

Multiple BIOS implementations fail to properly set write protections after waking from sleep, leading to the possibility of an arbitrary BIOS image reflash.
Description

According to Cornwell, Butterworth, Kovah, and Kallenberg, who reported the issue affecting certain Dell client systems (CVE-2015-2890):

    There are a number of chipset mechanisms on Intel x86-based computers that provide protection of the BIOS from arbitrary reflash with attacker-controlled data. One of these is the BIOSLE and BIOSWE pair of bits found in the BIOS_CNTL register in the chipset. When the BIOSLE bit is set, the protection mechanism is enabled. The BIOS_CNTL is reset to its default value after a system reset. By default, the BIOSLE bit of the BIOS_CNTL register is cleared (disabled). The BIOS is responsible for re-enabling it after a reset. When a system goes to sleep and then wakes up, this is considered a reset from the hardware’s point of view.

    Therefore, the BIOS_CNTL register must be reconfigured after waking from sleep. In a normal boot, the BIOS_CNTL is properly configured. However, in some instances BIOS makers do not properly re-set BIOS_CNTL bits upon wakeup. Therefore, an attacker is free to reflash the BIOS with an arbitrary image simply by forcing the system to go to sleep and wakes again. This bypasses the enforcement of signed updates or any other vendor mechanisms for protecting the BIOS from an arbitary reflash.

A similar issue affecting Apple systems (CVE-2015-3692) involves the FLOCKDN bit remaining unset after waking from sleep. For more information, refer to Pedro Vilaça’s blog disclosure.

See URL for full Notice.

http://www.kb.cert.org/vuls/id/577140

HP QuickLook: EFI PIM for MS Outlook

~ hucktech ~ Leave a comment

In business-class HP systems, they include various pre-OS tools. In addition to “HP System Diagnostics”, some older HP laptops (and perhaps desktops, but hopefully not servers) include “HP QuickLook”, a UEFI Pre-OS application which is a PIM (Personal Information Manager) for Microsoft Outlook (email, calendar, tasks, contacts).

From an HP PDF entitled “HP Business Notebook Computer EFI Guidelines”, also in below URLs:

—-snip—-
The HP EFI partition includes the following applications, which are accessible during computer startup:
* HP QuickLook or later versions (select models)
* <…omitted…>

QuickLook is a personal information manager (PIM) viewer for Microsoft(R) Outlook 2003 and 2007. QuickLook captures Microsoft Outlook email, calendar, task, and contact information, and then displays it without starting the operating system and without launching Microsoft Outlook. QuickLook can access cached Outlook information at the press of a single button, whether the computer is off or in Hibernation.
—snip—-

That’s rather scary. UEFI Pre-OS office applications. I’m not sure if it is a UEFI Application which gets run when you press the button, or if it is a UEFI RunTime Service, that is always running and only provides UI when button is pressed.

Plus, the EFI System Partition (ESP) is a FAT32-based partition, no file system-level security. Granted, a Unix-based system could mount the volume in such a way to help protect the contents, but on a Windows-based platform the user will have full read-write access to the HP .EFI executables.

It looks like there is a 2010-era HP QuickLook 3.2, perhaps later versions. I am not sure if this software is on modern HP UEFI systems, I don’t see it anymore on some docs, it may no longer be used, I’m not sure.

So, some business-class HP systems can be attacked via email network protocols, with added system complexity of being surrounded by a firmware suspend-resume! Network and content-media attacks are both options for this application. System administrators should check if this is installed on any modern systems, and consider the security risks -vs- the convenience this offers. Hiding inside corrupted HP PIM pre-OS app/service would be a great place for malware to hang out, or gain foothold via “a single button, whether the computer is off or in Hibernation”.

http://h20564.www2.hp.com/hpsc/swd/public/detail?swItemId=ob_70686_2&swEnvOid=4054

http://h20564.www2.hp.com/hpsc/swd/public/detail?swItemId=ob_79720_1&swEnvOid=4059

Survey of Boot security technologies

~ hucktech ~ Leave a comment

Wow, there’s a lot of  “Boot” buzzwords out there: U-Boot verified boot, Solaris Verified Boot,  Chrome Verified Boot,  Android Verified Boot (Class A and Class B),  UEFI Secure Boot (sometimes called Windows Secure Boot),  ARM TrustZone, UEFI Secure Boot, ARM TZ Secure Boot, Measured Boot (sometimes called TCG Measured Boot),  Trusted Boot (Windows and Linux concepts) and most likely half a dozen others I don’t even know about… 🙂

UEFI Secure Boot aside, I’m still learning some of these other boot technologies, and how they overlap. I still have a LOT of questions about many of them.  I think Verified Boot in Chrome and Android share the same Linux linux kernel technology, but have implemented things differently between Chrome and Android. UEFI’s Secure Boot doesn’t use a TPM, yet Microsoft requires OEMs to have a TPM. 😦 There’s the Trusted Boot that Windows has, and there’s also the tboot (Trusted Boot) loader that is Linux-centric. ARM’s TZ Secure Boot appears to be a different Secure Boot than the UEFI one. Solaris had their Verified Boot, but recently added UEFI support, so what is going to happen with UEFI Secure Boot, and will that mix with existing Solaris Verified Boot? Ditto on Android-IA, which only uses UEFI, will UEFI Secure Boot ever mix with Android Verified Boot?

None of these are full security solutions. For example, Intel has Boot Guard to help protect the system before UEFI Secure Boot’s protections kick in.

Below is a bit more information for each one. This is the first blog post on this topic, I’ll be doing further posts with more details about most of these in the future.

=================

U-Boot verified boot

“U-Boot 2013.07 introduces a feature allowing for the verification of a kernel and other images. U-Boot’s new verified boot feature provides a mechanism for verifying images while still allowing them to be field-upgraded. It fits in seamlessly with the existing image loading infrastructure in U-Boot. U-Boot verified boot relies on two familiar technologies: cryptographic hashing (e.g. SHA-1) and public key cryptography (e.g. RSA). Using these technologies it is possible to distribute images and have them verified on a device. Specifically we can create a key, hash an image, sign that hash, and publish the public key. On the device we can obtain an image and verify it was signed by the private key. Images can be chained one after the other and signed in reverse order either using the same keys or sub-keys (keys derived from other keys). For example, U-Boot may load an image containing a new U-Boot, then boot that. That U-Boot in turn may load an image containing a kernel. Doing that would allow U-Boot itself to be updated with the firmware without risking having an unbootable device due to a bad update. In principle this chain can be any length, but there must be an initial trusted image (“root of trust”) that can start the process. This can be stored in read-only media during manufacture or perhaps protected by on-chip crypto using its own signing scheme. The “root of trust” U-Boot must include the initial public key, held in U-Boot’s device tree (often called the flattened device tree or FDT). A more sophisticated scheme would allow the public keys to be provided by the user, perhaps by inserting an SD card containing the key. This could be implemented using a U-Boot script or with a more sophisticated user interface. A TPM can be used to hold rollback counters, to protect against rolling back to an older, compromised firmware. U-Boot also provides TPM support for trusted boot and remote attestation.”

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/verified-boot.txt;
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt;
http://git.denx.de/?p=u-boot.git;a=blob;f=test/vboot/sign-images.its
https://lwn.net/Articles/571031/

=================

Solaris Verified Boot

“Solaris Verified Boot is a solution for Oracle’s version of Solaris. Solaris Verified Boot refers to verification of object modules before execution using digital signatures. If enabled, Solaris Verified Boot checks the factory-signed signature in a kernel module before loading and executing the module. This is to detect accidental or malicious modification of a module. The action taken is configurable and, when enabled, will either print a warning message and continue loading and executing the module or will fail and not load and execute the module. Solaris Verified Boot checks kernel modules before execution and reports if the module is modified. Optionally on failures, the module is not loaded. For Solaris, Solaris Verified Boot will verify kernel modules before execution, beginning with the initial bootstrap SPARC ‘bootblk’ sectors and initial ‘unix’ module. Both of these are verified by SPARC OpenBoot (because Solaris is not running yet). The Solaris kernel loader (krtld) then takes over and verifies the main (generic) “genunix” module and all subsequent modules loaded by the Solaris kernel. The policy to use on failures is configurable with three policy settings: none, warning, and enforce. The default policy is none (that is, Verified Boot is disabled); None is the default behavior — no verification before execution. Re: TPMs, Solaris Verified Boot has no impact on the TPM chip or TPM software (TrouSerS). However, the TPM still serves complementary functions such as providing a secure keystore or taking measurements of firmware executibles. Verified Boot settings are maintained by Oracle ILOM. Anyone with ILOM spsh shell access can modify these settings.  Solaris Verified Boot is available with Solaris 11.2 for Sun SPARC T5/M5/M6 hardware platforms for host domains (with Sun Firmware FW 9.1.0 or better) and Fujitsu M10 systems (with Firmware XCP2250 firmware). Verified Boot is supported for the host domain in the Global Zone. Non-global, non-kernel zones do not have their own copy of the Solaris kernel and do not load kernel modules. Verified Boot is not supported initially for Solaris on X86, T4 or older SPARC platforms, LDoms guest domains, or Kernel Zones. We plan to support more hardware.”

https://blogs.oracle.com/DanX/entry/verified_boot
https://blogs.oracle.com/DanX/entry/solaris_kernel_zones_verified_boot
http://docs.oracle.com/cd/E36784_01/html/E37121/gmwce.html#OSSADgmwce

=================

Chrome Verified Boot

“Chrome Verified Boot is a solution for Google’s Chromium OS. The Chromium OS team is implementing a verified boot solution that strives to ensure that users feel secure when logging into a Chromium OS device. Verified boot starts with a read-only portion of firmware, which only executes the next chunk of boot code after verification. Verified boot strives to ensure that all executed code comes from the Chromium OS source tree, rather than from an attacker or corruption. Verified boot is focused on stopping the opportunistic attacker. While verified boot is not expected to detect every attack, the goal is to be a significant deterrent which will be improved upon iteratively. Verification during boot is performed on-the-fly to avoid delaying system start up.  It uses stored cryptographic hashes and may be compatible with any trusted kernel. This feature is not expected to provide 100% detection of attacks. Instead, it is meant to raise the attack bar significantly and in a way that can be improved upon iteratively.”

https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto
https://sites.google.com/site/chromeoswikisite/home/what-s-new-in-dev-and-beta/shell-acess-with-verified-boot

Click to access chromeos.pdf

http://research.google.com/pubs/pub42038.html
http://chrome.blogspot.com/2011/07/chromebook-security-browsing-more.html

=================

Android Verified Boot

“Android Verified Boot is a solution for Google’s Android OS. Android’s Verified boot guarantees the integrity of the device software starting from a hardware root of trust up to the system partition. During boot, each stage verifies the integrity and authenticity of the next stage before executing it. This capability can be used to warn users of unexpected changes to the software when they acquire a used device, for example. It will also provide an additional signal of device integrity for remote attestation, and together with encryption and Trusted Execution Environment (TEE) root of trust binding, adds another layer of protection for user data against malicious system software. We define two implementation classes for verified boot depending on how fully the device implements this specification. Class A implements verified boot with full chain of trust up to verified partitions. This implementation must support the LOCKED device state, and GREEN and RED boot states. Class B implements Class A and additionally supports the UNLOCKED device state and the ORANGE boot state.”

https://source.android.com/devices/tech/security/verifiedboot/verified-boot.html
https://source.android.com/devices/tech/security/verifiedboot/index.html
https://source.android.com/devices/tech/security/dm-verity.html
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt
http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.html
https://lwn.net/Articles/638627/

=================

UEFI Secure Boot

“UEFI Secure Boot, sometimes called Windows Secure Boot, is an optional security feature of UEFI that can be enabled by a PC OEM to enhance the security by helping to make sure that your PC boots using only software that is trusted by the PC manufacturer. When the PC starts, the firmware checks the signature of each piece of boot software, including firmware drivers (Option ROMs) and the operating system. If the signatures are good, the PC boots, and the firmware gives control to the operating system. Secure Boot does not require a TPM.”

https://technet.microsoft.com/en-us/library/Hh824987.aspx
http://go.microsoft.com/fwlink/?LinkId=278911

Click to access lf_uefi_secure_boot_open_platforms.pdf

https://fedoraproject.org/wiki/Secureboot
https://wiki.ubuntu.com/SecurityTeam/SecureBoot
https://wiki.freebsd.org/SecureBoot
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot
http://en.community.dell.com/techcenter/os-applications/w/wiki/7568.secure-boot-overview
http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO
https://en.opensuse.org/openSUSE:UEFI

=================

Measured Boot

“I think some refer to Measured Boot as TCG Measured Boot. Windows supports Measured Boot, Trusted Boot, and Secure Boot. Windows 8 introduces a new feature called Measured Boot, which measures each component, from firmware up through the boot start drivers, stores those measurements in the TPM on the machine, and then makes available a log that can be tested remotely to verify the boot state of the client. The Measured Boot feature provides AM software with a trusted (resistant to spoofing and tampering) log of all boot components that started before AM software. AM software can use the log to determine whether components that ran before it are trustworthy or if they are infected with malware. The AM software on the local machine can send the log to a remote sever for evaluation. The remote server may initiate remediation actions either by interacting with software on the client or through out-of-band mechanisms, as appropriate. Working with the TPM and non-Microsoft software, Measured Boot in Windows 8.1 allows a trusted server on the network to verify the integrity of the Windows startup process.”

https://msdn.microsoft.com/en-us/library/windows/desktop/Hh848050%28v=VS.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/Dn653311%28v=VS.85%29.aspx
https://technet.microsoft.com/en-us/windows/dn168167.aspx
http://www.jwsecure.com/2011/10/18/secure-measured-boot-in-windows-8/
https://mbt.codeplex.com/
http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/Hh848050%28v=VS.85%29.aspx
https://www.ibm.com/developerworks/community/blogs/smartersecurity/entry/uefi_secure_boot_and_the_tpm_implementing_secure_boot_with_a_tpm27?lang=en
https://technet.microsoft.com/en-us/windows/dn168169.aspx
http://mjg59.dreamwidth.org/10971.html

UEFI Secure Boot aside, it appears that ARM TrustZone also uses Secure Boot as a non-UEFI-based concept:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/CACGCHFE.html

=================

Trusted Boot

“Windows supports Measured Boot, Trusted Boot, and Secure Boot. With Trusted Boot, Windows checks the integrity of every component of the startup process before loading it. Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows 8.1 kernel before loading it. The Windows 8.1 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows 8.1 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.”

https://technet.microsoft.com/en-us/windows/dn168167.aspx
http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx

“Trusted Boot (boot) is ALSO the name of an open source, pre-kernel/VMM module for Linux, that uses Intel TXT to perform a measured and verified launch of an OS kernel/VMM. Intel TXT provides a hardware- based root of trust to ensure that a platform boots with a known good configuration of firmware, BIOS, virtual machine monitor, and operating system.”

http://hg.code.sf.net/p/tboot/code
http://www.trustedcomputinggroup.org/resources/trusted_boot
https://software.intel.com/en-us/articles/intel-trusted-execution-technology
http://www-01.ibm.com/support/knowledgecenter/SSTQK9_1.1.3/com.ibm.powersc113.se/trusted_boot_concepts.htm

=================

Enterprises which are responsible for user/data security usually like these kinds of technologies. Citizens who like to control their own devices, including installing their preferred operating system, instead of using the pre-installed OEM OS, often find these security technologies a hindrance to their normal usage. OEMs — except Google, with the Developer Mode of their ChromeBook — ignore this latter, smaller consumer demographic, and focus strictly on the security-focused market, creating opportunities for “micro-OEMs” like Purism and Bunnie Studios.

http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
https://en.wikipedia.org/wiki/Hardware_restriction

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