[…]For servers with greater than 24 days of power on time since the last AC power cycle, the first BIOS update will fail because the Intel Management Engine (ME) fails to enter recovery mode for the BIOS update.[…]
Non-Dell OEMs: please also add this to your QA cycle. 🙂
The Dell Security & Resiliency organization manages the security risk across all aspects of Dell’s business.
Responsible for discovering and exploiting vulnerabilities affecting Dell software and firmware
Developing and maintaining tools to assist in vulnerability research and exploit development
5+ years direct or equivalent experience in areas of vulnerability research, exploit development, reverse engineering and fuzzing
- Responsible for discovering and exploiting vulnerabilities affecting Dell software and firmware
Nikolaj is learning Rust. He just rewrote one C tool to Rust:
“Dell ship their Sputnik systems with a pre-populated MokSB variable that disables Secure Boot, so this is working as intended on the Fedora side.”
” OpenUSM – Let Docker Containers Manage Your Datacenter
OpenUSM is a suite of tools and utilities which configures and manage the lifecycle of system management. OpenUSM has a capability to perform the following functions:
* BIOS Token Change
* Firmware Update
Reminder to OEMs: publish the hashes of your platform firmware. Hopefully using codehash.db.
In below twitter thread, Joanna asked Dell support for hashes for their firmware. Eventually, Rick Martinez of Dell got involved, so this is a good example of a conversation on this topic by two who understand the issues.
It looks like Dell needs to use HTTPS:
Platform Software Senior Principal Engineer/BIOS Architect (17000X39)
[…]You’ll apply skills and experience across the full cycle of software development (specification development and review, debug and validation) to enable features and capabilitiesof platforms in areas like UEFI drivers, thermal, power management, security, manageability, manufacturability, configurability and embedded controllers.
* Work with Industry forums for spec development like UEFI, DMTF, PCI Sig, ACPI, etc
* Ability to take ownership of overall UEFI platform design throughout the platform lifecycle
* 12+ years experience in BIOS / firmware SW development
* UEFI Programming expertise
* Low level programming capability -system/motherboard/device/chipset level
* Experience with analyzers and other HW tools to debug complex system SW issues
PFSExtractor v0.1.0 – extracts contents of Dell firmware update files in PFS format
Usage: PFSExtractor pfs_file.bin
“[…] Responsible for discovering and exploiting vulnerabilities affecting Dell software and firmware. […]“
If you build a Linux-based system, you should be putting your firmware updates on fwupd. Dell is the only vendor currently doing this.
What about: System76, ThinkPenguin, Purism, HP, etc??
Hmm, it looks like System76 might be working on it!
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.
RackHD is a technology stack created for enabling hardware management and orchestration, to provide cohesive APIs to enable automated infrastructure. In a Converged Infrastructure Platform (CIP) architecture, RackHD software provides hardware management and orchestration (M&O). It serves as an abstraction layer between other M&O layers and the underlying physical hardware. Developers can use the RackHD API to create a user interface that serves as single point of access for managing hardware services regardless of the specific hardware in place.
SecuriTeam confused me by reposting a 2016 Dell iDDRAC vulnerability today, but I don’t see anything new. Just in case you weren’t aware of this issue, and you have a Dell system, here’s info on this older vulnerability, see the last link for a PDF-based response from the Dell iDRAC team.
“Dell iDRAC team’s response to Common Vulnerabilities and Exposures (CVE) ID CVE-2016-5685 [16 November 2016]
Summary: an authenticated user could gain Bash shell access through a string injection.
Dell Response: update to the latest iDRAC firmware, which remediates this potential vulnerability.”
“This repo contains the exploit for the Dell 2410U monitor. It contains utilities for communicating with and executing code on the device. The research presented here was done in order to highlight the lack of security in “modern” on-screen-display controllers. Please check out our Recon 0xA presentation (included) for a detailed description of our research findings and process.[…]”
William Leara has a new blog post which is an introduction to CHIPSEC. It is a nice introduction to CHIPSEC, if you have never used it before, this is a great way to get started.
Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:
Hewlett Packard Enterprises
Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.
The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.
William Leara, a firmware engineer at Dell, has a new blog post on Nikolaj Schlej’s UEFI Tool. He shows how to use it, starting with using Intel’s Flash Programing Tool (FPT) to acquire a BIOS image. Lots of screenshots of the various menu UI components of this GUI tool.
“It is extremely useful for interrogating and manipulating the components of a UEFI BIOS image. Download it and give it a test drive today!”