• ‘BootHole’ attack impacts Windows and Linux

    Home » Forums » Cyber Security Information and Advisories » Code Red – Security/Privacy advisories » ‘BootHole’ attack impacts Windows and Linux

    Author
    Topic
    #2284017

    Looks like this impacts Windows, all Linux, and many OEM’s.

    ZDnet

     

    Details about a new vulnerability in a core component of the Secure Boot process have been published today.

    The vulnerability, codenamed BootHole, allows attackers to tamper with the boot-loading process that precedes starting up the actual operating system (OS).

    This process relies on components known as bootloaders that are responsible for loading the firmware of all computer hardware components on which the actual OS runs.

    BootHole is a vulnerability in GRUB2, one of today’s most popular bootloader components. Currently, GRUB2 is used as the primary bootloader for all major Linux distros, but it can also boot and is sometimes used for Windows, macOS, and BSD-based systems as well.

    Don't take yourself so seriously, no one else does 🙂
    All W10 Pro at 22H2,(2 Desktops, 1 Laptop).

    12 users thanked author for this post.
    Viewing 12 reply threads
    Author
    Replies
    • #2284027

      Which relates to kb4524244 being removed by MSFT back in february 2020.

      Info from https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

      Recommendations

      1. Right away, start monitoring the contents of the bootloader partition (EFI system partition). This will buy time for the rest of the process and help identify affected systems in your environment. For those who have deployed the Eclypsium solution, you can see this monitoring under the “MBR/Bootloader” component of a device.

      2. Continue to install OS updates as usual across desktops, laptops, servers, and appliances. Attackers can leverage privilege escalation flaws in the OS and applications to take advantage of this vulnerability so preventing them from gaining administrative level access to your systems is critical. Systems are still vulnerable after this, but it is a necessary first step. Once the revocation update is installed later, the old bootloader should stop working. This includes rescue disks, installers, enterprise gold images, virtual machines, or other bootable media.

      3. Test the revocation list update. Be sure to specifically test the same firmware versions and models that are used in the field. It may help to update to the latest firmware first in order to reduce the number of test cases.

      4. To close this vulnerability, you need to deploy the revocation update. Make sure that all bootable media has received OS updates first, roll it out slowly to only a small number of devices at a time, and incorporate lessons learned from testing as part of this process.

      5. Engage with your third-party vendors to validate they are aware of, and are addressing, this issue. They should provide you a response as to its applicability to the services/solutions they provide you as well as their plans for remediation of this high rated vulnerability.

      Eclypsium has powershell and bash scripts available which can be used to detect bootloaders that are being revoked by this dbxupdate.

      wow, seems like a potentially foul vulnerability, I wonder if removing the cmos battery for a long period would kill it off if infected, as the malware resides in separate places in the motherboard, or whether it would regenerate upon system start after the cmos battery is replaced?

      Windows - commercial by definition and now function...
      4 users thanked author for this post.
    • #2284048

      CADesertRat wrote: “… but it [GRUB 2] can also boot and is sometimes used for Windows, macOS, and BSD-based systems as well.

      In the case of Macs, this problem seems to affect only people that, for some reason, have to use GRUB2 that, I understand, is third-party software and, if so, not a component of the standard Mac’s bootstrapping system. If that is correct, then most Mac users, myself included, may never have a reason for using GRUB2 in their Macs. Am I correct? Thanks to anyone that clarifies this for me and other Mac users.

      Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

      MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
      Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
      macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

    • #2284051

      Well, just this minute, I got a Ubuntu patch update:

      GRUB is a portable, powerful bootloader. This version of GRUB is based on a cleaner design than its predecessors, and provides the following new features:

      – Scripting in grub.cfg using BASH-like syntax.
      – Support for modern partition maps such as GPT.
      – Modular generation of grub.cfg via update-grub. Packages providing GRUB
      add-ons can plug in their own script rules and trigger updates by invoking
      update-grub.
      – VESA-based graphical mode with background image support and complete 24-bit
      color set.
      – Support for extended charsets. Users can write UTF-8 text to their menu
      entries.
      This is a dependency package for a version of GRUB that has been built for use with the traditional PC/BIOS architecture. Installing this package indicates that this version of GRUB should be the active boot loader.

      all for :
      CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15706, CVE-2020-15707,CVE-2020-15705

      WoW that was quick! 😉

      grub2

      Windows - commercial by definition and now function...
      4 users thanked author for this post.
      • #2284208

        I received a GRUB security update yesterday (July 29, 2020) on Neon (Ubuntu 18.04 base). I didn’t know exactly what it was for, but I do now! Can’t beat the speed of a security update that arrives before the warning of the vulnerability.

        Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
        XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
        Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

        2 users thanked author for this post.
    • #2284063

      Forbes has interesting information on the possible impact of Boothole.

      My Linux Mint just got two updates – marked as software updates  (not security) and labelled as “medium” importance.

      grub2-1

      3 users thanked author for this post.
    • #2284067
      * _ ... _ *
      3 users thanked author for this post.
    • #2284183

      If you don’t run Linux / dual boot Windows with Linux, there is nothing for Windows users to be concerned about.

      cheers, Paul

    • #2284201

      Not true Paul, one only need admin access to install GRUB2 (much like to edit the config in Linux).

      • #2284210

        From my reading, it sounds like Paul’s right here. There can be non-Linux related reasons to use GRUB to boot on a system with Windows, but it’s not by any means common.

        If you mean that it would be possible to install GRUB (quietly, without alerting the user) specifically to bypass secure boot before chainloading Windows… well, that’s certainly not described in the ZDNet article, and I don’t know how feasible it is.

        If you’re not using secure boot, this does not affect you even if you are using GRUB, though it only means that the lowered security of bypassing secure boot with this exploit is the normal situation (with all that implies).

        Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
        XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
        Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

    • #2284213

      I am still trying to comprehend that.

      In addition to Linux systems, any system that uses Secure Boot with the standard Microsoft UEFI CA is vulnerable to this issue

      Sounds to me, that every device using UEFI SecureBoot is vulnerable, including Windows machines.

      Isnt MS Azure linux-based too? Does this mean something?

      Dell Latitude 3420, Intel Core i7 @ 2.8 GHz, 16GB RAM, W10 22H2 Enterprise

      HAL3000, AMD Athlon 200GE @ 3,4 GHz, 8GB RAM, Fedora 29

      PRUSA i3 MK3S+

      • #2285814

        For that to be true, it requires that a vulnerable, signed version of GRUB2 be installable into an existing system. As things stand, those are readily available from old installer images and such.

        Therefore fixing this will require revoking keys, so that the vulnerable versions stop being accepted by Secure Boot.

        And THAT might mean that old Windows installers and such also stop being accepted.

        1 user thanked author for this post.
    • #2284216

      I think the Windows side of this is related to WSL /WSL2
      (Windows Subsystem for Linux) which is an optional feature but, is required when installing any Linux distro using the MS Virtual Machine Platform.
      I expect 3rd party VM’s will also upgrade their applications eg: VMware, Oracle Virtualbox to mitigate the issue.

      Windows - commercial by definition and now function...
    • #2284224

      New flaw neuters Secure Boot, but there’s no reason to panic. Here’s why

      “But there are some major catches

      The severity of the vulnerability, however, is offset by a few things. First, the attacker must have either administrative rights over the computer or physical access to the machine. Administrator-level control is increasingly hard to gain on modern OSes because of major advances they’ve made to block exploits. Physical access may be easier during border crossings or similar moments when a user briefly loses physical possession of a computer. But the requirement is steep in most other scenarios, making it unlikely many users are affected. What’s more, physical possession greatly restricts the scalability of attacks.

      Two other factors that make Boot Hole less scary: attackers who already have administrative or physical control of a computer already have plenty of other ways to infect it with advanced and stealthy malware. Furthermore, there are several other known techniques for bypassing Secure Boot.”

      I’m not overly concerned.  I always run as a Standard user, and “Ain’t nobody here but us chickens.”  No one else has physical access.

      Always create a fresh drive image before making system changes/Windows updates; you may need to start over!
      We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.
      We were all once "Average Users".

      3 users thanked author for this post.
    • #2284655

      BootHole fixes causing boot problems across multiple Linux distros

      ZDnet

       

       

      As many experts anticipated, patches for the BootHole vulnerability in the GRUB2 bootloader that is used by all major Linux distributions are causing problems and preventing some users from booting their systems.

      While the list of affected distros only included Red Hat yesterday, it has now expanded to include users of Ubuntu [1, 2, 3], Debian, CentOS [1, 2], and Fedora.

      Microsoft security researcher Kevin Beaumont, also reports issues in cloud environments, namely where “a bug in cloud-init is causing problems across major cloud providers with Grub, such as Digital Ocean and Azure, having the same impact: patched systems then fail to boot.”

      Don't take yourself so seriously, no one else does 🙂
      All W10 Pro at 22H2,(2 Desktops, 1 Laptop).

      1 user thanked author for this post.
    • #2285653

      To my knowledge, Macs don’t use GRUB to boot. They boot over EFI, and Macs with T2 Chips also have Secure Boot enabled that can even disallow booting from external media.

      Plus Macs can have a firmware password set on them requiring a password before booting from any other drive besides the macOS Boot Drive (I can write an article on this if need be).

      This would mainly affect Macs with a dual boot of Linux which usually doesn’t occur since most people who happen to run Linux on a Mac use a VM instead.

      Nathan Parker

      2 users thanked author for this post.
    • #2288307

      Could someone please explain in terms understandable to this non-tech user how much of a threat this invader presents, and what if any action I should take?  Running dual boot- Mint Mate 19.2 and Win7 on two machines in a home environment.  Internet access disabled in Win7.  It is our practice to install all Linux updates when presented.

      3 users thanked author for this post.
      • #2288330

        Running Linux / dual booting Windows means you use grub and are vulnerable.

        The exploit requires admin / root access. If you run Linux as a non-root user you are OK. If you run Windows as non-admin you should be OK.

        I see no need to rush to patch if you are a non-root user and don’t download apps, but patching sooner is better than later with this one.

        cheers, Paul

        1 user thanked author for this post.
        • #2288346

          You’re vulnerable if you use GRUB and secure boot.

          If you do not use secure boot, you are no more vulnerable than before. The vulnerability is to defeat the effect of secure boot, but if you’re not using it in the first place, you’re already at the level of security that the exploit would bring you to.

          If you’re using Windows 7 on the machines in question, that means the PC is either not secure boot capable or that secure boot is not enabled, since Windows 7 does not work with secure boot. Secure boot requires UEFI, so any BIOS PC won’t have it, and some early UEFI PCs or motherboards (like my desktop) that were typically released with Windows 7 can’t perform a secure boot either. Microsoft started requiring OEMs to ship PCs with secure boot enabled starting with Windows 8.

          I’ve read that there may be some tricks you can use to get secure boot to work with 7, but that’s clearly not what we are talking about here.

          Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
          XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
          Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

          3 users thanked author for this post.
          • #2288351

            We are not using Win7- originally when adding Mint, just chose the dual boot option to keep Win7 available as a starting point in case I fouled up the Mint install and needed Internet access to try again (BTW, that didn’t happen).  On the few instances that we need a file from 7, we get to it via the Mint directory.

            1 user thanked author for this post.
          • #2288562

            I’ve read that there may be some tricks you can use to get secure boot to work with 7, but that’s clearly not what we are talking about here.

            … Are you sure about that? Because that’s exactly the kind of thing the Grub2 shim was used for.

            As in, fixing this issue might cause at least some of those tricks to stop working.

    Viewing 12 reply threads
    Reply To: ‘BootHole’ attack impacts Windows and Linux

    You can use BBCodes to format your content.
    Your account can't use all available BBCodes, they will be stripped before saving.

    Your information: