BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • mppix
    Senior Member
    • Jan 2020
    • 828

    #11
    Surprise, GRUB OS has security issues..
    If only we had simple&effective alternatives.

    Comment

    • wswartzendruber
      Senior Member
      • Aug 2008
      • 531

      #12
      Originally posted by cl333r View Post
      lol, but why?
      Cocaine, specifically. The language moves fast, but not necessarily with attention to detail. An example of this was the Error trait being unsuitable for use (by the failure crate) until Error::cause was deprecated for Error::source. It was mentioned in the GitHub issue that this was a simple oversight.

      Comment

      • ssokolow
        Senior Member
        • Nov 2013
        • 5129

        #13
        Originally posted by wswartzendruber View Post
        Cocaine, specifically. The language moves fast, but not necessarily with attention to detail. An example of this was the Error trait being unsuitable for use (by the failure crate) until Error::cause was deprecated for Error::source. It was mentioned in the GitHub issue that this was a simple oversight.
        Because it was something that slipped through the cracks back in 2015 during the rush to get everything prepared for the 1.0 release and its API-stability promise. I was there at the time. It was very busy and I was quite surprised how little went wrong.

        Comment

        • wswartzendruber
          Senior Member
          • Aug 2008
          • 531

          #14
          Originally posted by ssokolow View Post

          Because it was something that slipped through the cracks back in 2015 during the rush to get everything prepared for the 1.0 release and its API-stability promise. I was there at the time. It was very busy and I was quite surprised how little went wrong.
          What drove the sense of urgency?

          Comment

          • stormcrow
            Senior Member
            • Jul 2017
            • 1524

            #15
            After reading through the disclosures, this really isn't as big a problem as some people in the tech press are making out. This requires someone to already have administrative and/or hardware access to pull this off. The only people that have access to grub.cfg in any sane configuration is root. That being the case, it's already possible to disable secure boot entirely in many systems via various mechanisms. Such a person can already insert malicious modules, divers, boot kits, etc. Naturally, you can have a potential chain of vulnerabilities in which this plays one part of that chain, but that would have to be a very targeted attack for a known target that has known versions of vulnerable software that have yet to be patched.

            Certainly Rust would likely have prevented this particular vulnerability since it seems to be a classic buffer overflow attack on a problematic case: arbitrary text parsers. That said, UEFI doesn't actually need Grub to boot a kernel any more. We might consider ditching Grub entirely, which has been an Achilles heel in the Linux boot process for ages. You can argue endlessly about Rust v. C (or any other such language), but the fundamental problem would be solved by having a less complex boot chain for Linux to begin with.

            Comment

            • cl333r
              Senior Member
              • Oct 2009
              • 2311

              #16
              Originally posted by wswartzendruber View Post
              Cocaine, specifically. The language moves fast, but not necessarily with attention to detail. An example of this was the Error trait being unsuitable for use (by the failure crate) until Error::cause was deprecated for Error::source. It was mentioned in the GitHub issue that this was a simple oversight.
              Ok that's an oversight, but imho doesn't yet make them drug junkies, any more serious issues?

              To me the biggest annoyance is the myriad of types because of memory management, like &MyClass, Rc<MyClass>, Rf<RefCell<MyClass>>, RefCell<Rc<MyClass>>, Box<MyClass>, "cow" stuff, and other, and because of this you constantly have to deal with shitty decisions of unwrapping, wrapping or otherwise disguising your variable to match the function's parameter type.

              Comment

              • wswartzendruber
                Senior Member
                • Aug 2008
                • 531

                #17
                Originally posted by cl333r View Post

                Ok that's an oversight, but imho doesn't yet make them drug junkies, any more serious issues?

                To me the biggest annoyance is the myriad of types because of memory management, like &MyClass, Rc<MyClass>, Rf<RefCell<MyClass>>, RefCell<Rc<MyClass>>, Box<MyClass>, "cow" stuff, and other, and because of this you constantly have to deal with shitty decisions of unwrapping, wrapping or otherwise disguising your variable to match the function's parameter type.
                The language, to me, has always had this aura of being wound up and in a really big hurry. But for what?

                Comment

                • cl333r
                  Senior Member
                  • Oct 2009
                  • 2311

                  #18
                  Originally posted by wswartzendruber View Post

                  The language, to me, has always had this aura of being wound up and in a really big hurry. But for what?
                  Like the "fat enums" in Rust - it's a language of trade-offs, but these trade-offs IRL tend to be a lot more annoying than the documentation admits.
                  I was often thinking - just give me a pointer free of the borrow checker and the code would be a lot cleaner and easier to read.

                  Comment

                  • cl333r
                    Senior Member
                    • Oct 2009
                    • 2311

                    #19
                    Anyway, am I the only one who finds the title of this article a bit perv?

                    Comment

                    • kaprikawn
                      Senior Member
                      • Jan 2013
                      • 834

                      #20
                      Originally posted by stormcrow View Post
                      After reading through the disclosures, this really isn't as big a problem as some people in the tech press are making out. This requires someone to already have administrative and/or hardware access to pull this off. The only people that have access to grub.cfg in any sane configuration is root. That being the case, it's already possible to disable secure boot entirely in many systems via various mechanisms. Such a person can already insert malicious modules, divers, boot kits, etc. Naturally, you can have a potential chain of vulnerabilities in which this plays one part of that chain, but that would have to be a very targeted attack for a known target that has known versions of vulnerable software that have yet to be patched.

                      Certainly Rust would likely have prevented this particular vulnerability since it seems to be a classic buffer overflow attack on a problematic case: arbitrary text parsers. That said, UEFI doesn't actually need Grub to boot a kernel any more. We might consider ditching Grub entirely, which has been an Achilles heel in the Linux boot process for ages. You can argue endlessly about Rust v. C (or any other such language), but the fundamental problem would be solved by having a less complex boot chain for Linux to begin with.
                      +1

                      This isn't really a big issue...shock horror...a program has a bug! Big deal, they'll patch it and that will be that. Yes, Rust would have prevented this bug, but that's not necessarily a reason to rewrite Grub in Rust.

                      But that doesn't change the fact that Grub is a bloated mess. I frequent some sub reddits and it's evident that noobs almost always choose Grub when they've got a choice and don't ask for advice first. That's sad to see, but not surprising. Grub seems synonymous with Linux bootloaders despite being really bad. Going with rEFInd, systemd-boot or an EFI stub solution is almost always the better choice unless you've got some encryption setup that those don't support.

                      Comment

                      Working...
                      X