Tag: UEFI

Linux Foundation workstation security ebook

~ hucktech ~ Leave a comment

[…]Now, before you even start with your operating system installation, there are a few things you should consider to ensure your pre-boot environment is up to snuff. You will want to make sure:
* UEFI boot mode is used (not legacy BIOS) (ESSENTIAL)
* A password is required to enter UEFI configuration (ESSENTIAL)
* SecureBoot is enabled (ESSENTIAL)
* A UEFI-level password is required to boot the system (NICE-to-HAVE)

https://www.linux.com/news/linux-workstation-security/2017/3/4-security-steps-take-you-install-linux

http://go.linuxfoundation.org/workstation_security_ebook

Sounds interesting, but I don’t see any actual download link for this ebook. I guess I need some sleep.

There is also this: https://firmwaresecurity.com/2015/08/31/linux-foundation-it-security-policies-firmware-guidance/

 

CHIPSEC gets UEFI variable fuzzer

~ hucktech ~ Leave a comment

The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size. Note: this module modifies contents of non-volatile SPI flash memory (UEFI Variable NVRAM). This may render system unbootable if firmware doesn’t properly handle variable update/delete operations.
 
Usage:
    “chipsec_main -m tools.uefi.uefivar_fuzz [-a <options>]“
    
Options:        
    “[-a <test>,<iterations>,<seed>,<test_case>]“
    – “test“        which UEFI variable interface to fuzz “(all, name, guid, attrib, data, size)“
    – “iterations“    number of tests to perform (default = 1000)
    – “seed“        RNG seed to use
    – “test_case“    test case # to skip to (combined with seed, can be used to skip to failing test)
    All module arguments are optional
    
Examples:
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a all,100000
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a data,1000,123456789
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a name,1,123456789,94

https://github.com/chipsec/chipsec/blob/master/chipsec/modules/tools/uefi/uefivar_fuzz.py

 

UEFI VBS required by Microsoft

~ hucktech ~ Leave a comment

https://twitter.com/aionescu/status/835553407398100992

 

“VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.”

I’m glad Alex is reading these Microsoft updates better than I am. 🙂 Glad to know that VBS is not VBScript.

Microsoft updates OEM Device/Credential Guard requirements

Microsoft updates Device Guard OEM guidance

Microsoft Updates OEM Device/Credential Guard requirements

Microsoft updates Secure Boot and ACPI requirements

~ hucktech ~ Leave a comment

These Microsoft pages have recently (last month) been updated. No changelog, so unclear what has changed. 😦

 

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/secure-boot-and-device-encryption-overview

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/device-experiences/acpi-firmware-implementation-requirements

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/firmware-requirements-for-d3cold

 

Tianocore patch to increase memory protection

~ hucktech ~ Leave a comment

Ard Biesheuvel of Linaro submitted a V2 5-part patch to the EDK2 project, to harden UEFI more!

This is a proof of concept implementation that removes all executable permissions from writable memory regions, which greatly enhances security. It is based on Jiewen’s recent work, which is a step in the right direction, but still leaves most of memory exploitable due to the default R+W+X permissions. The idea is that the implementation of the CPU arch protocol goes over the memory map and removes exec permissions from all regions that are not already marked as ‘code. This requires some preparatory work to ensure that the DxeCore itself is covered by a BootServicesCode region, not a BootServicesData region. Exec permissions are re-granted selectively, when the PE/COFF loader allocates the space for it. Combined with Jiewen’s code/data split, this removes all RWX mapped regions.

Changes since v1:
– allocate code pages for PE/COFF images in PeiCore, so that DxeCore pages have the expected memory type (as suggested by Jiewen)
– add patch to inhibit page table updates while syncing the GCD memory space map with the page tables
– add PCD to set memory protection policy, which allows the policy for reserved and ACPI/NVS memory to be configured separately
– move attribute manipulation into DxeCore page allocation code: this way, we should be able to solve the EBC case by allocating BootServicesCode pool memory explicitly.

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

Slides for coreboot/UEFI talk from REcon available

~ hucktech ~ Leave a comment

 

Click to access REConBrussels2017_BARing_the_system.pdf

http://www.intelsecurity.com/advanced-threat-research/index.html

Kaspersky Antivirus for UEFI

~ hucktech ~ Leave a comment

 

[…]Kaspersky Antivirus for UEFI is integrated into Kraftway’s proprietary chip-based Kraftway Security Shell to ensure timely detection and blocking of malware attacks against key points (Master Boot Record, Global Partition Table, OS loader and kernel, key OS files, registry, critical files and directories, etc.) before the OS itself even starts to load.[…]

 

https://usa.kaspersky.com/oem/partners/kraftway

http://www.kraftway.ru/en/

http://www.kraftway.ru/products/detail.php?ID=1438&sphrase_id=21351

SUSE on UEFI -vs- BIOS

~ hucktech ~ Leave a comment

I missed this blog post from SuSE from last year:

[…]One UEFI topic that I noticeably did not address in this blog is secure boot. This was actually covered extensively in three previous blogs. To read those blogs do a search for “Secure Boot” at suse.com. I also did not address the comparison of UEFI and BIOS from the operating systems perspective in this blog. That is a separate blog that was released at the same time as this one (Comparison of UEFI and BIOS – from an operating system perspective). Please read it too. Hopefully this gives you some helpful information about the transition from BIOS to UEFI, on the hardware side. You can find more information about SUSE YES Certification at https://www.suse.com/partners/ihv/yes/ or search for YES CERTIFIED hardware at https://www.suse.com/yessearch/. You can also review previous YES Certification blogs at YES Certification blog post[…]

https://www.suse.com/communities/blog/comparison-uefi-bios-hardware-perspective/

UEFI-D: D language bindings for UEFI

~ hucktech ~ Leave a comment

D bindings for UEFI specifications, based on the headers from EDK II 2015. They allow to compile fully functional EFI executables without assembly or C bootstrapping, it boots directly to D 🙂 They can be used to build UEFI-compatible applications and drivers in the D Programming Language. Sample “Hello, world” program is provided, with source and a linux script to compile[…]

http://forum.dlang.org/thread/kjmjtauonvlxhdaqcpij@forum.dlang.org

https://github.com/kubasz/uefi-d

http://code.dlang.org/packages/uefi-d

https://github.com/kubasz/uefi-d/blob/master/sample/photo.jpg?raw=true

 

Rootkits and Bootkits book update

~ hucktech ~ 1 Comment

https://www.nostarch.com/rootkits

Table of Contents
Chapter 1: Observing Rootkit Infections
Chapter 2: What’s in a Rootkit: The TDL3 Case Study (NOW AVAILABLE)
Chapter 3: Festi Rootkit: The Most Advanced Spam Bot (NOW AVAILABLE)
Chapter 4: Bootkit Background and History (NOW AVAILABLE)
Chapter 5: Operating System Boot Process Essentials (NOW AVAILABLE)
Chapter 6: Boot Process Security (NOW AVAILABLE)
Chapter 7: Bootkit Infection Techniques (NOW AVAILABLE)
Chapter 8: Static Analysis of a Bootkit Using IDA Pro (NOW AVAILABLE)
Chapter 9: Bootkit Dynamic Analysis: Emulation and Virtualization (NOW AVAILABLE)
Chapter 10: Evolving from MBR to VBR Bootkits: Olmasco (NOW AVAILABLE)
Chapter 11: IPL Bootkits: Rovnix & Carberp (NOW AVAILABLE)
Chapter 12: Gapz: Advanced VBR Infection (NOW AVAILABLE)
Chapter 13: Rise of MBR Ransomware (NOW AVAILABLE)
Chapter 14: UEFI Boot vs. the MBR/VBR Boot Process (NOW AVAILABLE)
Chapter 15: Contemporary UEFI Bootkits
Chapter 16: UEFI Firmware Vulnerabilities
Chapter 17: How Secure Boot Works
Chapter 18: HiddenFsReader: Bootkits Forensic Approaches
Chapter 19: CHIPsec: BIOS/UEFI Forensics

dual-booting FreeBSD or Windows

~ hucktech ~ Leave a comment

Kevin Bowling has an article that shows how to setup a UEFI system to work with FreeBSD — including ZFS on root — and another UEFI OS like Windows.

https://www.freebsdnews.com/2017/01/23/freebsd-uefi-root-zfs-windows-dual-boot-kevin-bowling/

https://bsdmag.org/freebsd_uefi_root/

I’m not sure if this article is an improved version of or just a rebroadcast of:

