Tag: UEFI

Alex at Black Hat: Where the Guardians of the BIOS Are Failing

~ hucktech ~ Leave a comment

Black Hat Vegas: Where the Guardians of the BIOS Are Failing
By Alex Matrosov
In our upcoming Black Hat Vegas talk, we will summarize our research about the UEFI firmware protections and our newly-discovered security problems. This talk raises awareness of these security challenges for hardware vendors, BIOS-level security researchers and defenders, and sophisticated stakeholders who want to know the current state of UEFI exposure and threats. The situation is serious but, with the right tools and knowledge, we can prevail.[…]

https://www.blackhat.com/us-17/briefings.html#betraying-the-bios-where-the-guardians-of-the-bios-are-failing

https://www.cylance.com/en_us/blog/black-hat-vegas-where-the-guardians-of-the-bios-are-failing.html

Setting up Mac for EFI development

~ hucktech ~ Leave a comment

Setup EFI Development environment on Mac OSX Sierra (10.12.X)

Mikal Villa Mikal Villa • 07/10/2017

Oh no! a lot of text. Well, luckly half of the post is troubleshooting. EFI development setup is easy 🙂

Okay, before starting this guide you should have some tools installed already.[…]

https://0xcc.re/setup-efi-development-environment-on-mac-osx-sierra-10-12-x/

UEFI-based IoT firmware updates

~ hucktech ~ Leave a comment

https://twitter.com/grjohnson10/status/880767835886301184

Simplify Secure, UEFI-Based IoT Firmware Updates
Rich Nass

In the age of the Internet of Things (IoT), where everything is becoming connected, each connection point can be viewed as a “Hack This” sign for the bad guys. To prevent this, developers need to be sure that all firmware and associated patches are kept up to date with verified and secure revision control. Any unpatched or outdated firmware can allow access to critical system functions. Unfortunately, this need to keep firmware updated often goes overlooked by the development team after a product has shipped. In many cases this is due to the resources required and complexities involved. But what if the whole process of updating and securing firmware remotely or over the air (OTA) could be standardized and encapsulated within an easy-to-use, reliable solution that works seamlessly with your underlying hardware? It turns out that such a solution is already in hand.[…]

http://www.insight.tech/industrial/simplify-secure-uefi-based-iot-firmware-updates

http://www.insight.tech/authors/rich-nass

Nikolaj on recent UEFI/ACPI spec updates

~ hucktech ~ Leave a comment

