Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Microsoft Security IT

Microsoft Patches Windows To Eliminate Secure Boot Bypass Threat (arstechnica.com) 39

Microsoft has patched a Windows vulnerability that allowed attackers to bypass Secure Boot, a critical defense against firmware infections, the company said. The flaw, tracked as CVE-2024-7344, affected Windows devices for at least seven months. Security researcher Martin Smolar discovered the vulnerability in a signed UEFI application within system recovery software from seven vendors, including Howyar.

The application, reloader.efi, circumvented standard security checks through a custom PE loader. Administrative attackers could exploit the vulnerability to install malicious firmware that persists even after disk reformatting. Microsoft revoked the application's digital signature, though the vulnerability's impact on Linux systems remains unclear.
This discussion has been archived. No new comments can be posted.

Microsoft Patches Windows To Eliminate Secure Boot Bypass Threat

Comments Filter:
  • by Gavino ( 560149 ) on Thursday January 16, 2025 @01:58PM (#65094155)
    The term “secure” in “secure boot” should probably also be revoked. This kind of stuff gives me zero confidence in what Microsoft have essentially forced on the industry. It seems to be about as secure as 64-bit WEP. I.e. not very.
    • by Anonymous Coward on Thursday January 16, 2025 @02:06PM (#65094175)

      The ONLY thing secure boot secures is Microsoft another revenue stream. Nothing is proven about anything other than someone paid M$ to sign some code.

      It is literally just cartel behavior.

      • Re: (Score:2, Informative)

        by Anonymous Coward
        Secure Boot is NOT MS specific.
    • by 93 Escort Wagon ( 326346 ) on Thursday January 16, 2025 @02:14PM (#65094197)

      Yeah, in all seriousness - I'm kind of flabbergasted by this. The fact that it's even possible for a Windows-based exploit to bypass "Secure Boot" tells us that Secure Boot is more or less a scam.

      • Yeah, in all seriousness - I'm kind of flabbergasted by this. The fact that it's even possible for a Windows-based exploit to bypass "Secure Boot" tells us that Secure Boot is more or less a scam.

        It's not a bug - it's a feature. How else are the bad guys going to get the access they need?

      • by PsychoSlashDot ( 207849 ) on Thursday January 16, 2025 @05:25PM (#65094621)

        Yeah, in all seriousness - I'm kind of flabbergasted by this. The fact that it's even possible for a Windows-based exploit to bypass "Secure Boot" tells us that Secure Boot is more or less a scam.

        To be fair, I don't think it's SecureBoot's job to make your OS secure; it's the OS's job.

        I haven't read about this in ages, but I think the idea is that your OS leverages SecureBoot to confirm that its bootloader hasn't been modifed. A flaw in the OS, at the line where it says "if SecureBoot.reportsissue = $true then shut back down" is what I think is going on, and is not indicative that SecureBoot is a scam. It's indicative that programmers continue to get even ultra-critical stuff wrong from time to time.

        There's always been a lot of FUD about SecureBoot (and TPM as well) but so far none of the common conspiracy theories have come true. It's all been - like this story - someone getting it wrong.

        We live in a world where weird stuff like watching voltage levels lets you infer cache contents and whatnot. Security is hard.

        • My basic point (or opinion, if you prefer) is - if something at the OS layer has this level of access to Secure Boot, then we're back to "your computer is only as secure as your OS". Secure Boot can't and shouldn't be considered a trustworthy gatekeeper for any bootloader if it's not immune to bad behavior from the running OS.

          The relationship between Secure Boot and any OS should have been designed to flow in one direction only.

          • by Ed Tice ( 3732157 ) on Thursday January 16, 2025 @09:01PM (#65095023)
            If anybody had read TFA before posting, they would see that what happened was that malware was somehow introduced into a custom firmware that Microsoft signed. This would seem to affect only those who are using non-vendor UEFI. What Microsoft did was revoke the signature of the flawed implementations. This has nothing to do with Microsoft or Secure Boot. I'm curious if those who so quickly and effusively blamed Microsoft are going to be as enthusiastic in their retractions or if they will double down.
            • Thank you - well said and saved me the trouble. It wasn't a hard article to read, for people who can (read) :-)
      • by kmoser ( 1469707 )
        "Secure" in this context is just a marketing term, not an actual description of the product.
        • by gweihir ( 88907 )

          Oh, it is. But the purpose of the "security" is to secure Digital Restriction Management against _you_, the user, so that you cannot copy media the content mafia does not want you to copy. Nothing to do with your security. MS does not care about securing your machine or your data against attacks.

      • by gweihir ( 88907 )

        The fact that it's even possible for a Windows-based exploit to bypass "Secure Boot" tells us that Secure Boot is more or less a scam.

        That has been clear for a long time. The claim to be protecting you is simply a direct lie. This is all about protecting the computer against you to have better control and better Digital Restriction Management.

    • by gweihir ( 88907 )

      This is Digital Restriction Management, nothing else. No connection with protecting the user or the computer, MS does not care about that or about you.

      Same likely for the insane TPM requirement in Win11 (in addition to boost PC sales by making perfectly fine PCs unusable for many people).

  • The example (Score:3, Insightful)

    by Ol Olsoc ( 1175323 ) on Thursday January 16, 2025 @02:19PM (#65094207)
    Of why Windows is inherently not secure. If the Standard OS, the largest installed User base, the utter need for users to work on anything other than Office 365....

    Whose very claimed Secure boot is not at all secure.

    It is difficult to have much sympathy for it's users who still use it after Secure boot is not secure. Such a weak system means that either the users and companies that continues to use windows are either brain dead, or do not care about security at all.

    Enjoy getting Pwned,

    • Re:The example (Score:4, Interesting)

      by 93 Escort Wagon ( 326346 ) on Thursday January 16, 2025 @03:06PM (#65094311)

      Yeah, I've been (historically) jumping through all the extra hoops to keep Secure Boot enabled on our Linux servers and (especially) student workstations, taking the extra steps to get GPU drivers working with it, etc. etc. Now I'm wondering why I've bothered.

      It seems to me that, at least on those machines where other people have physical access (and can log in), this exploit tells me Secure Boot isn't really making them any more secure.

      If someone wants to argue the other way, I'll certainly be interested to listen.

      • Yeah, I've been (historically) jumping through all the extra hoops to keep Secure Boot enabled on our Linux servers and (especially) student workstations, taking the extra steps to get GPU drivers working with it, etc. etc. Now I'm wondering why I've bothered.

        It seems to me that, at least on those machines where other people have physical access (and can log in), this exploit tells me Secure Boot isn't really making them any more secure.

        If someone wants to argue the other way, I'll certainly be interested to listen.

        And just imagine the other surprises Windows will serve us with. Some vulnerabilities can happen, sure. But this is pretty egregious.

      • Did you read TFA or even TFS? Yeah, if you install third-party UEFI with vulnerabilities, SecureBoot can be compromised. You know, maybe don't do that. And set a UEFI password so that others can't easily install third-party UEFI. Or did you not even read before posting? Not that you're the only one. But apparently people don't read or understand before moderating either. SMH
        • by vbdasc ( 146051 )

          Yeah, if you install third-party UEFI with vulnerabilities, SecureBoot can be compromised. You know, maybe don't do that.

          How do I know that a third-party "UEFI" (sic) has vulnerabilities? Do I put it through an anti-malware program? Do I disassemble it? That particular "UEFI" had a valid Microsoft signature. If this doesn't GUARANTEE that there are no vulnerabilities, I don't know what does.

          Oh wait, this is Microsoft, so their signature actually means and guarantees little. Not to mention that they signed the linux-booting shim, which, technically speaking, is a secure boot vulnerability by itself.

          This secure boot crap should

          • A signature does not guarantee the lack of vulnerabilities and never has. A signature authenticates the source. It means that you are installing what you think you are installing. This applies to applications as well. The fact that you would make such a statement indicates that you really haven't bothered to learn anything about what these technologies are and why they exist. It validates the integrity of the boot process. That's a necessary step in securing systems but not a sufficient one. As far as
            • by vbdasc ( 146051 )

              No, it's you who didn't understand what I actually asked about. So I'll ask again.

              How do I know that a third-party "UEFI" has vulnerabilities? (especially if it comes as part of software from a good-reputation vendor whom you trust)

              In an earlier comment, you gave a good advice to not install "UEFI"s with vulnerabilities, and I actually agree. Now please advise how to achieve that.

              A signature authenticates the source. It means that you are installing what you think you are installing

              It's debatable that this is the only purpose of a software signature, especially in the case of signed "UEFI"s. But anyway, it's

              • It's not debatable that this is the only purpose of a software signature. The purpose of signing is to guarantee authenticity. And that's the only purpose. Any discussion to the contrary is equivalent to debating whether the sun rises int he east.

                The way you can avoid installing third-party UEFI with vulnerability is to avoid installing third-party UEFI! But even the vendor-supplied UEFI can have defects.

                It's not year clear whether the defects in these third-party UEFI were due to (a) the vendor m

                • by vbdasc ( 146051 )

                  It's not debatable that this is the only purpose of a software signature. The purpose of signing is to guarantee authenticity. And that's the only purpose. Any discussion to the contrary is equivalent to debating whether the sun rises int he east.

                  Some software signature providers vet the behavior of the software they sign. This directly contradicts your words. However, as I wrote above, this is not relevant here.

                  The way you can avoid installing third-party UEFI with vulnerability is to avoid installing third-party UEFI! But even the vendor-supplied UEFI can have defects. It's not year clear whether the defects in these third-party UEFI were due to (a) the vendor making a mistake, (b) the vendor intentionally introducing weaknesses, or (c) the vendor was infiltrated and the defective code placed without their knowledge.

                  Yes, exactly! So, your earlier words

                  Yeah, if you install third-party UEFI with vulnerabilities, SecureBoot can be compromised.

                  might mislead people, and it should be replaced with "SecureBoot can be compromised without your knowledge and despite your efforts, and the less you touch the UEFI payloads, the better". Which was my intention since the beginning of this discussion.

                  • by vbdasc ( 146051 )

                    P.S. To use more precise words, a Microsoft signature on an UEFI payload serves these purposes:

                    First, to inform the user that the exactly same UEFI payload was submitted to Microsoft, and Microsoft guarantees that what they signed and the user's copy are binary identical,

                    Second, to inform the user that this UEFI payload's origin is the same as what it claims,

                    Third, to inform the user that this UEFI payload's behavior has been tested by Microsoft and deviations from the set guidelines that may endanger secur

                  • You are confusing the requirements Microsoft places on the vendor with the guarantees provided to the user. The list of requirements to get UEFI signed is quite extensive. The goal is to not sign UEFI from vendors who aren't making an honest effort to preserve the value of Secure Boot. Most well known signers do a combination of their own rudimentary security checks plus require attestation from the vendor. For certain classes of signed binaries, there will be additional requirements (such drivers imple
      • by gweihir ( 88907 )

        Secure boot is about making Digital Restriction Management more secure, not about protecting the user or the machine. I routinely just turn it off. An attacker with physical access can basically do anything anyways, "secure" boot or not.

    • Of why Windows is inherently not secure. If the Standard OS, the largest installed User base, the utter need for users to work on anything other than Office 365....

      Whose very claimed Secure boot is not at all secure.

      It is difficult to have much sympathy for it's users who still use it after Secure boot is not secure. Such a weak system means that either the users and companies that continues to use windows are either brain dead, or do not care about security at all.

      Enjoy getting Pwned,

      I mean - devil's advocate here - not having the ability to leverage the feature doesn't make an OS more secure.

      That doesn't excuse Microsoft here at all. This code should've been vetted and checked so many times there's no statistical possibility of vulnerability. The foundation must be reliable before you build walls atop it.

  • Sure you get a trusted flag with secure boot, but when the trusted code betrays you or gets backdoored you're screwed. Revoking the key only closes the barn door afterwards. Same with all DRM and notarized code.
  • If MS had just integrated SystemD this would have never happened. We all know SystemD can detect and remove malware, bloatware, and any fungus among us.

    • I'm sure WindowsD is somewhere in the planning pipeline!

      • At this rate, the SystemD project will probably implement it in several years. The boot process will be:

        systemd loads Linux kernel -> systemd starts systemd-init -> systemd-init loads Windows kernel -> user cries
        • by gweihir ( 88907 )

          Probably. Still happily systemd free here. That atrocity will not make it onto my machines.

  • by SoonerPet ( 893902 ) on Thursday January 16, 2025 @09:09PM (#65095041)
    You mean some people leave this enabled? It’s literally the first thing I disable on all systems so I can actually install an OS properly.
    • by gweihir ( 88907 )

      Indeed. The only attack vector it supposedly protects against (but does not) is really physical access. If you can compromise a machine, you really do not need to persist that in the boot-process, that is just icing on the top. But in actual reality, it "secure" boot just there to support Digital Restriction Management, and hence its real purpose is to stand in the user's way.

  • I can't believe previous posters have tried to say it's not really Microsoft's fault. Fanboys are hopeless.

    From the article:
    reloader.efi, which was digitally signed after somehow passing Microsoft’s internal review process for third-party UEFI apps

    Microsoft failed in their QA and wrongly signed a malicious file.
    How many other "Secure" Boot modules have been wrongly signed?
    Has Microsoft even properly identified the person / company that submitted this malicious file?

    "Secure" Boot's primary pur
  • Why do they say Windows "devices" as if Windows runs on anything besides a computer?

Always draw your curves, then plot your reading.

Working...