Tag: UEFI

UEFI for OpenBSD??

~ hucktech ~ Leave a comment

Hmm, I was under the impression that of the BSDs, only FreeBSD supported UEFI. (As well as MacOSX, of course.) But it appears that despite Theo’s previous comments on UEFI 🙂 that there might be some UEFI support in OpenBSD eventually:

From last year, GSOC’14 for OpenBSD (UEFI and GPT), I’ve not studied to see if these have been upstreamed yet:
http://www.google-melange.com/gsoc/project/details/google/gsoc2014/mmu/5639274879778816

From 2 days ago, a new OpenBSD-centric boot loader:
https://github.com/yasuoka/openbsd-uefi
It looks like the latter project needs some hardware help, besides the author’s VIAO, if you can help them out…

New HardenedBSD release

~ hucktech ~ Leave a comment

A new release of HardenedBSD is available: v28 version of 10-STABLE as well as 11-CURRENT.

HardenedBSD is a security-enhanced fork of FreeBSD, created in 2014 by Oliver Pinter and Shawn Webb. HardenedBSD aims to implement innovative exploit mitigation and security solutions for FreeBSD. The project works with upstream FreeBSD and any other FreeBSD-based project to include any security improvements. NanoBSD is the embedded subset of FreeBSD. FreeBSD — at least the last time I checked — was the only BSD distro that supports UEFI. Recently, HardenedBSD 11-CURRENT was released:
https://hardenedbsd.org/article/oliver-pinter/2015-07-24/hardenedbsd-11-current-amd64-x86-64-installers
https://github.com/HardenedBSD/hardenedBSD

The AArch64 port of FreeBSD has been progressing well. I’ve not built HardenedBSD for AArch64 myself yet, but it appears that someone can, there’s a VM version at least:
https://twitter.com/lattera/status/628701851286962177

Intel Firmware Engine SDK 1.0 for Windows released

~ hucktech ~ Leave a comment

Yesterday Intel released the 1.0 SDK for their Firmware Engine.

“The Intel(R) Firmware Engine simplifies and accelerates the creation of platform firmware images, allowing developers to quickly deploy platforms based on Intel reference designs. Customers can configure firmware features using a catalog of compatible firmware components, without the need to modify source code. It enables simple changes of the binary image of the firmware from reference platform to derivative product, allowing developers to configure firmware features based on their product customizations. This development process accelerates adding and removing firmware features not found in reference platform, adding third-party components not provided with reference platform, and integrating custom boot payloads. Developers can also extend functionality using the Intel(R) Firmware Engine Software Development Kit (SDK). Existing Intel(R) UDK2014 code can be extended to work with Intel Firmware Engine, allowing silicon component vendors and firmware developers to rapidly extend the Intel Firmware Engine ecosystem.”

http://firmware.intel.com/learn/intel-firmware-engine/downloads
http://firmware.intel.com/sites/default/files/Intel%C2%AE%20Firmware%20Engine%20SDK%20Release%201.0.zip

The Firmware Engine and it’s SDK only work with Microsoft(R) Windows. If you don’t use Windows, you’ll find this SDK useless. I prefer the approach taken with the UEFI Driver Wizard, which was created with a cross-platform GUI (wxWidgets), and source code was released. Focusing on Windows-only developers alienates Mac and Linux (and FreeBSD) OS vendors and developers, all of which have UEFI firmware and may benefit from this engine and it’s SDK.  I wish Intel would target cross-platform developer tools. I wish the sources were available, so the non-Windows community could help Intel to port their code to other OSes.

No Starch Press: Rootkits and Bootkits

~ hucktech ~ 1 Comment

[Wow!]

Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats
by Alex Matrosov, Eugene Rodionov, and Sergey Bratus

Spring 2016, 304 pp.
ISBN: 978-1-59327-716-1
$39.95 EARLY ACCESS Ebook
$49.95 Print Book and EARLY ACCESS Ebook

Get 30% off with the coupon code EARLYBIRD

Modern malware is always evolving because malware authors are constantly finding new ways to bypass security and avoid detection. Defending against (and even discovering) the latest malicious software requires cunning and extensive expertise because attackers have become much more sophisticated.

