Tag: UEFI

RU.EFI updated, screen snapshot support

~ hucktech ~ 1 Comment

http://ruexe.blogspot.com/2016/09/ru-518291-beta.html

https://github.com/JamesAmiTw/ru-uefi/

 RU 5.18.291 BETA
This release is mainly for saving snapshot from RU screen as BMP file.  Which is requested by Gary and other users.  Special thanks to Mykhaylo for the help. I didn’t test this version at all, so it could be buggy.  Please leave me a message if you find any bug.

New feature:
RU.EFI: Add F12 key to capture the screen snapshot to BMP file.
File name is auto-generated: Format: “YYYYMMDDhhmmss.bmp”
RU.EXE does not support this.

See post for list of bugfixes.

cryptboot

~ hucktech ~ Leave a comment

Interesting new project. I wish most modern Linux distros let you control keys in ways like this. Check out the entire web page on Github, nice read for Linux/UEFI even if you don’t plan on using cryptboot.

https://github.com/xmikos/cryptboot

Encrypted boot partition manager with UEFI Secure Boot support

With encrypted boot partition, nobody can see or modify your kernel image or initramfs. GRUB boot loader supports booting from encrypted boot partition, but you would be still vulnerable to Evil Maid attacks. One possible solution is to use UEFI Secure Boot. Get rid of preloaded Secure Boot keys (you really don’t want to trust Microsoft and OEM), enroll your own Secure Boot keys and sign GRUB boot loader with your keys. Evil maid would be unable to boot modified boot loader (not signed by your keys) and whole attack is prevented. cryptboot simply makes this easy and manageable.

Requirements
* Linux (x86_64)
* UEFI firmware with enabled Secure Boot
* separate /boot partition encrypted with LUKS
* cryptsetup
* openssl
* efitools
* sbsigntools
* efibootmgr
* grub (grub-efi on Debian based distributions)

[…]

And this article points out something else crazy: “but current TrustedGRUB2 doesn’t even support UEFI yet.“

Steven Ellis: firmware updating on Linux

~ hucktech ~ Leave a comment

Steven Ellis of Red Hat has a new article on OpenSource.com on updating firmware and UEFI, with lots of good stuff to read. He mentions his next article will be on the topic of patching SSD firmware, which sounds very interesting. Spoiler alert: I’m exerpting his Recommendations from the end of the post:

[…] In this article, I’ll walk through my recent firmware update on Linux, and I’ll share a few recommendations based on that experience. […]
Recommendations:
* More vendors should allow UEFI BIOS updates directly from the BIOS-style interface. UEFI shell command-line isn’t for the casual user.
* If your vendor supplies a bootable image, try to use that first.
* Investigate what supported tools are available, but consider using a live image for patching. I’m somewhat wary of tools that build and install their own kernel modules.
* Assist projects—like flashrom—to avoid these issues in the future.
[…]

https://opensource.com/life/16/8/almost-open-bios-and-firmware-update-tips-linux-users

ACPICA shipping acpidump.efi

~ hucktech ~ Leave a comment

In recent news on the ACPICA site is:

“AcpiDump for UEFI is now available at Downloads/uefi-support – 26 August, 2016 – 13:57”

The tool acpidump now targets UEFI, in addition to OSes. In addition to shipping source via Github, they ship a zip with prebuilt Intel 32- and 64-bit .efi binaries, no ARM binaries.

https://github.com/acpica/acpica/tree/master/source/tools/acpidump

https://acpica.org/downloads/uefi-support

https://acpica.org/

If there is a place where the above web site’s ‘recent news’ is delivered via RSS or Atom or Twitter or NNTP or some announce mailing list or even Facebook, please leave a Comment. I think I’m not on the right ACPI list or something… Thanks.

PeiBackdoor: new UEFI payload/backdoor tool

~ hucktech ~ 1 Comment

Dmytro Oleksiuk (aka Cr4sh) has created a new UEFI security researcher tool: PeiBackdoor, which hooks into the init code of UEFI. (PEI is the Pre-uEfi-Init phase, before all the UEFI protocols are in place, the init code of UEFI.) It uses Capstone, and requires Windows.

PEI stage backdoor for UEFI compatible firmware

