Richard Hughes

Nowadays, it’s difficult to find any hardware vendor who develops all the components present in its products. Many of these components, including firmware, are outsourced to ODMs. As a result, this limits the ability of hardware vendors to have complete control over their hardware products. In addition to creating extra supply chain security risks, this also produces security gaps in the threat modeling process. Through this research, ​we wanted to raise awareness about the risks in the firmware supply chain and the complexity of fixing known vulnerabilities. The firmware patch cycles last typically around 6-9 months (sometimes even longer) due to the complexity of the firmware supply chain and the lack of a uniform patching process. The 1-day and n-day vulnerabilities in many cases have a large impact on enterprises since the latest firmware update wasn’t installed or the device vendor had not released a patch yet. Each vendor follows their own patch cycle. Even known issues may not be patched until the next firmware update is available. We decided to build an open-source framework to identify known vulnerabilities in the context of UEFI specifics, classify them based on their impact and detect across the firmware ecosystem with the help of the LVFS project. We will be sharing our approach as well as the tooling we have created to help industry identify the problems and get patched. Workshop outline: * Why it's important to get patched in time, and why your EDR won't help you with compromised firmware? * The uefi_r2 scanner details internals (https://github.com/binarly-io/uefi_r2) * How semantic code annotations work to bring UEFI codentext for code analysis * How to scale uefi_r2 scanner in enterprise infrastructure? * Deep dive into FwHunt rules format * What is the difference between detecting new and known issues? * How does the FwHunt detection work on different layers PEI/DXE/SMM? * LVFS integration of uefi_r2 and FwHunt * How patch the industry deal with the help of LVFS? * Future plans and upcoming updates for FwHunt technology

Other people: Kai Michaelis Alex Matrosov Alex Ermolov

Nowadays, it’s difficult to find any hardware vendor who develops all the components present in its products. Many of these components, including firmware, are outsourced to ODMs. As a result, this limits the ability of hardware vendors to have complete control over their hardware products. In addition to creating extra supply chain security risks, this also produces security gaps in the threat modeling process. Through this research, ​we wanted to raise awareness about the risks in the firmware supply chain and the complexity of fixing known vulnerabilities. The firmware patch cycles last typically around 6-9 months (sometimes even longer) due to the complexity of the firmware supply chain and the lack of a uniform patching process. The 1-day and n-day vulnerabilities in many cases have a large impact on enterprises since the latest firmware update wasn’t installed or the device vendor had not released a patch yet. Each vendor follows their own patch cycle. Even known issues may not be patched until the next firmware update is available. We decided to build an open-source framework to identify known vulnerabilities in the context of UEFI specifics, classify them based on their impact and detect across the firmware ecosystem with the help of the LVFS project. We will be sharing our approach as well as the tooling we have created to help industry identify the problems and get patched.

Other people: Kai Michaelis Alex Matrosov Alex Ermolov

Over the last year we've grown the LVFS ecosystem over 100%. Recently we hit 2 million firmware downloads per month for the first time. There are now over 3000 firmware files available on the LVFS, with over 100 vendors using 50 different protocols. We're clearly winning. I wanted a chance to talk about the latest things that you can do on the LVFS and with fwupd. * We have more vendors using HSI for real use cases * We now have a complete Redfish implementation working with tier-1 OEM hardware. * Signed LVFS firmware reports for hardware certification. * Scanning EFI binaries on upload for common security problems. * Soft requirements in the form of recommends and requires. * A global progressbar, to be used for instance in something like ChromeOS. * Bidirectional support for VINCE, allowing us to work effectively with CERT. * Mirroring to IPFS for firmware updates from behind less-than-great firewalls. * Adding support for CapsuleOnDisk and chainloading from grub, and more generally FreeBSD. Time will be left for some questions and feedback.

The LVFS is a website which allows hardware vendors to upload firmware updates. This site is used by all major Linux distributions to securely provide metadata for clients such as fwupdmgr and GNOME Software. There is no charge to vendors for the hosting or distribution of content, and both the website and client-side mechanism are free software. Since its inception nearly three years ago, the LVFS has shipped over 7 million firmware files to Linux users, and now updates over 500,000 devices a month. Over the last few years the LVFS has grown from a hobby project with a monthly budget of $22 to a supported project managed by the Linux Foundation. Using the power of open source, reverse engineering and determination we’ve convinced Dell, Logitech, Lenovo, HP (and dozens more vendors) to ship both free and proprietary firmware to Linux users, greatly improving the security of all of our hardware. The LVFS is so ingrained into our ecosystem that increasingly big companies like Google and government departments are requiring hardware to be supported by the LVFS before purchases are approved. Dell even requires all hardware suppliers to use the LVFS too. Far from being just a giant FTP archive of blobs, the LVFS actually validates and checks the uploaded firmware using tools like CHIPSEC and MEA for common issues. This ensures that firmware problems are caught before being sent to millions of computers. With this analysis, we can also make sure the vendors include all the security issues fixed in the update description without accidentally missing anything out. Users can also provide optional automated and anonymous success/failure reports back to the vendor, so many real-world problems can be quickly identified. This talk will cover some of the history of LVFS, and detail how we got to where we are today. I’ll show the workflow for an OEM or ODM, and also explain how the automated tests work. They’ll be lots of screenshots and not much writing.