One particularly fascinating and threatening area of malware development is that of rootkits and bootkits. We’re talking hard stuff – attacks buried deep in a machine’s boot process or firmware. These are the kind of attacks that keep malware analysts up late at night. But help is on the way.

In Rootkits and Bootkits, authors Alex Matrosov, Eugene Rodionov, and Sergey Bratus share the knowledge and expertise they’ve gained during years of professional research. You’ll learn how to expose hidden files systems that can make rootkits so hard to identify and remove. You’ll explore how malware has evolved from rootkits like TDL3 to the present; how this stealthy software can take hold of a system; and how to counter anti-debugging, anti-disassembly, and anti-virtual machine measures. You’ll also learn how bootkits work, and how Windows boots so that you can better prevent infections in the first place.

Cybercrime syndicates and malicious actors keep pushing the envelope, writing ever more persistent and covert attacks. But the game is not lost. In this low-level tour through the wilds of malware, you’ll learn how to reverse next generation threats. Explore the cutting edge of malware analysis with Rootkits and Bootkits.
About the Author

Alex Matrosov has more than 10 years experience with malware analysis, reverse engineering and advanced exploitation techniques. He is a senior security researcher in the Advanced Threat Research team at Intel Security Group and prior to this role, he spent four years focused on advanced malware research at ESET. Matrosov is co-author of numerous research papers including Stuxnet Under the Microscope, and is frequently invited to speak at major security conferences such as REcon, ZeroNights, Black Hat and Virus Bulletin.

Eugene Rodionov, PhD, graduated with honors from the Information Security faculty of the Moscow Engineer-Physics Institute. He currently works at ESET, where he is involved with internal research projects and performs in-depth analysis of complex threats. His interests include kernel-mode programming, anti-rootkit technologies and reverse engineering. Rodionov has spoken at security conferences such as REcon, Virus Bulletin, ZeroNights, CARO and AVAR, and has co-authored numerous research papers.

Sergey Bratus is a Research Associate Professor in the Computer Science Department at Dartmouth College. He has previously worked at BBN Technologies on Natural Language Processing research. Bratus is interested in all aspects of Unix security, in particular in Linux kernel security, and detection and reverse engineering of Linux malware.

Table of Contents
Introduction
Part 1: ROOTKITS
Chapter 1: What’s in a Rootkit: The TDL3 Case Study (NOW AVAILABLE)
Chapter 2: Festi Rootkit: The Most Advanced Spam Bot
Chapter 3: Observing Rootkit Infections
Chapter 4: Rootkit Static Analysis: IDA Pro
Chapter 5: Rootkit Dynamic Analysis: WinDbg
Part 2: BOOTKITS
Chapter 6: Bootkit Background and History (NOW AVAILABLE)
Chapter 7: The Windows Boot Process: Bringing Up a System in a Trustworthy State (NOW AVAILABLE)
Chapter 8: From Rootkits (TDL3) to Bootkits (TDL4): Bypassing Microsoft Kernel-Mode Code Signing Policy (NOW AVAILABLE)
Chapter 9: Operating System Boot Process Essentials (NOW AVAILABLE)
Chapter 10: Static Analysis of a Bootkit Using IDA Pro (NOW AVAILABLE)
Chapter 11: Bootkit Dynamic Analysis: Emulators and Virtual Machines
Chapter 12: Evolving from MBR to VBR Bootkits: Mebromi & Olmasco
Chapter 13: VBR Bootkits: Rovnix & Carberp
Chapter 14: Gapz: Advanced VBR Infection
Chapter 15: UEFI Boot vs. MBR/VBR
Chapter 16: Contemporary UEFI Bootkits
Part 3: DEFENSE AND FORENSIC TECHNIQUES
Chapter 17: How Secure Boot Works
Chapter 18: HiddenFsReader: Bootkits Forensic Approaches
Chapter 19: CHIPsec: BIOS/UEFI Forensics
Part 4: ADVANCED REVERSE ENGINEERING
Chapter 20: Breaking Malware Cryptography
Chapter 21: Modern C++ Malware Reversing
Chapter 22: HexRaysCodeXplorer: Practical C++ Code Reconstruction

https://www.nostarch.com/rootkits