http://kev009.com/wp/2016/07/freebsd-uefi-root-on-zfs-and-windows-dual-boot/

 

Tianocore patch to harden UEFI executables

~ hucktech ~ Leave a comment

Ard Biesheuvel of Linaro has posted a V2 patch to the Linux-EFI list, which includes some UEFI image hardening.

[PATCH v2 00/14] arm64+ARM: efi: PE/COFF cleanup/hardening

This cleans up the PE/COFF EFI header, by taking some of Mark’s patches and use them to replace open coded constants with symbolic ones, and remove incorrect values or unused sections. Finally, it updates the section layout so that the kernel Image can be mapped in a way that does not require setting RWX permissions anywhere. Note that this is currently not a huge win, given that most current UEFI implementations map all of RAM RWX by default, but this is finally gaining some attention, and work is underway to make the PE/COFF loader in EDK2 adhere to the section permissions, which would also allow the RAM mapping to default to non-executable. Work in progress nonetheless…

Changes since v1:
– added missing secondary SOB on Mark’s patches
– leave Image header as before, only move the PE header to a separate file
– put PE header fixes in a separate patch
– add acks from Mark and Peter (#6)
– give ARM the same treatment as arm64 (#10 – #13)
– add NB10 PE debuglink entry to ARM PE/COFF header as well (#9, #14)

Full announcement/patch:
http://vger.kernel.org/majordomo-info.html

Testing SMM with QEMU, KVM and libvirt

~ hucktech ~ Leave a comment

Laszlo Ersek has created a new document that shows how to test SMM using UEFI’s OVMF. Great information!

I’ve added the following article to the TianoCore wiki[1]. It should help both Windows and Linux desktop users build a KVM test machine / environment that closely resembles mine. Such an environment is useful for testing and regression-testing new MP and SMM features and bugfixes. The initial setup is not short, but once you got it up and running, it’s very simple to rebuild OVMF with the edk2 changes, install the firmware binary in the right place (see the article) and then click the Play button on the Fedora 25 and Windows 10 guests, to see the changes in action. If you have smaller updates or structural reorgs for the document, there’s no need to ask me, just go ahead and do them. If some significant information is missing that you’d like me to add, I think I’d prefer new TianoCore BZs at this time (Product: Tianocore Feature Requests, Component: Web Content, Assignee: yours truly). I don’t know when I’ll have time again to dig into this.
[1]https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

Full announcement:
https://lists.01.org/mailman/listinfo/edk2-devel

Tianocore BIOS setup authentication password patch

~ hucktech ~ Leave a comment

Jiewen Yao of Intel posted a V2 patch to the EDK2-devel list, adding new user authentication to Tianocore, including SMM interaction.

==== V2 ====
1) Add SmmCommunicationBufferProtocol dependency.
2) Cleanup header file and copyright to 2017.
3) Add missing UserAuthenticationSmm.uni.
4) Rename KeyLib.h/c to KeyService.h/c to avoid confusing.

This series patch adds password support in EDKII. This password based user authentication is to verify user when a user
wants to enter BIOS setup page. The detail information is added in [PATCH 5/6].

CryptoPkg:SmmCryptLib: Add real Pkcs5Pbkdf2.c.
SecurityPkg/dec: Add PcdPasswordCleared.
SecurityPkg/include: Add PlatformPasswordLib lib class.
SecurityPkg/PlatformPasswordLibNull: Add PlatformPasswordLib instance.
SecurityPkg/Password: Add Password based UserAuthentication modules.
SecurityPkg/dsc: add Password authentication module.

24 files changed, 2768 insertions(+), 2 deletions(-)

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

UEFI port of CHIP-8 game engine

~ hucktech ~ 1 Comment

There’s a CHIP-8 emulator written for most platforms, now including UEFI. The executable uc8.efi is built using the GNU-EFI toolchain, not the Tianocore toolchain.

“CHIP-8 emulator as an UEFI application”

Usage: uc8 FILE [ROM]

Follow the instructions on your screen. In case of trouble, press Z.

About CHIP-8, Wikipedia says: ”
There are a number of classic video games ported to CHIP-8, such as Pong, Space Invaders, Tetris, and Pac-Man. There’s also a random maze generator available. These programs are reportedly placed in the public domain, and can be easily found on the Internet.”

https://github.com/Reisse/uefi-chip8

https://en.wikipedia.org/wiki/CHIP-8