[[[UPDATE:
William’s blog post on Nikolaj’s comments are more readable than below post:
http://www.basicinputoutput.com/2017/07/uefi-27-courtesy-of-nikolaj.html
]]

Nikolaj has over a dozen tweets showcasing the interesting new features in the latest UEFI and ACPI specs. Click on the above Twitter URL to see the full set.

 

UDK2017 available

~ hucktech ~ Leave a comment

Brian Richardson of Intel has a new article talking about the latest UEFI dev kit. It includes a summary of the newly-added UEFI features.

https://software.intel.com/en-us/blogs/2017/06/29/udk2017-the-latest-uefi-development-kit-release-is-now-available

https://github.com/tianocore/edk2/releases/tag/vUDK2017

https://github.com/tianocore/tianocore.github.io/wiki/UDK2017#udk2017-features–updates–changes

Xen 4.9 multiboot2 support increased

~ hucktech ~ Leave a comment

At least one UEFI change in this release:

Boot Xen on EFI platforms using GRUB2 (x86):
From Xen Project 4.9 and GRUB2 2.02 onwards, the Xen Project Hypervisor can be booted using the multiboot2 protocol on legacy BIOS and EFI x86 platforms. Partial support for the multiboot2 protocol was also introduced into network boot firmware (iPXE). This makes the Xen Project boot process much more flexible. Boot configurations can be changed directly from within a bootloader (without having to use text editors) and boot configurations are more portable across different platforms.

https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/

 

EFI Boot Guard from Siemens

~ hucktech ~ Leave a comment

EFI Boot Guard

Simple UEFI boot loader with support for safely switching between current and updated partition sets. A bootloader based on UEFI. Provides the following functionality:

* Arm a hardware watchdog prior to loading an OS
* Provides a simple update mechanism with fail-save algorithm

The following watchdog drivers are implemented: Intel Quark, Intel TCO, and Intel i6300esb.

 

https://github.com/siemens/efibootguard

Summer reading list for UEFI security

~ hucktech ~ Leave a comment

I’ve seen a large number of ‘Summer reading list’ posts on various social media forums in the last few days. I’ll add my own.

http://www.timeglider.com/timeline/5ca2daa6078caaf4

https://github.com/advanced-threat-research/firmware-security-training

https://www.nostarch.com/rootkits

https://www.degruyter.com/view/product/484477

https://www.degruyter.com/view/product/484468

https://blog.invisiblethings.org/2015/10/27/x86_harmful.html

https://blog.invisiblethings.org/2015/12/23/state_harmful.html

Regarding the No Starch Press book above, most chapters available via ebook, hardcopy book apparently due later this Summer, autographed edition at DEF CON.

Dell PowerEdge 14G firmware updates

~ hucktech ~ Leave a comment

Dell/EMC has a new Tech Note, written by Wei Liu and Seamus Jones, summarizing some of the new firmware security features available in their new server:

Cyber-Resiliency Starts at the Chipset and BIOS

2-page Tech Note covering new BIOS features introduced with PowerEdge 14G servers, offering unique resiliency to malicious intent or user error. The two features highlighted, BIOS Recovery and integration of Intel Boot Guard, respectively, are further demonstration of PowerEdge engineering commitment to ensuring the security and stability of enterprise infrastructures.

http://en.community.dell.com/techcenter/extras/m/white_papers/20444061

 

sicherboot: systemd Secure boot integration

~ hucktech ~ Leave a comment

systemd Secure boot integration

sicher*boot automatically installs systemd-boot and kernels for it into the ESP, signed with keys generated by it. The signing keys are stored unencrypted and only protected by the file system permissions. Thus, you should make sure that the file system they are stored (usually /etc) in is encrypted. After installing sicherboot, you can adjust a number of settings in /etc/sicherboot.conf and should set a kernel commandline in /etc/kernel/cmdline. Then run ‘sicherboot setup’ to get started.

 

https://github.com/julian-klode/sicherboot

EFI variable support for U-Boot

~ hucktech ~ Leave a comment

Rob Clark has an RFC patch to U-Boot, with UEFI variable support:

[RFC] efi: variable support

Mapping from EFI variables to grub variables. Still almost as many TODOs as lines of code, but just figured I’d send out an early version for comments. I was thinking of it as a useful way for u-boot to pass values to grub (although grub is still missing a way for grub scripts to retrieve UEFI variables). The rough idea is to encode GUID + variable name plus “efi_” prefix (to avoid unintended u-boot variables leaking into the UEFI world). And then encode the type (and attributes?) in the string value of the variable. Ie. something like:

setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported (u64)0

Full patch/thread:
https://lists.denx.de/listinfo/u-boot

 

Adaptiva Secure 10: BIOS to UEFI

~ hucktech ~ Leave a comment

New registration-required freeware from Adaptiva:

Adaptiva’s free Secure 10 is a complete automation solution for ConfigMgr admins to make the BIOS to UEFI conversion process simple and unattended. With Secure 10, migrations take much less time and no IT staff need to be on-site during the process. Now including support for new MBR2GPT.exe tool for retaining data while making the switch, as well as ConfigMgr 1610+ WinPE boot image pre-staging. Also new: two complete task sequences to save time integrating into your deployments! […] The open solution includes detailed documentation to help SCCM system administrators overcome the complexities of automating the conversion from:

* BIOS to UEFI – Secure 10 automates the conversion process from the legacy BIOS firmware typically used in Windows 7/8 systems to the more powerful Unified Extensible Firmware Interface (UEFI) technology. UEFI is required to enable key enterprise security features available in Windows 10.

* MBR to GPT – Secure 10 now includes support for the MBR2GPT.exe tool, which helps convert the disk layout on a PC from the legacy Master Boot Record (MBR) to GUID Partition Table (GPT). The new tool is the only Microsoft-supported tool to convert a production disk from MBR to GPT without data loss, greatly speeding in-place upgrades to Windows 10.

* WinPE Pre-staging – Microsoft recently introduced the capability to pre-stage a WinPE boot image to a partition from within an SCCM Task Sequence and have that image persist during the conversion from MBR to GPT. Secure 10 supports this capability for refresh/replace scenarios.

https://www.adaptiva.com/blog/2017/adaptiva-releases-bios-uefi-solution-update-speed-windows-10-migrations/

Dmytro on PCI-E/SMM vulnerability

~ hucktech ~ Leave a comment

Dmytro has an interesting 6-part twitter post on PCI-e security:

Debian 9 “Stretch” released

~ hucktech ~ Leave a comment

Excerpts of announcement included below. For full announcement, see the debian-announce mailing list archives.

 After 26 months of development the Debian project is proud to present its new stable version 9 (code name “Stretch”), which will be supported for the next 5 years thanks to the combined work of the Debian Security team and of the Debian Long Term Support team. Debian 9 is dedicated to the project’s founder Ian Murdock, who passed away on 28 December 2015.

The UEFI (“Unified Extensible Firmware Interface”) support first introduced in “Wheezy” continues to be greatly improved in “Stretch”, and also supports installing on 32-bit UEFI firmware with a 64-bit kernel. The Debian live images now include support for UEFI booting as a new feature, too.

A total of ten architectures are supported: 64-bit PC / Intel EM64T / x86-64 (amd64), 32-bit PC / Intel IA-32 (i386), 64-bit little-endian Motorola/IBM PowerPC (ppc64el), 64-bit IBM S/390 (s390x), for ARM, armel and armhf for older and more recent 32-bit hardware, plus arm64 for the 64-bit “AArch64” architecture, and for MIPS, in addition to the two 32-bit mips (big-endian) and mipsel (little-endian), there is a new mips64el architecture for 64-bit little-endian hardware. Support for 32- bit Motorola/IBM PowerPC (powerpc) has been removed in “Stretch”.

https://www.debian.org/News/2017/20170617
http://ftp.debian.org/debian/doc/dedication/dedication-9.0.txt
https://www.debian.org/releases/stretch/installmanual
https://www.debian.org/releases/stretch/releasenotes

 

Black Hat Briefings: Firmware is the New Black

~ hucktech ~ Leave a comment

 

Firmware is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities
Bruce Monroe, Rodrigo Branco, Vincent Zimmer

In recent years, we witnessed the rise of firmware-related vulnerabilities, likely a direct result of increasing adoption of exploit mitigations in major/widespread operating systems – including for mobile phones. Pairing that with the recent (and not so recent) leaks of government offensive capabilities abusing supply chains and using physical possession to persist on compromised systems, it is clear that firmware is the new black in security. This research looks into BIOS/UEFI platform firmware, trying to help making sense of the threat. We present a threat model, discuss new mitigations that could have prevented the issues and offer a categorization of bug classes that hopefully will help focusing investments in protecting systems (and finding new vulnerabilities). Our data set comprises of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past 3 years and the analysis was manually performed, using white-box and counting with feedback from various BIOS developers within the company (and security researchers externally that reported some of the issues – most of the issues were found by internal teams, but PSIRT is involved since they were found to also affect released products).

https://www.blackhat.com/us-17/briefings/schedule/index.html#firmware-is-the-new-black—analyzing-past-three-years-of-biosuefi-security-vulnerabilities-6924