Debian calls for UEFI packaging help

~ hucktech ~ Leave a comment

Steve McIntyre of Debian posted a blog the other day, they’re doing more to help with UEFI in Debian. If you can help, this is the most upstream distribution…

http://blog.einval.com/2015/08/02#tracking_broken_UEFI_implementations

http://linux.softpedia.com/blog/debian-needs-your-help-to-improve-uefi-support-in-the-distribution-488512.shtml

I’m not good at packaging, but am currently learning. If you want to help with Debian packaging for CHIPSEC, please let me know, or join the thread on the CHIPSEC mailing list.

https://lists.01.org/pipermail/chipsec/2015-July/000001.html

EBC

~ hucktech ~ Leave a comment

EBC, The EFI Byte Code, is a UEFI feature that supports Intel (Itanium, x86, and x64) instructions in a single bytecode. The Intel C Compiler can target EBC, and UEFI drivers can use EBC instead of native drivers, to save space (1 binary, instead of 3).

The other week I gave a firmware security tools talk at BlackLodgeResearch.org, and Vincent Zimmer of Intel showed up. I had a slide complaining that EBC is only supported by Intel C Compiler, a commercial-only product, and that the UEFI Forum should fund a ‘summer-of-code’-style effort to get EBC into GCC or LLVM CLang. After the talk, Vincent mentioned that ICC had to do a bit of unexpected work to generate EBC, and would blog about it. Well, he did blog about it, a few days ago, just catching up to it, and describe the problem.
http://vzimmer.blogspot.com/2015/08/efi-byte-code.html

If you know of someone on the LLVM CLang or GCC project, please try to add a request for EBC support.

Not only would it be nice to have LLVM CLang work with EBC to have an alternative to ICC, and for LLBVM’s Klee fuzzer (to fuzz UEFI via OVMF), but ALSO because the Capstone Framework RE tool uses LLVM’s intermediate form and would then get EBC support!!
http://www.capstone-engine.org/

Today, radare2, another RE tool, already has EBC support.

tool mini-review: radare2

If technically possible, it might be nice if ARM added AArch32 and AArch64 support, and EBC support in their compiler, so that EBC could actually target all UEFI platforms with a single blob. ARM/Linaro already has something that appears to overlap in some ways:
http://people.linaro.org/~christoffer.dall/arm-vm-spec-v1.0.txt

Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!
https://github.com/nnliaohua/CIL2EBC-ToolChain

quiz: define ‘firmworm’

~ hucktech ~ Leave a comment

The pre-conference preview videos are coming out… 🙂 One firmware one that caught my attention:

Thunderstrike 2 “firmworm” for MacBooks Preview Video

https://twitter.com/qrs/status/628346592668598272

Microsoft Windows HSTI (Hardware Security Test Interface)

~ hucktech ~ Leave a comment

I just noticed that Microsoft has a “Hardware Security Testability Specification”, still at version 1.0, which defines the Microsoft Windows “Hardware Security Test Interface” (HSTI). The Windows Hardware Certification Program is a self-testing and certification process for Windows OEMs and IHVs. The OEMs/IHVs run some tests, pass them, upload the test log output showing the passing, the vendor gets their code signed and/or they won’t get their marketing logo. Though the test name and the group  name have changed, these tests have been around since the beginning of Windows NT. The tests have grown over time to cover more system components, and certification and logo requirements have gotten more tied to passing test results. As these tests are only useful for Windows-centric IHVs and OEMs, I’ve not paid much attention to what firmware tests are available. These days, there are tests for chip vendors and for IBVs (Independent BIOS Vendors), in addition to OEMs and IHVs. It looks like they have a few UEFI-centric tests regarding Secure Boot, and dealing with system suspend/resume.

Jeremiah Cox of Microsoft gave a talk at the Summer 2013 UEFI Forum plugfest (Summerfest): “Validating Hardware Security Through Firmware Interfaces“, see below for URL to slides.

Excerpts from the MSDN web page:

“HSTI helps avoid misconfiguration of security features on devices running Windows. Thus, HSTI provides better assurance of compliance with Windows Hardware Security Requirements. HSTI aims to simplify the interface for designing tests to ensure compliance, reducing the effort required to comply with Windows Hardware Security Requirements. The results of HSTI tests will be consumed by Windows Certification Tests and can be used to verify that devices have been properly configured to enable supported security features. These tests may be used to identify unsecure engineering devices in the field; for example, engineering devices which may contain unsecure test keys. The results of these tests may be used by the Windows operating system to display a watermark (or similar indicator) on unsecured devices. The IHV will develop reference security designs for their platforms that comply with the Windows Compatibility Requirements. In addition, IHVs and IBVs will also implement programmatic tests that verify proper enablement of the reference security implementations and report the results via the Hardware Security Test Interface. These tests are delivered to OEMs & ODMs as compiled modules (not source) and should work without modification. If an OEM/ODM deviates from reference security designs, these test modules may report failures, and the OEM/ODM will need to contact Microsoft to review the modifications and implement an additional HSTI instance that reports these exceptions. OEMs should be able to leverage these security modules with no modification required by following the reference design and documentation. OEMs who wish to add additional security modules, or modify the behavior of any security module, must undergo a design review with Microsoft. Silicon suppliers and IBVs who support Connected Standby systems must implement the platform independent interfaces for querying the respective hardware and firmware security states of their reference platforms. These implementations must be delivered as compiled modules. It is recommended that these modules be signed, and that a signature check is performed when they are run. The purpose is to query the hardware and firmware designs and states to report proper security provisioning of the platform. If an OEM wants to provide an alternate implementation of HSTI tested security features the OEM may provide additional tests. OEM security checks must at least fully cover one IHV or IBV security test. Before use, OEMs must submit to a design review by Microsoft and are subject to the same Documentation and Tool disclosure requirements as other HSTI test providers. Upon approval from Microsoft, the OEM may include security tests that extend upon the IHV and IBV tests. Note that OEM attestation is not required as part of the HSTI design. HSTI is not a list of requirements for OEMs; it is an interface to guarantee effective programmatic security testing of firmware, hardware, and configuration parameters. Silicon and firmware suppliers should make available to Microsoft all necessary security-related reference documentation and tools that they provide to OEMs. This documentation and tools should be made available no later than they are provided to Windows OEMs. This should include, but is not limited to, all documentation and tools related to fusing, installing and updating firmware, firmware and boot recovery, hardware diagnostics, firmware diagnostics, & boot diagnostics. This documentation and tools provided should be fully sufficient to perform HSTI checks in a lab environment.”

Beyond Canonical’s FirmWare Test Suite (FWTS) tool for Ubuntu systems, I wonder if Linux Foundation (and FreeBSD Foundation) have anything close to this testing and certification policy for (not just a test), to help encourage silicon vendors, IBVs, IHVs, and OEMs to best (and most securely) work with Linux (and FreeBSD). In addition to passing FWTS, Intel-based systems should also have to pass current CHIPSEC release before Linux or FreeBSD should touch the platform.

This also reminds me of my last blog post, about getting CHIPSEC results more widely available for consumer’s pre-sales knowledge, depending on the strength of these Windows tests, Microsoft may have some OEM/IBV test results that I wish they’d share (but they never would share that kind of data about their Partner, of course).

For the good of all OSes, not just Windows, I wish Microsoft would add CHIPSEC to their test suites, to force OEMs to pass CHIPSEC. I wonder if CHIPSEC works using IronPython when run as an OS-level app on Windows. 🙂

More Information:

Click to access UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf

http://www.uefi.org/learning_center/presentationsandvideos
https://msdn.microsoft.com/en-us/library/windows/hardware/dn879006.aspx

AMD AGESA

~ hucktech ~ Leave a comment

I’m learning about AMD firmware solutions, and AGESA is first acronym on the list. According to Wikipedia:

“AMD Generic Encapsulated Software Architecture (AGESA), is a bootstrap protocol by which system devices on AMD64-architecture mainboards are initialized. The AGESA software in the BIOS of such mainboards is responsible for the initialization of the processor cores, memory, and the HyperTransport controller. AGESA documentation was previously available only to AMD partners that had signed an NDA. AGESA source code was open sourced in early 2011 to gain track in coreboot.”

