Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security Linux

0-Day GRUB2 Authentication Bypass Hits Linux (hmarco.org) 144

prisoninmate writes: A zero-day security flaw was discovered by developers Ismael Ripoll and Hector Marco in the upstream GRUB2 packages. GRUB2 did not correctly handle the backspace key when the bootloader was configured to use password protected authentication, thus allowing a local attacker to bypass GRUB's password protection. Versions from 1.98 (December, 2009) to 2.02 (December, 2015) are affected. At the moment, it looks like only a few distributions received the patched GRUB2 versions, including Ubuntu, Debian (Squeeze LTS only) and Red Hat Enterprise Linux 7.
This discussion has been archived. No new comments can be posted.

0-Day GRUB2 Authentication Bypass Hits Linux

Comments Filter:
  • Well Slackware is immune.

    Seriously how can a bug like this hang around as basic input validation is something that should be done.
    • by Viol8 ( 599362 ) on Wednesday December 16, 2015 @08:59AM (#51128879) Homepage

      Sadly slackware also appears to be slowly winding down. Sure its still being updated on an ad hoc package by package basis, by there hasn't been a full distro release for 2.5 years now. Thats not a good sign.

      • The natural migration from Slackware is to a BSD. I migrated from Slackware to NetBSD in 1999.

        • by Viol8 ( 599362 )

          Only superficially. When you get into the guts of administering the OS's then slackware is a lot closer to other linuxes than it is *BSD. Also the BSDs suffer from a lack of support. You might find that a linux program compiles from source on *BSD but often you'll find it doesn't without hacking it around a bit. Also the linux emulation layer - whatever its called - on BSD I always found a bit flaky.

          • Have you used a BSD since 1999? The ports system takes a bit of getting used to, but it works more than fine. But it's a server distro, I wouldn't dream of using any of them as a desktop OS though, but that's not what they're designed to do...

            • by Viol8 ( 599362 )

              It has been a while since I've used FreeBSD, I liked it, but as you say, its not a desktop OS so I stayed with linux.

            • NetBSD isn't really a server distro. It's the most general-purpose of the three main BSD's. The point in NetBSD is portability. Portability squeezes warts and bugs out of software that is coded too close to a particular architecture. When you download the source code for NetBSD, you're downloading the source for every architecture it runs on. With Linux it's typical that every 'distribution' is more or less tweaked to a particular architecture.

              And anyway, my comment about NetBSD being similar to Slackw

      • by DarkOx ( 621550 ) on Wednesday December 16, 2015 @09:11AM (#51128953) Journal

        Slackware is not winding down. There has not been a release because there has been little reason for one. With so much in flux Systemd, X/Wayland, GCC 5 stabilizing, and XFCE Slackware's 2nd of 2 DE's having only recently itself having a major release 14.1 has aged well. I think figuring out where udev/eudev were going also has held things up a bit.

        The changelog has been very active the past couple months. Patrick is making noise about 'betas' etc and the other developers like Robby and Eric are also hinting. A new release is coming.

        What you have to realize about Slackware is, releases are not done for their own sake. They done for the sake of major changes and improvements. Slackware only implements major changes / forklifts when its clear they won't be walking back those changes or replacing them again with something else in the near future. Slackware really takes stability and consistency very very seriously.

        The 'faster' thing move in the Linux ecosystem the longer the Slackware team has to wait for the dust to settle.

        • by Viol8 ( 599362 )

          "little reason for one"

          Seriously? The rate hardware changes these days theres a good chance the base release from 2013 won't boot on an up to date PC and if it does it might not be able to run the network hardware. In which case how exactly you do you expect someone to update it to current?

          • Why would it not boot?
            • by wbo ( 1172247 )

              Why would it not boot?

              Because many distributions have trouble booting via UEFI and more and more systems are shipping without legacy/MBR boot support and can only boot via UEFI.

              UEFI brings some nice improvements but motherboard manufactures typically only test with Windows and good UEFI support hasn't been a high priority until very recently for many Linux distributions.

              • by Anonymous Coward

                From Slackware 14.1 release notes:

                One of the big changes in Slackware 14.1 is support for systems
                running UEFI firmware (x86_64 Slackware edition only). We've added
                several new packages for UEFI, including elilo, GRUB 2, and efibootmgr,
                and all of the installation media supports booting under UEFI, as do
                the USB boot sticks generated during installation. At this point
                there is no support for running the system under Secure Boot, but a
                dedicated user could add their own Machine Owner Key, sign their
                kernels, modules, and bootloader, and then use shim to start the
                bootloader. We'll be looking into adding support for this in the
                next development cycle. Documentation for installing on UEFI machines
                is provided in a README_UEFI.TXT found in the top-level Slackware
                directory.

                Slackware ISO images (both the ones available online as well as
                the discs sent out from the Slackware store) have been processed using
                isohybrid. This allows them to be written to a USB stick, which can
                then be booted and used as the install source. This works on machines
                running both regular BIOS as well as UEFI.

              • by DarkOx ( 621550 )

                Its a good thing the current release 14.1 has UEFI support already.

          • Pure BS. I'm running fedora23 on a core 2 duo I built in 2007 with absolutely no problems. Even upgraded it with dnf system-upgrade without trouble.

      • Slackware is close to a new release ftp://ftp.osuosl.org/pub/slack... [osuosl.org].
        It just has taken longer than usual because upstream is in great turmoil and some hard decisions needed to be made regarding:
        ConsoleKit/systemd (consolekit2), udev/systemd (eudev) and KDE (probably still KDE4).
      • by mishehu ( 712452 )
        Obviously you don't follow slackware-current . I just installed that recently, as I'm an old timer, and -current doesn't skeer me. gcc 5.2.0 as of a couple weeks ago...
    • Seriously how can a bug like this hang around as basic input validation is something that should be done.

      For some strange reason folks these days insist that bloated high level languages like C/C++ are a good choice of language for real low level problems, leading to bootloader designs the defy explanation, because the developers suited to making a high level language work in this instance are not the typical developers that have to deal with unconstrained input.

      In car analogy terms, its what you get when you hire a car mechanic to design an oil tanker.

      • by Viol8 ( 599362 )

        C was designed in the 1970s specifically as a language to replace assembler for low level development and even today almost all OS kernels including linux, windows and OS/X are written in it. Buy a ticket on the clue train when you get a chance.

        • C was designed in the 1970s...

          Yes.

          ... specifically as a language to replace assembler for low level development

          No.

          The C crowd has been claiming this for awhile, but not since the 70's. It wasn't until the 90's that the C crowd started insisting that C was a low level language. I've been banging keys through all of this period. You are wrong.

          and even today almost all OS kernels including linux, windows and OS/X are written in it.

          Not entirely, but you pretend different.

          The real problem here isnt your ignorance about C, its that you have no idea what "low level" means, just like that wave of 1990's C programmers.

          Buy a ticket on the clue train when you get a chance.

          I'm already on the clue train. Tickets cost knowledge. Hope that someday you can a

          • The C crowd has been claiming this for awhile, but not since the 70's. It wasn't until the 90's that the C crowd started insisting that C was a low level language. I've been banging keys through all of this period. You are wrong.

            Taken from K&R first edition calls C "not a very high level language", while second edition calls C "a relatively low level language" (page 1). I assume they know better than you.

            The real problem here isnt(sic) your ignorance about C, its that you have no idea what "low level" means, just like that wave of 1990's C programmers.

            I think we know what "low level" means, and it means something other than what you think it does.

            • Sorry K&R first edition was published 1978 -- "70s". Considering most people considered K&R's book the authority on C at the time, and they played a big role in writing C as we know it, I think I'll take their word for it over yours.

          • by HiThere ( 15173 )

            OTOH, what do you mean "low level". Assembler code is generally executed via a lower level of microcode (though I think it's burned into ROM during the writing of the CPU chip. (Read ROM as descriptive, not as a separate chip.)

            So I have no problem calling C low level. These days I normally program in Python or D. I gave up on assembler the sixth time I had to rewrite all my programs.

          • by Viol8 ( 599362 )

            " I've been banging keys through all of this period. You are wrong."

            All that proves is that length of service doesn't always give rise to knowledge.

            "Not entirely, but you pretend different."

            Apart from a small amount of assembler - yes , entirely.

            "I'm already on the clue train."

            Apparently the one you're on has yet to leave the station.

      • Real bootloaders are written using toggle switches and pushbuttons, not keyboards!

  • News for nerds? (Score:4, Insightful)

    by Anonymous Coward on Wednesday December 16, 2015 @08:33AM (#51128723)

    Is this even an issue?

    It's a password on the boot loader. It's not encrypting anything. If anyone is in the position to interact with a machine before the OS has loaded, they've probably got enough access to it that they can do whatever the hell they want, including booting the system off alternative media and replacing or reconfiguring said boot loader.

    • Re:News for nerds? (Score:4, Insightful)

      by JackieBrown ( 987087 ) <dbroome@gmail.com> on Wednesday December 16, 2015 @08:36AM (#51128749)

      Then why offer a password on a bootloader?

      • Re:News for nerds? (Score:5, Insightful)

        by i.r.id10t ( 595143 ) on Wednesday December 16, 2015 @08:55AM (#51128843)

        I can see where a boot password would be handy for a kiosk or similar setup where the machine is out in public space, and I'd definitely want it locked down to some degree. BIOS boot options as well.

        For a server room, this is no big deal.

      • Re:News for nerds? (Score:5, Insightful)

        by segedunum ( 883035 ) on Wednesday December 16, 2015 @09:01AM (#51128889)
        Its news, but it's not as big as many people think. When someone can physically get to your machine you're going to need an awful lot more than a bootloader password to secure things.
        • I can understand why people want the feature(it's a decent middle ground between "haha, no, you can't fix even the tiniest misconfiguration without booting from an entirely different medium!" and giving anyone who can reboot the machine the ability to use Grub to load a near-arbitrary payload(they need to know what they are doing; but if all boot devices except the one with grub on them are locked out in the device firmware, you can then use grub to boot a payload from any storage it knows how to interact w
        • by arth1 ( 260657 )

          Its news, but it's not as big as many people think.

          It's also not a zero-day. When a disclosure happens before the exploit, it's not zero-day. And when a patch is already out, like for Red Hat, it's definitely not zero-day.

          Is it a bug that needs fixing? Absolutely. But this isn't anything to worry overly much about. There are a lot of other things to worry about with grub2, which isn't exactly the pinnacle of elegant design.

          • Yep. The term "zero-day" indicates that the bug was discovered because it was being exploited in the wild. I saw no specific mention of this, so it looks like the article got it wrong, and the summary picked up on that incorrect usage.

      • by phorm ( 591458 )

        Well, if you've got a fully encrypted drive and a passworded bootloader, it can actually make things pretty difficult to access even if you can boot alternative media.

        • by Bengie ( 1121981 )
          The boot information should be encrypted with the password. That way if the password is wrong and there's a bug in the validation, the attacker will won't be able to read the current information.
          • by phorm ( 591458 )

            That makes sense to me.Another good reason to have a password, and it would also mean that this bug would be useless if encryption is used.

  • by Froze ( 398171 ) on Wednesday December 16, 2015 @08:33AM (#51128729) Homepage

    In the majority of cases if you are interacting with the boot process then you have physical access to the machine. So unless GRUB is managing disk encryption you have access regardless of the password in GRUB. This is security theater, not real security and breaking it is not accomplishing anything significant.

    Next Story.

    • That's so silly - physical access to the machine doesn't mean anything per se!

      What if you can't take the machine apart inconspicuously because the case is sealed. What if you have only 3 minutes before someone else comes by? Security is not black and zero at all.

      One can easily even use an AVR that'll replay the keypress sequence over USB (posing as a keyboard) on a button press. This is something completely different than taking the machine apart to clear CMOS or whatever.

      BTW, can you have UEFI trusted boot

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        What if you can't take the machine apart inconspicuously because the case is sealed. What if you have only 3 minutes before someone else comes by? Security is not black and zero at all.

        That is like the most contrived example ever. Perhaps you shouldn't take use cases from Hollywood flicks?
        We are talking about the boot process, the computer wouldn't be shut down if the user was away for three minutes.
        More realistic scenario would be laptop left in hotel room and an option would be to just steal the laptop and have all the time in the world.

        • That is like the most contrived example ever.

          It's a very common example for many locations, assuming "sealed" means a lock and cable on a public-use computer.

          We are talking about the boot process, the computer wouldn't be shut down if the user was away for three minutes.

          Physical access does include the power button. And it's not just "the user" you have to worry about, but *anyone* just passing by. Of course if the machine was screen-locked with a user logged in, it might arouse suspicion if it's later found turned off or at the login screen.

          More realistic scenario would be laptop left in hotel room and an option would be to just steal the laptop and have all the time in the world.

          More common for home users perhaps, but this doesn't mean it's the only scenario that grub should be designed for.

    • Sometimes, physical access to the machine is the whole point of having that machine around. You provide local keyboard, mouse, monitor or even worse things to annoying and/or weird walking meatsacks called "users".

  • by Ancil ( 622971 )

    Versions from 1.98 (December, 2009) to 2.02 (December, 2015)

    They certainly set a blistering development pace.

    • Re: (Score:3, Informative)

      by spirtbrat ( 848317 )
      It's a boot loader. And as boot loaders go, GRUB2 is already packed with features. What more do you expect it to be developed?
    • Versions from 1.98 (December, 2009) to 2.02 (December, 2015)

      How, exactly, can you call this a "0-day" exploit if the hole has existed for six years?

      • Because GRUB developers had 0 days to develop a patch because it was already known from the outside. They can exist far longer and still be zero-day.

  • by Anonymous Coward

    This was a deliberate move by the FSF, because computers that need passwords aren't really free, are they?

    • This was a deliberate move by the FSF, because computers that need passwords aren't really free, are they?

      You joke, but RMS hates passwords on computers: http://www.oreilly.com/openboo... [oreilly.com] He might as well say "A train that is stuck to the tracks isn't really free to move. Remove the tracks!"

    • This was a deliberate move by the FSF, because computers that need passwords aren't really free, are they?

      Title is obviously wrong. As you should well know, Grub is Not Linux!

      Seriously, the title is wrong, since Grub is a pre-OS environment used to load the actual operating systems, including not just Linux, but Windows and the BSDs. Saying this is a Linux bug is like blaming Microsoft for a BIOS bug.

  • by Anonymous Coward on Wednesday December 16, 2015 @08:40AM (#51128761)

    The new systemd-grub leverages a pre-boot, machine-level dbus interface to policy-kit and systemd-logind, which will handle this for you. Why are people still in the dark ages with bootloader passwords?

    • by armanox ( 826486 )

      I'm sorry, but I think the module you wanted for systemd was bootloaderd.

    • Because complicating the shit out of a bootloader before an OS is even running seems like a great idea.
      • by Anonymous Coward

        GRUB already is the systemd of bootloaders.

        They already did that; lilo was much easier, and simpler than grub; but they went with grub anyway.

        I don't want a GRand Unified Bootloader for my Linux distro; I just want something where it's easy to tweak to boot parameters and doesn't involve the voodoo like parameters of GRUB, something like lilo.

        • by Anrego ( 830717 ) *

          Give extlinux a try. It's still around and is very lilo like, simple config file vice a huge maze of support scripts generating the actual complex configuration files that grub2 uses.

        • by Anonymous Coward

          LI

        • When lilo failed, you were stuck with a box you had to boot from CD. With grub, you can at least boot another disk or even the correct disk.
  • Yawn.... (Score:4, Insightful)

    by Lumpy ( 12016 ) on Wednesday December 16, 2015 @08:45AM (#51128779) Homepage

    If someone has local access, they OWN the machine already. This is a minor inconvenience as zero security is given with a grub password anyways.

    • by 0ld_d0g ( 923931 )

      If someone has local access, they OWN the machine already.

      Using that logic, nobody should be required to enter a password at a local console.

      This is a minor inconvenience as zero security is given with a grub password anyways.

      "Hey guys we have this new password feature, but its completely useless so don't use it or ever rely on it."

  • tl;dr (Score:4, Informative)

    by SharpFang ( 651121 ) on Wednesday December 16, 2015 @09:08AM (#51128937) Homepage Journal

    press backspace 28 times [enter]
    write_word 0x7eb514e 0x90909090[enter]
    normal[enter]
    Enter 'edit mode'
    append init=/bin/bash to the linux entry
    F10

    • by blazerw ( 47739 )
      Or better yet:
      1. Turn on computer.
      2. Choose OS.
      3. Boot.

      Because NOBODY uses the grub password feature.

    • You forgot "Get prompted for login credentials AGAIN when the OS boots."
      • that's what init=/bin/bash is for. You boot directly to bash shell with root privileges bypassing all authentication. Then you can either create a passwordless alias for the root account, or install any rootkit you like.

  • There are enough REAL security issues floating around without getting our panties all in a wad over an issue that requires PHYSICAL access to the Console and Keyboard on a machine that has already been rebooted ...

    Along the same lines, even after this 'Zero-Day' is repaired, if I can access the Console and Keyboard, I can access the Boot Menu, and boot from a Thumb-Drive and then do everything I could do via the Grub2 Bug.

    Sheesh !

    -- kjh

  • by Anonymous Coward

    No surprise here. GRUB2 has always been a POS. I knew this would happen when all major Linux distros started forcing their users to use GRUB2 (not unlike the systemd fiasco). Yet, my Linux machines all use GRUB Legacy and are immune.

    • by gweihir ( 88907 )

      GRUB 2, same as systemd, suffers from gross KISS violation. GRUB 2 also suffers from the "Second System Effect", where they put in everything and the kitchen sink. Systemd has the same problem, but _they_ managed to make this basic mistake on the first try.

  • Seriously though, some of my old motherboards don't work with Grub, and I have no need for features beyond LILO.
  • An attacker with physical access and some minimal skill has won anyways.

  • Seems slackware.org is /.......

  • The fix for Ubuntu was out earlier today, I already applied the latest patch to Grub to fix that bug! Kinda weird having grub patches two days in a row

"You show me an American who can keep his mouth shut and I'll eat him." -- Newspaperman from Frank Capra's _Meet_John_Doe_

Working...