Language Selection

English French German Italian Portuguese Spanish

New Security Patches and New UEFI 'Secure' Boot Catastrophe

Filed under
Server
Security
  • Security updates for Thursday

    Security updates have been issued by Arch Linux (webkit2gtk), CentOS (GNOME, grub2, and kernel), Debian (firefox-esr, grub2, json-c, kdepim-runtime, libapache2-mod-auth-openidc, net-snmp, and xrdp), Gentoo (chromium and firefox), Mageia (podofo), openSUSE (knot and tomcat), Oracle (grub2, kernel, postgresql-jdbc, and python-pillow), Red Hat (firefox, grub2, kernel, and kernel-rt), SUSE (grub2), and Ubuntu (firefox, grub2, grub2-signed, and librsvg).

  • Grub2 updates for Red Hat systems are making some unbootable

    As reported in the comments on the Grub2 secure-boot vulnerabilities report, the updates for grub2 for RHEL 8 and CentOS 8 are making some systems unbootable. The boot problems are seemingly unrelated to whether the system has secure boot enabled. It may be worth waiting a bit for that to shake out.

  • Servers at risk from “BootHole” bug – what you need to know

    That’s our tongue-in-cheek name for a cybersecurity vulnerability that not only gets assigned an identifier like CVE-2020-10713, but also acquires an impressive name plus a jaunty logo (and even, in one intriguing case, a theme tune).

    This month’s bug with an impressive name (see what we did there?) is called BootHole, and its logo rather cheekily shows a boot with a worm sticking out of a hole in the toecap.

    The bad news is that this bug affects the integrity of bootup process itself, meaning that it provides a way for attackers to insert code that will run next time you restart your device, but during the insecure period after you turn on the power but before the operating system starts up.

    The good news for most of us is that it relies on a bug in a bootloader program known as GRUB, short for Grand Unified Boot Loader, which is rarely found on Windows or Mac computers.

  • Why the GRUB2 Secure Boot Flaw Doesn’t Affect Purism Computers

    To understand why this flaw does not affect Purism computers, it helps to understand why UEFI Secure Boot exists to begin with, and how it and the security exploit works. Attacks on the boot process are particularly nasty as they occur before the system’s kernel gets loaded. Attackers who have this ability can then compromise the kernel before it runs, allowing their attack to persist through reboots while also hiding from detection. UEFI Secure Boot is a technology that aims to protect against these kinds of attacks by signing boot loaders like GRUB2 with private keys controlled ultimately by Microsoft. UEFI Firmware on the computer contains the public certificate counterparts for those private keys. At boot time UEFI Secure Boot checks the signatures of the current GRUB2 executable and if they don’t match, it won’t allow the executable to run.

    If you’d like to understand the GRUB2 vulnerability in more detail, security journalist Dan Goodin has a great write-up at Ars Technica. In summary, an attacker can trigger a buffer overflow in GRUB2 as it parses the grub.cfg configuration file (this file contains settings for the GRUB2 menu including which kernels to load and what kernel options to use). This buffer overflow allows the attacker to modify GRUB2 code in memory and execute malicious code of their choice, bypassing the protection UEFI Secure Boot normally would have to prevent such an attack.

    Unfortunately, UEFI Secure Boot doesn’t extend its signature checks into configuration files like grub.cfg. This means you can change grub.cfg without triggering Secure Boot and the attack exploited that limitation to modify grub.cfg in a way that would then exploit the running GRUB2 binary after it had passed the signature check.

    Further complicating the response to this vulnerability is the fact that it’s not enough to patch GRUB2. Because the vulnerable GRUB2 binaries have already been signed by Microsoft’s certificate, an attacker could simply replace a patched GRUB2 with the previous, vulnerable version. Patching against this vulnerability means updating your UEFI firmware (typically using reflashing tools and firmware provided by your vendor) so that it can add the vulnerable GRUB2 binary signatures to its overall list of revoked signatures.

