Category: Uncategorized
Intel ME coverage from BHEU
Brian: Using CHIPSEC Whitelists to Improve Firmware Security
[Strange, I was doing the previous blog post on Brian, and during that time, he did a new blog post…]
Brian Richardson of Intel has a new blog post on using CHIPSEC whitelist command to help with UEFI security:
Using Whitelists to Improve Firmware Security
Firmware has become more popular in the world of computer security research. Attacks operating at the firmware level can be difficult to discover, and have the potential to persist even in bare-metal recovery scenarios. This type of hack has been well documented by investigations of the HackingTeam and Vault7 exploits. Fortunately, there are methods for detecting and defending against such attacks. Firmware-based attacks typically attempt to add or modify system firmware modules stored in NVRAM. Tools provided by the open source CHIPSEC project can be used to generate and verify hashes of these modules, so users can detect unauthorized changes.[…]
https://software.intel.com/en-us/blogs/2017/12/05/using-whitelists-to-improve-firmware-security
https://github.com/chipsec/chipsec
Brian speaking at ESCConf on UEFI security
Brian Richardson of Intel will be speaking at the Embedded Systems Conference (ECS Conf) on firmware security, talk is called:
What You Don’t Know About Firmware Might Get You 0wn3d
I’m not sure I blogged on this, but Brian also gave a talk at BSidesJackson:
And his talk about BIOS end-of-life from recent UEFI plugfest are also online:
Hammertime: rowhammer testing/profiling/simulating suite
Hammertime: a software suite for testing, profiling and simulating the rowhammer DRAM defect. Includes the following components:
* libramses: a library that handles address translation for the entire memory stack.
* libperfev-util: a library providing a more human-friendly interface to Linux’s performance event API.
* Probes for monitoring memory access behaviour of running programs.
* Predictors that decide whether a certain memory access behaviour triggers rowhammer.
* Glue code to tie all this together and effect bit flips in memory.
* Fliptables: example profiles of rowhammer-vulnerable DRAM chips, usable by a dedicated predictor.
* Various cool tools and utilities:
+ tools/profile: a tool to test a running system’s vulnerability to rowhammer.
+ py/prettyprofile.py converts a profile output into something more human-friendly.
+ py/hammerprof.py converts a profile output into a fliptable.
+ py/common_flips.py processes multiple profile results selecting only bit flips common to all. Useful for finding bit flips that can be reliably triggered.
+ py/pyramses is a Python interface to libramses.
+ py/hammertime/ contains Python interfaces to work with profile results and fliptables.
+ py/hammertime/estimate.py is a framework for rapidly estimating Rowhammer attack effectiveness, based on exploit models and profile results.
+ ramses/tools/msys_detect.py is an interactive tool for detecting current system memory configuration.
UEFI-var-in-disk: Inject the UEFI variable in the first sector of hard disk
Bluntly, I’m not sure what this month-old project does yet, the title/tagline sounds more interesting than the usage, and I’ve not done a code review yet.
Inject the UEFI variable in the first sector of hard disk
usage text:
efi2disk version %s\n”, TOOL_VERSION);
usage: efi2disk [options]
-r | –read Read UFEI variable information
-V | –version return version and exit
-h | –help show help/usage
proposal: add Security Version to Linux Shim
Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.
Security Version
When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]
https://github.com/lcp/shim/wiki/Security-Version
https://marc.info/?l=linux-efi&m=151246813626512&w=2
PS: Hmm, Gmane’s linux-efi links aren’t working for me.
http://dir.gmane.org/gmane.linux.kernel.efi
sefi: Simple EFI boot manager
Simple EFI boot manager
sEFI is simple boot manager for UEFI capable computers. It uses simple C language and GNU-EFI library.
Differences from other boot managers:
* file browser to select efi applications
* really simple structure of config files
IfrViewer: Viewer for IFR structures
IfrViewer: tool that is able to read a binary HPK package and most (hopefully all in future) of its HII and IFR structures. A HPK file (used by EDKII) holds so called HII packages (Human Interface Infrastructure). The content of such a file follows the kind of file structure definition from UEFI specification. It can consist of many various things but in most cases it consists of strings for different languages and IFR structures (Internal Forms Representation) to be able to build the SETUP menu for UEFI capable systems.
* List all IFR structures in order to view a HPK’s content
* Improve GUI to handle this data more efficient
* Create HTML pages which can be viewed by standard web browser showing the skeleton of the HPK’s forms
https://github.com/topeterk/IfrViewer
Embedi SMM_USBRT_POC: CVE-2017-5721 UsbRt SMM EoP
CVE-2017-5721 Proof-of-Concept
UsbRt SMM Privilege Elevation
This is a Proof-of-Concept code that demonstrates the exploitation of the CVE-2017-5721 vulnerability. This PoC causes a system to be completely stuck because of Machine Check Exception occurred.
All you need is CHIPSEC Framework installed. And don’t forget to put GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash acpi=off” in /etc/default/grub if you have Intel device.
VisualUEFIShell
“Create and debug UEFI Shell EFI_APPLICATION using VS2017”
https://github.com/JoaquinCono/VisualUEFIShell
not to be confused with VisualUEFI:
https://github.com/ionescu007/VisualUefi
Note to both authors: Please support VSCode, not just Visual Studio, that is free and works on other OSes where UEFI is also used.
efivalidate (and mojo_thor)
Rick Mark has released efivalidate, a macOS-centric Ruby-based EFI checking tool. Also, by same author, Mojo_Thor project has activity. I thought it was a one-time drop, but it is actively being updated:
efivalidate is a ruby utility to take a given input EFI payload from macOS and to compare it against Apple’s validation schema. Being written in ruby this can occur off-box to ensure that the utility itself hasn’t been compromised
https://github.com/rickmark/efivalidate
Loki / Thor / Mojo are a triad of Apple internal tools and malware that infects the SMC, EFI and macOS of Apple MacBooks. It is believed that direct access to the hardware is gained by re-flashing the Thunderbolt controller (via ThorUtil)
more on Intel-SA-00068 (Intel ME)
Intel has updated the advisory documents. There are more OEMs in the list:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html
Acer
ASUS
Compulab
Dell Client
Dell Server
Fujitsu
Getac
GIGABYTE
HP Inc.
HPE Servers
Intel: NUC, Compute Stick, Compute Card
Lenovo
MSI
Oracle
Panasonic
Quanta/QCT
Supermicro
Toshiba
Vaio
System76 to disable Intel ME (Dell as well)
http://blog.system76.com/post/168050597573/system76-me-firmware-updates-plan
https://github.com/system76/firmware-update
PS: Liliputing has info on a few Dell models that also can have Intel ME disabled.
https://liliputing.com/2017/12/dell-also-sells-laptops-intel-management-engine-disabled.html
Qualcomm seeks bootloader engineer
Embedded Software Engineer – Bootloaders
Qualcomm processors provide integrated solutions for millions of diverse mobile and new emerging platforms across IoT, Automotive and Compute markets. It all starts with the Boot Firmware the first mission critical code to execute on our SoC(System on chip) and prepare the system for operation. We design and develop the software we put in mask boot ROM, along with system boot-loaders. Features we work on include image authentication, multicore setup, the UEFI pre-boot environment, configuration of next-generation DDR memories, ARM CPU and custom Qualcomm DSP/microprocessors, MMU/Cache memory management and advanced driver development for multiple boot/storage devices including eMMC, UFS, NAND, SPI-NOR, QSPI and flashless boot transport interfaces such as PCIe, SDIO, USB. Embedded Bootloader design & development involves architecting solutions to address different use cases and feature requirements in the early bootloader environment before the handoff to the High Level Operating System kernel. Engineer is expected to work with different Qualcomm build infrastructure tools and ARM compiler tool chains to enable different drivers and services for Bootloaders, optimizing them both for boot time, internal memory size constraints and power metrics.
* Design, development and integration of custom and/or open source Bootloaders for QCT mobile platforms.
* ThreadX, Linux, Android, Windows Boot process knowhow
* UEFI (Unified Extensible Firmware Interface) based bootloader and device driver model experience
* coreboot, uboot based bootloader experiences
https://jobs.qualcomm.com/public/jobDetails.xhtml?requisitionId=1960693
IDA 7.0 SP1 released with a lot of bugfixes
AMI on Intel’s BIOS end-of-life announcement
https://ami.com/en/tech-blog/intel-says-bye-to-bios-by-2020/
Click to access Brian_Richardson_Intel_Final.pdf
The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂
Intel seeks senior security researcher
[Hmm, I don’t understand Intel org chart, but I’ve never heard of the Advanced Security Research Team, sounds like it is under Security Center of Excellence, which is under Platform Engineering Group (PEG)? Not to be confused with Intel Advanced Threat Research, which went off with the MkAfee split.]
“The Platform Engineering Group (PEG) is responsible for the design, development, and production of system-on-a-chip (SoC) products that go into Intel’s next generation client and mobile platforms. […] Intel Security Center of Excellence’s […] we would like you to join us as a proud member of Intel’s Advanced Security Research Team. Through your deep vulnerability analysis and mitigation development expertise, you will influence the security of a variety of Hardware, Firmware, Software & Systems spanning a range of products including Devices, Cloud, Auto, IOT, AI, VR, Drones, and Networks. Responsibilities include the following: Own emerging threat analysis, gain insights & know-how of evolving attack techniques, predict and extrapolate attack trends ahead of its occurrence, develop robust counter measures and mitigation.[…]
* 5+ years of experience in the field of system security research and excel in exploring software and hardware techniques as a method of attack against targets within the computing systems.
* Experience with spanning security expertise over HW, SW and Firmware domains.
* Knowledge of computer architecture CPU, SoC, chipsets, BIOS, Firmware, Drivers, and others
[…]
* Strong network in security community CISSP and/or other security certifications
http://jobs.intel.com/ShowJob/Id/1426937/Sr.%20Security%20Researcher
Nyan-Load (and EFI-Example)
nyan-load:
have you ever wanted a moving nyan cat as your bootloader? of course! now you can. the rainbow and cat tail moves as of right now, and work is being done to add stars in the background.
nyan-load code is based on efi-example.
EFI-example: Self-contained minimal example of building an EFI application (under 64 bit Linux atm) without external build dependencies. This project was created to research the base for an EFI bootloader for the Haiku Operating System.
https://github.com/puckipedia/efi-example
https://github.com/ohnx/nyan-load
https://en.wikipedia.org/wiki/Nyan_Cat
EFIedit: efibootmgr wrapper to inspect and edit EFI boot entries
https://github.com/Juma7C9/Efiedit
“Efiedit is an efibootmgr wrapper to inspect and edit EFI boot entries. It extends efibootmgr adding the possibility to inspect the content of existing boot entries, and to read the option from a config file, enabling an easier managenment of boot option, in a bootloader-y fashion.”
Firmware Security 
You must be logged in to post a comment.