There are two firmware ecosystems, coreboot and UEFI, where the former has a lot of Chrome OEMs, and the latter has a lot of Windows OEMs. UEFI and coreboot work on Intel and AMD (and ARM) systems. AMD makes both x86 and ARM systems, but I’m focusing on their x86 systems here.

For coreboot, Sage Engineering is main coreboot IBVs (Independent BIOS Vendors), AFAICT. Sage currently supports AMD systems, offering coreboot with AGESA.

https://www.se-eng.com/products/sagebios-bsp-for-amd-processors/

“Sage supports many modern x86 platforms from AMD. In early BSP releases,our source code license allowed us to directly modify and include AGESA source code. Later versions include the AGESA binary PI from AMD to initialize the CPU. SageBIOS(TM) Custom BSPs deliver full-featured firmware designed for AMD platforms.”

https://www.se-eng.com/firmware-solutions-for-intel-and-amd-x86-processor-systems/

“AMD was the first […] to support an open source boot solution with its support of the One Laptop Per Child program, which was immersed in the Linux open source community, and the Linux firmware boot solutions that would ultimately become coreboot. Sage Electronic Engineering founder Scott Hoot was heavily involved in that the children’s laptop project, as a firmware designer for AMD, and would soon embrace open source firmware solution as a foundation for his startup company. Sage would have distinct advantages over other open source firmware development companies in that Hoot already had a insight into AMD’s proprietary architecture, which he would cement with a agreements with AMD to help forge the way into expanded open source BIOS and firmware coding. Sage would continue to forge a trail in the community with its support of the coreboot(R) solution and the proprietary hybrid that Sage developed for more rapid deployment, SageBIOS. Open source development as a whole continue to progress with AMD’s AGESA  and Intel’s Firmware Support Package, essentially giving open source firmware designers a better look at the architecture than was previously allowed.”

Over in the UEFI Forum ecosystem, it appears that most of the ‘mainstream’ IBVs also support ARM via AGESA in their products as well. I see support from Insyde Software and AMI, at least.

http://www.insyde.com/press_news/press-releases/insyde-software-provides-framework-support-amd-processors

http://www.ami.com/news/press-releases/?PressReleaseID=135&/American%20Megatrends%20Extends%20Aptio%C2%AE%20Firmware%20Support%20for%20AMD%20AGESA%E2%84%A2/

I’m still not clear if TianoCore can use AGESA directly, or if an IBV is still needed to integrate the two.

More Information:

http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/vendorcode/amd
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/a46a712610c130cdadfe1ebf6bec9ad22e474dac/src/cpu/amd/agesa

Click to access AGESA_Interface_specification_for_Arch2008.pdf

[I just realized that I’ve not written a blog on Intel Firmware Support Package (FSP) yet…. I’ll do one in a few days.]

book mini-review: combat: UEFI Principles and Programming (in Chinese)

~ hucktech ~ 1 Comment

Ok, I’m writing a book review about a book I didn’t read. 😦 The book is written in Chinese, and I’m not good enough at translation software yet to read the book. But for anyone who can read Chinese, if you don’t already know about this book, you should check it out.

According to Amazon.com. the author is Director of Intel Labs China, and the book has a developer focus. The github site includes a snapshot of the EDK2, with a few examples. Even if you can’t read Chinese, you can still benefit from reading the samples. The  book was published January 1st 2015, and Gthub appears to have last been updated in May. From the Amazon.com abstract:

“combat: UEFI Principles and Programming is the first UEFI monograph in Chinese, which is written by senior UEFI expert and evangelist. Director of Intel Labs China, Wu Gansha, strongly recommended! This book is combat-oriented for UEFI users and developers. It describes the UEFI system components, boot process, advantages, and a variety of systems development environment to build; Then it analyzes the UEFI components from deverloper’s view, including UEFI modules, a variety of protocols. basic services, events, hard drives and file systems; Finally it explaines UEFI development , involving the development of UEFI services(video decoder service though ffmpeg), UEFI-driver development(AC97 audio driver), the development of multi-tasking applications, the development of network applications and GUI application development.”

https://github.com/zhenghuadai/uefi-programming
https://github.com/zhenghuadai/uefi-programming/blob/master/README.md

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

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/

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

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

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