Red Hat Enterprise Linux runs into Boothole patch trouble

  • Red Hat Enterprise Linux runs into Boothole patch trouble

    Sometimes the cure really is worse than the disease. The recently revealed Boothole security problem with GRUB2 and Secure Boot can, theoretically, be used to attack Linux systems. In practice, the only vulnerable Linux systems are ones that have already been successfully breached by an attacker. Still, the potential for damage was there, so almost all enterprise Linux distributors have released patches. Unfortunately, for at least one -- Red Hat -- the fix has gone wrong.

    Many users are reporting that, after patching Red Hat Enterprise Linux (RHEL) 8.2, it has rendered their systems unbootable. The problem also appears to affect RHEL 7.x and 8.x computers as well. It seems, however, to be limited only to servers running on bare iron. RHEL virtual machines (VM)s, which don't deal with Secure Boot firmware, are working fine.

Debian explains

  • GRUB2 UEFI SecureBoot vulnerability - 'BootHole'

    UEFI Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded.

    SB works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When SB is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment.

    Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that are signed by Microsoft. Most modern systems will ship with SB enabled - they will not run any unsigned code by default, but it is possible to change the firmware configuration to either disable SB or to enrol extra signing keys.

    Debian, like many other Linux-based operating systems, uses a program called shim to extend that trust from the firmware to the other programs that we need to be secured during early boot: the GRUB2 bootloader, the Linux kernel and firmware update tools (fwupd and fwupdate).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Today in Techrights

Android Leftovers

LibreOffice 6.4.5 finally for Slackware 14.2

The Document Foundation recently released version 7.0.0 of their Libre Office suite of applications. The packages for Slackware-current can be found in my repository. But the situation for Slackware 14.2 used to be different – I got stuck after LibreOffice 6.2 because the newer source releases (6.3 and onwards) require versions of system software that our stable Slackware 14.2 platform does not offer. From time to time during the last year, when there was time and the build box was not compiling packages, I messed around with the libreoffice.SlackBuild script in futile attempts to compile recent versions of LibreOffice on Slackware 14.2. I failed all the time. Until last week. After I had uploaded the new KDE Plasma5 packages to ‘ktown‘, I had an epiphany and decided to use a new approach. What I did was: question all the historic stuff in the SlackBuild script that got added whenever I needed to work around compilation failures; and accept that the compilation needs newer versions of software than Slackware 14.2 offers. The first statement meant that I disabled patches and variable declarations that messed with compiler and linker; and for the second statement I stuck to a single guideline: the end product, if I were able to compile a package successfully, has to run out of the box on Slackware 14.2 without the need to update any of the core Slackware packages. Read more

Web Browsers: New Tor RC, Firefox/Mozilla Trouble, and Web Browsers Need to Stop

  • New release candidate: 0.4.4.4-rc

    There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.4.4-rc from the download page. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely in the coming weeks.

    Remember, this is a release candidate, not a a stable release: you should only run this if you'd like to find and report more bugs than usual.

  • Mozilla is dead

    If Mozilla wants to survive, the management will be fired with unearned compensation, the most important departments will be strengthened, products that nobody ordered will be discontinued and the organization will be limited to its core competence. Browser, email, security, adaptability and the fight for a free Internet. And they work with all their might to ensure that the products will become an integral part of everyday life and all operating systems.

    Three months. That’s all the time they have for a clear signal. After that, users have to make a decision. Unfortunately, it will probably only be something with chromium.

    Poor Internet.

  • Web browsers need to stop

    I call for an immediate and indefinite suspension of the addition of new developer-facing APIs to web browsers. Browser vendors need to start thinking about reducing scope and cutting features. WebUSB, WebBluetooth, WebXR, WebDRM WebMPAA WebBootlicking replacing User-Agent with Vendor-Agent cause let’s be honest with ourselves at this point “Encrypted Media Extensions” — this crap all needs to go. At some point you need to stop adding scope and start focusing on performance, efficiency, reliability, and security5 at the scope you already have.