A pair of Spanish security researchers just revealed a groanworthy get-root-on-Linux bug.
Strictly speaking, just in case we needlessly provoke the ire of Linux fans out there, it’s not a Linux bug (or even more strictly, a GNU/Linux bug), because the problem is in one of the startup scripts used in many popular distributions, rather than in the kernel or the core utilities.
It’s also, if we’re honest, not a particularly dangerous bug, if indeed it is a bug at all, because you can typically only exploit it if:
- You have physical access to the computer.
- The system partition (and probably the rest of the computer, too) is encrypted.
- You deliberately get the decryption password wrong.
When you trigger the bug, you end up in a very stripped-down root shell with access to the
/boot partition only.
If you’re breaking into someone else’s unattended laptop, that’s not such a big deal because you could almost certainly get much further simply by booting off one of those cool USB flash drives that all sysadmins have in their pockets at all times.
And if you’re trying to get root on some sort of internet kiosk where the keyboard and screen are visible but everything else is tucked away behind a padlock, the hard disk probably hasn’t been protected using full disk encryption, which means that this vulnerability isn’t exposed.
The reason full disk crypto has to be enabled is that this password bypass bug, rather embarrassingly…
…is in the script that asks you to enter your hard disk password.
It turns out that all you have to do is enter the wrong password close to 100 times, and that’s that.
In fact, you can just press
[Enter] and hold it down so it starts autorepeating, and after about a minute you suddenly drop into a recovery shell.
The coding error is an interesting one, and teaches us a good lesson: when you get an error back from someone further down the chain, it really matters why the error happened, not merely that it did.
As the researchers noted in their article explaining the bug, the password validation function goes something like this, expressed in pseudocode:
function dounlock: for tries = 1,3 do read password apply password to drive if drive is unlocked then return OK end end return ERROR end
So far, so good.
You’re probably expecting that the
dounlock function is used something like this:
function tryunlock: for tries = 1,5 do if dounlock is OK then return OK end wait a while end # User didn't know the password. # Start from the top after a bigger delay. reboot computer end
But that’s not what happens.
Further up the chain is a function something like this:
function dostartup: for tries = 1,30 do . . . try dounlock # If the root device hasn't shown up yet, give it a little while # to allow for asynchronous device discovery (e.g. USB). wait a while if root device is unlocked then return OK end end drop to emergency root shell end
As you can see, there are two commingled problems here:
dounlockfunction gives three guesses, but is allowed to run 30 times.
- When the 30 tries are exhausted, the reason why the root device ended up unlocked gets ignored.
In other words, by the time the incorrect password guessing is over, the startup scripts don’t take into account that you didn’t know the password.
Of course, this may be deliberate, given that the root shell appears on the local computer, and therefore requires physical access.
Remember that the bulk of the hard disk remains encrypted, so a crook can’t easily access your data this way.
Nevertheless, Ubuntu-based distros load the above disk unlocking scripts from a special unencrypted partition called
/boot, which contains unencrypted copies of your kernel and, of course, the offending startup scripts.
So, giving crooks and miscreants an easy way to access a root prompt, even if they can’t get at the USB ports to add or extract additional data, makes it correspondingly easy for them to subvert the bootup process itself.
That means they might fairly easily and unobtrusively be able to add a few lines to log your hard disk password next time you start up.
And, anyway, what more embarrassing way to give away a root shell than by simply allowing a “hacker” to press
[Enter] a lot?
What to do?
The distros that use the offending script (we tried ElementaryOS, which is built on a Debian/Ubuntu core) may well decide that this code is worth changing, so watch your distro’s mailing list.
On the other hand, the various distro maintainers might also decide that dropping to an emergency shell ought to be the default behaviour when the root filing system won’t mount, regardless of why.
If this worries you, we have two suggestions.
A quick workaround suggested by the authors of the paper is to add the kernel boot parameter
panic=10, which means that the kernel will automatically reboot after 10 seconds if the system panics (the Linux equivalent of a Windows Blue Screen or a macOS Dark Grey Screen of Death).
That works here because the startup script above actually implements the “drop to emergency root shell” part like this:
if kernel parameter panic is set then wait (panic) seconds reboot else drop to emergency root shell end
If you have an internet kiosk, for example, you probably already have autorebooting enabled, so you probably already bypass the unwanted root shell.
A better workaround, but admittedly a much more complex one, is to configure your Linux bootloader to unlock your hard disk earlier in the boot process. (The bootloader on Ubuntu-based systems is usually GRUB, which supports this feature.)
This bypasses the buggy script above, because the root device is already unlocked before the script runs.
This also allows you to have
/boot encrypted as well, making it harder for a crook with limited access and fiddling time to booby-trap your computer by modifying the kernel or your startup scripts.
Unfortunately, most distros don’t have an install-time feature to encrypt everything including
/boot, and the procedure for doing so varies from distro to distro, so we can’t give you a simple list of instructions here.
Of course, you could just switch to macOS, where all this stuff is taken care of for you at install time…
…but we know what would happen if we were to make a suggestion like that.
16 comments on “Get root on Linux: learn the secret password”
Don’t try this… lots of people implement their own modified script to wipe the hard-drive, and then you’ve maliciously damaged their equipment (I think they will find out when they realise the HDD has become a log of n entries from `/dev/zero`
There’s another reason not to try it on someone else’s computer: the Computer Fraud and Misuse Act.
+1 on the next to last line… LOL
Or switch to Slackware 🙂 Different startup scripts…
I learned Loonix on Slackware and OpenBSD–love Slack!
Before I finally got a secondhand JunOS router I ran pf/oBSD an old Dell 200MHz/32MB laptop (3 NICs with dock–for DMZ of course), last seen running for 1485 days before a power outage outlasted the UPS juicing it and my cable modem.
A sad day for a nerd that was–funny how we care so ardently about uptime.
The problem with uptime is that it’s like putting a dollar on red and letting it ride…the better you to do, the harder the fall feels, even though you only lose $1 in the end in every case 🙂
When someone sees you have a very creditably ordinary 5 says of uptime, it’s no good saying, “But you should have seen it last week!”
I don’t use Linux for my day-to-day tasks any more (20 minutes of using a Mac and you can’t help but wonder why you ever wasted so much time tweaking the appearance of every single app “because you could”, or why getting sleep mode to work 100% reliably had to be a science project). But I do have a bunch of Linuxes around and despite trying the greener grass of other distros many times, I have always returned to Slackware. Firstly, you can actually understand the init scripts. Secondly, X is just another application. Thirdly, they dont make ’em like they used to. As implied in the article, however, I do keep an ElementaryOS laptop at hand. I shouldn’t really say anything that sounds like marketing, but I genuinely like the way it looks. Lean and clean for a stripped-down beach laptop.
I like OSX’s stability but just can’t embrace Apple’s “WE WILL TELL YOU WHAT YOU LIKE” paradigm. After three years while I’m no longer tempted to install RedQuits–but it’s still foreign to me. I don’t consider myself overtly stubborn, but to remain objective I should consider the possibility.
I’m on an inherited Mac (my predecessor’s) and still malign quirks that my film nerd brother just loves**. My favorite app is Terminal–not a typical OSX user. Maybe I did Windows too long before finally putting my money where my mouth was at “there’s just gotta be something better out there.”
Still the Mac “goofy GUI” is preferable to launching X on Slackware 4 in dual boot with Solaris 9 on an old Micron junker, testing eleventeen different video cards–Voodoo3 failed? try the TNT2–and hours upon hours tweaking appearances, nudging the edge of Conky (Torsmo?) “just a bit more lefter” or “a bit back righter,” meticulously aligning window manager parameters so that maximized windows won’t hide system stats.
Editing X11 files by hand: OMG, typo killed the radio star.
I still use Slack on servers–I *do* loves me those init scripts–yet my last gui/fluxbox/xfce tweakfest was eons ago–and probably why I never use sleep mode to this day. Mint now runs everything I need for work plus plays movies and games (Steam, FTW), far more than a mere “terminal holder,” which was about all that old Micron could handle….though my box at home usually has a good 15-20 shells open at all times.
Sorry I steered a conversation so far down the road we need road flares and binoculars to see it, but I always enjoy discourse with you. I’ll check out ElementaryOS too.
** click between context menu items, the whole menu closes? I merely sloppily missed my selection; I didn’t want the entire menu to go away. Boo.
Cool Mac Terminal trick: if you click the mouse cursor while holding down the Option, key, the text cursor jumps to where you clicked. Good for editing long command lines or when in vi.
heh, chuckled several times reading this–we Linnicks nerds can be an irksome, elitist lot. Thanks for the info Duck.
This may be the wrong place to ask, but I so far can’t get a straight answer out of anyone who should know: Any idea why OSX found roots in BSD Land yet eschewed using /etc/fstab** (among others)?
** IMO a reasonably well-established standard and at least somewhat reliable as designed
Oh yeah, and…
RMS would be so proud.
There are numerous Unixisms in macOS that either got dumped or are there “just to have the files,” like /etc/hosts.
Not sure how some things were kept and others morphed…
Yeah… I’d be unable to build an OS without quitting my job and devoting a month (six?) to intense web searches. However it seems like basing stuff on something already very well established would preclude changing things that seem so fundamental–as well as save one the trouble of reinventing various wheels. Again, I’m no Ken Thompson, but it seems odd to me.
> When the 30 tries are exhausted, the reason why the root
> device ended up unlocked gets ignored.
I think you’ll find the problem was that it *didn’t* get unlocked.
Oops. I’ll fix that. Ununlocked indeed 🙂
In general, I find that the various scripts have poor error-handling, so I consider physical access to be an easy win for any bad actor. I generally leave my startup scripts alone, because I don’t worry about physical access, having physically secured the premises of my personal computer plus all my other personal property, and fixing the scripts after every upgrade is overly bothersome.
I cannot bring myself to encrypt my drive. It would seem that one single HDD failure would result in total data loss instead of partial loss. So overall, this particular weakness won’t affect me, but there are plenty more where that came from….
In recent years, I’ve had one laptop drive give me a problem, and that was “a single failure” of the it-doesn’t-even-spin-up-and-work sort.