This project implements early stage firmware backdoor for UEFI based firmware. It allows to execute arbitrary code written in C during Pre EFI Init (PEI) phase of Platform Initialization (PI). This backdoor might be useful for low level manipulations with the target platform configuration when the most of the platform configuration registers are not locked yet. […]

PEI backdoor project includes:

* PeiBackdoor.py – Python program that allows to infect raw flash images or individual UEFI PEI drivers with the backdoor code.
* PeiBackdoor_IA32.efi, PeiBackdoor_IA32.pdb – 32-bit PEI backdoor binary compiled with ACTIVE_PLATFORM = IA32.
* PeiBackdoor_X64.efi, PeiBackdoor_X64.pdb – 64-bit PEI backdoor binary compiled with ACTIVE_PLATFORM = X64.
* PeiBackdoor.inf – PEI backdoor project configuration for EDK2 build environment.
* config.h – PEI backdoor build options.
* payload.c – Put your own PEI stage code into this source file and call it from Payload() function.
* src/ – Rest of the PEI backdoor code.

PeiBackdoor.py is using Capstone engine and pefile Python libraries, you need to install them with pip install capstone pefile command.
[…]

https://github.com/Cr4sh/PeiBackdoor

CHIPSEC ported to Apple Mac OS X!

~ hucktech ~ Leave a comment

Wow, CHIPSEC is ported to Mac OS X! This is great news for Mac owners! CHIPSEC requires a native kernel driver to support CHIPSEC’s HAL. Before this, there was only Linux and Windows HAL drivers for CHIPSEC, so Mac OS X users had to reboot with a Linux-based distro which had CHIPSEC (eg, LUV-live). Live use aside, this also probably means you’ll be able to use CHIPSEC on OS X for offline analysis of blobs.

OSX Driver for Chipsec. This driver is currently in alpha release. It is not signed and you will need to disable the System Integrity Protection to load it. It is only compatible with x86_64 kernels, that is any release >= 10.7. How to:
1. (optional) Build the Driver using Xcode (chipsec.xcodeproj)
2. Turn the System Integrity Protection off: see
    https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html
3. Reboot and load the driver
   # kextutil chipsec.kext
4. Within the source/tool directory, run:
   # python chipsec_util.py spi info
   # python chipsec_util.py spi dump rom.bin
5. Unload the driver

https://github.com/chipsec/chipsec/blob/master/source/drivers/osx/README

https://github.com/chipsec/chipsec/pull/69

https://github.com/chipsec/chipsec/commit/b00c037101523212725c60d35f3f70b168a44e1c

With an OS X port of the CHIPSEC HAL, Apple’s OS is starting to catch up with Linux and Windows. I hope Apple paid @tweksteen for the effort, Apple should have done this port long ago. FreeBSD/OpenBSD/NetBSD: time for you to catch up too! 🙂

William reviews CrScreenshotDxe

~ hucktech ~ 1 Comment

William has done another tool review, this time of Nikolaj’s CrScreenshotDxe tool. He does must longer blog posts on tool reviews than me, so it is always nice to see another review from him. 🙂

[…] “Nikolaj did us all a great service by posting this utility on Github.  It was easy to integrate and worked flawlessly.” […]

http://www.basicinputoutput.com/2016/08/the-joy-of-crscreenshotdxe.html

https://github.com/LongSoft/CrScreenshotDxe

screenshot-taking UEFI DXE driver

CHIPSEC adds blacklist database of UEFI modules

~ hucktech ~ Leave a comment

CHIPSEC 1.2.4 was recently released:

CHIPSEC 1.2.4 released

One new feature is a blacklist database of bad UEFI modules, and a new CHIPSEC security module to test for them, see the modules/tools/uefi/blacklist.py source for more details.

https://github.com/chipsec/chipsec/commit/bb9c9963547aae91a416be695c7f8b97fa61a3e8

Look at some of Yuriy’s more recent Twitter posts for a few new features not listed in the previous 1.2.4 release blog post, in addition to this blacklist.

UEFI Forum updates Secure Boot revocation database?

~ hucktech ~ Leave a comment

I wish I knew some more authoritative sources of news for this Microsoft Secure Boot story… 😦 The below post implies that the UEFI Forum’s Secure Boot recovation list file has been updated in response to recent news.

I REALLY wish the UEFI Forum would *announce* when they update their Secure Boot revocation list, and include version history to the changes, and keep older releases available for diffing against current one. It seems something this important should not be under public version control so you can see when keys come and go, and why. The current web page on this database should include information about the entries in the current database, and show changes and why. The page for this database should include end-user information for sysadmins to apply this to their systems, I see no real documentation on this page on how to properly use this database.
http://uefi.org/revocationlistfile

excerpt from https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

[…] In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new new individual signature entries into dbx, raising the total to 77.  […]

more on Microsoft UEFI Secure Boot golden key news

~ hucktech ~ Leave a comment

There are a few news stories coming out saying that the recent Microsoft Secure Boot stories are mostly false, pointing to a Steve Gibson video podcast.

If someone had some good technical background on this story, please leave a Comment to this post, thanks!

https://redmondmag.com/articles/2016/08/17/windows-secure-boot-slip-up.aspx

Kurt Mackie has a story in Redmond Magazine about the recent Microsoft Secure Boot news:

[…] There were no actual software keys involved when anonymous researchers claimed that Microsoft had leaked so-called “golden keys” to the Windows secure boot protection scheme, according to an industry veteran. That point of view was offered by Steve Gibson, president and founder of Gibson Research Corp., a small software development firm in Laguna Hills, Calif. “It was completely wrongly reported” by the press, Gibson said in a “Security Now” show yesterday. Gibson is cohost on the show, which is published by the Twit network. “It was nice work,” Gibson said about the researchers’ findings, “but the whole golden key was an absolute red herring referring to the notion of backdoor systems. But this wasn’t that. It was a mistake.” […] “What this actually was was an implementation design error in the handling of boot permission policies which can be used to trick older versions of the UEFI secure boot manager using some components of an update. So the so-called ‘Redstone’ version of Windows 10, which is version 1607, we know it as the ‘anniversary update,’ it added some new technology in the concept of supplemental secure boot policies, which can, for example, be used for test-signing development code. And of course, that could also be [used for running] malicious rootkits and so on.” […]

http://www.winbeta.org/news/microsofts-golden-key-agenda-actuality

Kareem Anderson of WinBeta has a similar story:

Microsoft’s ‘Golden key’ is more agenda than actuality “None of that is true. Complete misreporting.”

ThinkPwn updated

~ hucktech ~ Leave a comment

https://github.com/Cr4sh/ThinkPwn/commit/d496e7d9a4bbb1e2903a94802760d52c1e46c037
https://github.com/Cr4sh/ThinkPwn/

UEFI bootloader for Google Fuchsia

~ hucktech ~ 1 Comment

Apparently Google is working on a new OS called Fuchsia, which is not based on Linux, Android, or ChromeOS. One of the components of Fuchsia is Magenta.

I just noticed that Magenta has a UEFI-aware bootloader.

https://github.com/fuchsia-mirror/gigaboot20x6

“This project contains some experiments in software that runs on UEFI firmware for the purpose of exploring UEFI development and bootloader development.”

https://github.com/fuchsia-mirror
https://github.com/fuchsia-mirror/magenta
https://github.com/fuchsia-mirror/magenta/blob/master/docs/index.md
https://github.com/littlekernel/lk

 

Multiple Intel systems have SMM runtime EoP

~ hucktech ~ Leave a comment

See the full announcement for the list of vulnerable products. Regardless of model, it sounds like no fix until early September.

SmmRuntime Escalation of Privilege
Intel ID:      INTEL-SA-00056
Product family:      Intel® Server Board S1200/1400/1600/2400/2600/4600 series
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important
Original release:      Aug 08, 2016

Intel is releasing mitigations for a privilege escalation issue. This issue affects the UEFI BIOS of select Intel Products. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable function to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Other vendors’ products which use the common BIOS function SmmRuntime may be impacted.  To find out whether a product you have may be vulnerable to this issue, please contact your system supplier. Intel highly recommends applying the mitigations. For Intel branded products where a mitigation is still pending, we recommend following good security practices including running with least privilege and keeping security software and operating systems up to date. […]

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr