Category: Uncategorized

CrowdStrike announces Venom vulnerability

~ hucktech ~ Leave a comment

As reported by Robert Hackett at Fortune, Crowdstrike has research on a new vulnerability that impacts virtualization. Venom stands for “virtualized environment neglected operations manipulation”. It impacts QEMU, Xen, KVM, and VirtualBox, among others.

(It must be a big deal, as it already has an icon. I think Heartbleed took longer for it’s icon.)

More information:
http://venom.crowdstrike.com/
http://fortune.com/2015/05/13/venom-vulnerability/

Windows Defender attacks some non-Windows UEFI images

~ hucktech ~ Leave a comment

Starting in late 2013, Microsoft Windows Defender, a background malware scanner that gets updates via Windows Update, started looking for UEFI boot managers/loaders/tools that are not signed by Microsoft, and started deleting them. This impacts booting non-Windows OSes, Linux, FreeBSD, Android, etc. Windows Defender gives users no control to override/configure anything. Microsoft can update the scanner to delete new files in the future, when Windows Update refreshes it. Presumably any UEFI image that isn’t signed by Microsoft is likely a candidate.  I am unclear what “UEFI module” is they describe in the documentation (see below), I presume this means any UEFI Application/Service/Driver. The list of OEM contacts the Microsoft documentation points to for these “UEFI modules” is a very old list, doesn’t cover most UEFI Forum Members. Then again, some of the main targets of Defenders deletions are likely not OEMs nor UEFI Forum Members, but open source UEFI tools.

This feature is useful if you have a Windows system and you only run Windows, and never want to run anything other than Windows. This feature is not useful if you ever wish to dual-boot a non-Windows OS alongside Windows, since Windows Defender will destroy the other OS’s boot loader.

The workaround is to never dual-boot anything alongside Windows. OEMs who want to build non-Windows machines have to risk Windows Defender making their systems unbootable, if any customer tries to dual-boot Windows on it. I wonder, if an OEM is ever capable enough to ship a Linux system with UEFI Secure Boot setup to boot Linux, without Microsoft keys, would Windows Defender properly check the UEFI keys and delete the Windows boot manager, which is unsigned by that firmware? 🙂

More information:

Microsoft security advisory: Update to revoke noncompliant UEFI boot loader modules
https://support.microsoft.com/en-us/kb/2871690
https://technet.microsoft.com/library/security/2871690

Excerpts:

“Microsoft is announcing the availability of an update for Windows 8 and Windows Server 2012 that revokes the digital signatures for nine private, third-party UEFI modules that could be loaded during UEFI Secure Boot. When the update is applied, the affected UEFI modules will no longer be trusted and will no longer load on systems where UEFI Secure Boot is enabled. The affected UEFI modules consist of specific Microsoft-signed modules that are either not in compliance with our certification program or their authors have requested that the packages be revoked. At the time of this release, these UEFI modules are not known to be available publicly. Microsoft is not aware of any misuse of the affected UEFI modules. Microsoft is proactively revoking these non-compliant modules as part of ongoing efforts to protect customers. This action only affects systems running Windows 8 and Windows Server 2012 that are capable of UEFI Secure Boot where the system is configured to boot via UEFI and Secure Boot is enabled. There is no action on systems that do not support UEFI Secure Boot or where it is disabled.”

“On affected releases of Microsoft Windows that are running on UEFI firmware with UEFI Secure Boot enabled, the update revokes the digital signatures for specific UEFI modules that could be loaded during UEFI Secure Boot. When the update is applied, the affected UEFI modules will no longer be trusted and will no longer load on systems where UEFI Secure Boot is enabled. The affected UEFI modules consist of specific Microsoft-signed modules that are either not in compliance with our certification program or their authors have requested that the packages be revoked.”

“For more information about your UEFI module, contact the UEFI module supplier. This might include the system vendor, the plug-in card vendor, or other UEFI software vendors such as UEFI backup and restore solutions, UEFI anti-malware, and so on.”

“Customers should update their UEFI modules to compliant versions prior to installation of this update. Customers who apply this update on a system with a non-compliant UEFI module risk putting the system into a non-bootable state. Microsoft recommends that all customers apply this update after ensuring they are running up-to-date UEFI modules.”

“Customers who want to continue using non-compliant UEFI modules for their own purposes, such as for testing, can do so by disabling Secure Boot in their system’s BIOS configuration menu.

Firmware security checks and IoT network security

~ hucktech ~ Leave a comment

In Mobile Enterprise, Laurie Lamberth and Steve Brumer have a story on IoT network security. Previous articles on topic have mentioned issues with out-of-date device firmware.

Excerpt:

3. Periodic endpoint integrity checks: With thousands of devices of all different types being connected to the enterprise networks, over different networks with different access control protocols, after the fact as well as real-time access monitoring is a good idea. Periodically checking each device’s security software and policies, firmware, software, and other resources such as anti-virus protection, can root out vulnerabilities before they become problems.

Read the full story:
http://mobileenterprise.edgl.com/news/3-Options-for-Securing-the-IoT-Network-99910

Do you know how to check the firmware on your system?

Linaro makes LUVos-live available for ARM64

~ hucktech ~ 1 Comment

LUVos (Linux UEFI Validation — aka luvOS or LUVos, is a Yocto-based Linux distro that helps diagnose UEFI firmware. LUV-live is a liveimage boot version of LUVos. LUV-live also includes other hardware/firmware tools, such as BITS, FWTS, and CHIPSEC.

Intel-based LUV was initially only targeting Intel platforms. But LUV is an open source project, with a healthy community of contributors.

Recently Linaro has been porting LUV to ARM64. Thanks, Linaro! This is great news for ARM64 Linux enterprise hardware. Once Linaro ports CHIPSEC to ARM, it’ll be a very good day for ARM64 firmware defensive security tools.

It would be nice to consider an ARM32 port, as well as ARM64. All devices need bootkit detection tools, not just enterprise-class systems. 🙂

[Someone please wake up AMD. Right now, AFAICT, their platform now has the worst defensive tools. They need a LUV-live with a CHIPSEC that works on ARM systems.]

https://wiki.linaro.org/LEG/Engineering/luvOS

https://01.org/linux-uefi-validation

Book Review: Embedded Firmware Solutions

~ hucktech ~ Leave a comment

Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer
http://www.apress.com/9781484200711

[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]

If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.

Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.

I’m looking forward to a second edition in a year or so, once tech changes enough.

New NVME Express pass-through protocol in UEFI 2.5

~ hucktech ~ Leave a comment

Feng Tian of Intel recently checked in changes to the EDK-II trunk for the EFI_NVME_PASS_THRU_PROTOCOL, as part of the UEFI 2.5 checkins. This UEFI NVM Express protocol provides services that allow NVM Express commands to be sent to an NVM Express controller or to a specific namespace in a NVM Express controller.

I’ve found the definitions in the code, but not an implementation, so either the checkin hasn’t happened yet, I’ve missed it, or it’s a non-open source implementation that won’t be in the TianoCore code, I’m unclear. If you know, please speak up!

For more information, see:
MdePkg/Include/Protocol/NvmExpressPassthru.h
and:

Front

New UEFI HTTP Boot support in UEFI 2.5

~ hucktech ~ 1 Comment

One of the new features in UEFI 2.5 is the use of the HTTP protocol for network booting. Previously, UEFI booted remotely, using IPv4 or IPv6, starting with DHCP, then finishing using TFTP, “PXE-based”. This new UEFI 2.5 change defines new DHCP options to specify URI-based pointers to the “Network Boot Program (NBP)”, the binary image to download and run, which can be used using HTTP instead of TFTP. DHCP Servers will need to support this new HTTPBoot extension, if the DHCP type code for x86 is 0x0F and 0x10 for x64. For example, inside a corporate enterprise, with an URL like:
http://examplebootserver/boot/boot.efi

HTTP aside, the new spec hints of future URI-based network protocol support, such as FTP or NFS, in the future.

AFAICT, this presumes HTTP, not HTTPS. Most of the spec says HTTP. Only in one place did I see a reference to TLS and HTTPS, see Figure 72. But TLS and the S in HTTPS were in red, unlike all else, unclear what this means, if it is not public feature only in commercial UEFI products, etc.  Speak up if you know.

The spec mentions both enterprise and home use of this protocol, and they mention usage of this protocol across across networks (via the public Internet), not just internal home/corporate network use.

Refer to section 23.7 of the UEFI v2.5 specification for more details.
http://www.uefi.org/specsandtesttools

I’ve yet to locate this code in the public TianoCore EDK-II trunk; either I’ve missed it, it hasn’t yet been checked in, or the code is part of a non-open source codebase. It would answer the HTTPS/TLS question, as well. Speak up if you know the answer!

UEFI systems’s updates can incorporate new features, so this feature may show up in your system the next time your vendor issues an update. So, DNS, DHCP, and HTTP are all network attack vectors for network UEFI booting. Is your firewall/router ready for UEFI HTTP Booting?

New storage crypto Interface protocol added to UEFI 2.5

~ hucktech ~ Leave a comment

A few days ago, as part of the UEFI 2.5 checkins, Tien Feng of Intel checked in new code to the EDK-II trunk, with a new UEFI Inline Cryptographic Interface protocol.

“The EFI_BLOCK_IO_CRYPTO_PROTOCOL defines a UEFI protocol that can be used by UEFI drivers and applications to perform block encryption on a storage device, such as UFS.”

The interface protocol provides services to abstract access to inline cryptographic capabilities. It has the abilities to get, configure and use pre-OS crypto support in disks, and can configure algorithms, key sizes and keys. It has interfaces such as Reset, GetCapabilities, SetConfiguration, GetConfiguration, ReadExtended, WriteExtended, and FlushBlocks. The latter are read/write/flush functions which encrypt/decrypt the data.

For more information, read MdePkg/Include/Protocol/BlockIoCrypto.h and search for EFI_BLOCK_IO_CRYPTO_PROTOCOL_GUID.

Universal Flash Storage (UFS) support added to UEFI

~ hucktech ~ Leave a comment

Late last month, Feng Tien of Intel checked in new code to the EDK-II trunk, with support for a Universal Flash Storage (UFS) stack.

The stack “includes 4 drivers:
1. UfsPassThruDxe, which is a UEFI driver and consumes EFI_UFS_HOST_CONTROLLER_PROTOCOL and produces EFI_EXT_SCSI_PASS_THRU_PROTOCOL.
2. UfsPciHcDxe, which is specific for pci-based UFS HC implementation and is a UEFI driver to produce EFI_UFS_HOST_CONTROLLER_PROTOCOL.
3. UfsBlockIoPei, which is a PEI driver and consumes EFI_UFS_HOST_CONTROLLER_PPI and produces EFI_PEI_VIRTUAL_BLOCK_IO_PPI.
4. UfsPciHcPei, which is specific for pci-based UFS HC implementation and is a PEI driver to produce EFI_UFS_HOST_CONTROLLER_PPI.”

EDK-II updating to UEFI 2.5

~ hucktech ~ Leave a comment

Starting a few days ago, there’ve been many UEFI 2.5-specific checkins to the EDK-II trunk.

MdePkg/Include/Uefi/UefiSpec.h now has a EFI_2_50_SYSTEM_TABLE_REVISION entry. There are similar updates to PI structures.

I’ll have some more blog entries on other specific new changes for UEFI 2.5 — specs and code — in the coming days, there is a lot to study…

Embedded medical devices and firmware updates

~ hucktech ~ Leave a comment

Yesterday Cory Doctorow had a story in yesterday’s BoingBoing about medical device security, including firmware security. Excerpt:

“Like other medical devices that independent security researchers have looked at, Richards said the Hospira LifeCare pump did not validate the authenticity of firmware updates prior to installing them – a common problem in the medical device sector.”

Read the full story here:

Drug pump is “most insecure” devices ever seen by researcher

Windows 10 UEFI Secure Boot policy welcomed by Linux users

~ hucktech ~ Leave a comment

In an article by Sam Varghese in iTWire, Linux users will find Microsoft’s current advice to Windows 10 OEMs regarding UEFI Secure Boot welcome news. More information here:

http://www.itwire.com/opinion-and-analysis/open-sauce/67959-microsofts-new-secure-boot-strategy-will-suit-linux-firms

 

[iTWire article aside, more welcome news would be if OEMs would build consumer Linux devices with Secure Boot working directly with them, without Microsoft PKI/CA/keys, in some of their models. Intel and SuSE demonstrated this at IDF2013, yet no consumer devices are available, AFAIK.
Even more welcome news would be offering Coreboot as an option, including new Coreboot support in UEFI as PI component.
Even more news would be providing systems where owners could build and update their own firmware, from tianocore.org and coreboot.org code, along with any new drivers from the OEM, and have a firmware update mechanism for local owner-users, not only beg for updates from vendors.
But I guess I should simply be happy that Microsoft is permitting Windows OEMs to still let users install software on the HW/FW/SW that we don’t actually own/control. 🙂 –ed]

 

New FPGA embedded security research from GTRI

~ hucktech ~ Leave a comment

As reported today by Rick Robinson, Georgia Institute of Technology, in Scientific Computing, researchers at Georgia Tech Research Institute (GTRI) have interesting new research for use of FPGAs in embedded system design, which adds “entirely new attack vectors to consider, ones that lie outside the traditional computer security mindset.” Read the full Scientific Computing article here[1], and read the GTRI research here[2].

[1] http://www.scientificcomputing.com/news/2015/05/advancing-security-and-trust-reconfigurable-devices
[2] http://www.gtri.gatech.edu/casestudy/advancing-security-and-trust-reconfigurable-device

 

TianoCore mailing list migration to 01.org begins

~ hucktech ~ Leave a comment

The first step of the migration from the SourceForge-hosted mailing lists to Intel 01.org-hosted lists is underway:

https://lists.01.org/mailman/listinfo/edk2
http://www.tianocore.org/news/2015/05/01/UnderConst.html

Today, on the edk2-devel mailing list, Joe Peterson of Intel announced the availability of the replacement EDK2 mailing list:

“Due to community feedback, a new mailing list is being set up to replace this one. The new list will be hosted on Lists.01.org and should be more stable and consistent than this one. The host has an opt-in policy and will not allow the current subscription list to be imported so you will need to subscribe yourself. The timing of the final conversion to the new list is still to be determined, but in the meantime you can sign up for the new list here:  https://lists.01.org/mailman/listinfo/edk2/ . Please keep all relevant communications on this channel and do not use the new one for patches or questions yet. Feel free to post questions/comment/concerns to this current list. Stay tuned for more updates… A list of the content changes / improvement being worked can be found here:  http://www.tianocore.org/news/2015/05/01/UnderConst.html . Thank you.”