33

I am studying for my RHCSA exam, and one of the topics is the ability to "change a forgotten root user password." This is an official exam objective and even has official Redhat documentation.

How is this not a glaring security vulnerability? Shouldn't the ability to change a root user password not exist? I get that you need to have physical access to a machine (which makes it harder to implement) but why even have a password at all if it can just be changed like this? Is there a way to disable this 'feature' so that it cannot be changed from GRUB like this?

Can you do this in all other Linux distros as well? Or is this a Redhat exclusive ability?

Improve this question
3
  • 4
    Look at KonBoot for Windows. No OS is secure under a physical attack, as mentioned in the answer.
    – multithr3at3d
    Jun 6, 2019 at 23:07
  • 9
    NOT having this ability is a vulnerability. You can't put it back in the bag once it escapes. Changing admin passwords should be SOP. A deceased or incapacitated administrator is a foreseeable event. Ideally a securely printed envelope should also be in secure location.
    – mckenzm
    Jun 7, 2019 at 2:59
  • 12
    3rd Immutable Law of Security: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
    – 8bittree
    Jun 7, 2019 at 20:25

2 Answers 2

Reset to default
62

You pretty much hit the nail on the head when you said that you need physical access to the machine.

If you have physical access, you don't need to go through the official steps to reset the root password, as you can flips bits on the hard drive directly, if you know what you're doing. I.e., you can boot up a recovery OS from a DVD or flash drive, and mount the drive that way to gain complete read/write access to the entire disk.

Disk encryption will mitigate the risk, but doesn't remove it entirely* but makes attacks much more complicated. It is best to assume that an attacker with physical access will be able to influence every aspect of the device in time.

Since it's assumed that attackers with physical access will always gain privileged account access eventually, there's little point in putting the legitimate administrators through extra trouble if they lost their password.

Every Linux distro that I have used has had this feature, though it's possible that some of the distros aimed at a more paranoid audience could disable this.

In addition, it's a standard feature in BSD Unixes, was tested for on the CCNA exam at least 15 years ago when I took it for Cisco devices, and it's fairly trivial to reset passwords on a Windows machine if it isn't explicitly secured.

* The attacker could for example add a backdoored kernel or initrd in the /boot directory, that needs to be unencrypted because the bootloader must be able to read the kernel and initrd files.

Improve this answer
18
  • 4
    "Disk encryption will mitigate the risk, but doesn't remove it entirely" While I agree with this, I think this should be explained. E.g. assume that the disk is encrypted and you need to enter the key (or use dongle) every time you boot up and / or login for decryption. Assuming that encryption is done right, how does physical access to the encrypted data disk help with the decryption?
    – Andrew Savinykh
    Jun 7, 2019 at 5:33
  • 2
    @AndrewSavinykh: Freeze the RAM, unplug it, inspect it with the help of another computer; if you time right, you get the password, and at worst, you get whatever disk content is cached in RAM at that moment in time. Physical access is game over for a sufficiently advanced opponent.
    – Matthieu M.
    Jun 7, 2019 at 8:22
  • 3
    @AndrewSavinykh: for key case: add a physical key logger to keyboard and wait to get the key and any other passwords introduced.
    – vladmihaisima
    Jun 7, 2019 at 8:27
  • 9
    @vladmihaisima: with physical access to the disk, you can modify the initrd in the unencrypted boot partition to log the encryption key and then reinstall the disk. No need for a physical keylogger.
    – Jochen Lutz
    Jun 7, 2019 at 9:08
  • 2
    I once studied this problem. In the old days, there was an actual solution. /boot was encrypted. The code for mounting /boot was written in golfed assembly. NVRAM was hashed and the kernel checked. There wasn't room in the bootloader to backdoor it and the encrypted volume started right after the bootloader. Can't do it with UEFI. :(
    – Joshua
    Jun 7, 2019 at 15:11
28

How is this not a glaring security vulnerability?

It is. Physical access to your system is the ultimate vulnerability.

Is there a way to disable this 'feature' so that it cannot be changed from GRUB like this?

Can you do this in all other Linux distros as well? Or is this a Redhat exclusive ability?

Make yourself aware of what is happening here:

Your operating system is not even running yet when the attacker takes control of your system.

While GRUB comes packaged with Linux, it's not an integral part of it, and actually, the attacker could replace GRUB with some other bootloader without the OS being any the wiser.

So it's not as much about your OS being vulnerable. It's about your OS, any OS really, having been taken out of the equation.

Even if you have your hard drive encrypted, requiring the user to enter the password before the actual boot. With physical access to your system, nothing keeps the attacker from e.g. installing a keylogger (hardware or software) to get that password the next time it is entered.

Since there is virtually no way to defend against an attacker with physical access to your machine, generic operating systems don't bother with making it hard(er) for an attacker with such priviledges. You've already lost the fight at this point.

Someone with physical access is, effectively, a root user.

Improve this answer
2
  • "Your operating system is not even running yet when the attacker takes control of your system." - While true for the general class of attacks with physical access, it's not true in the OP's situation; the described procedure involves booting the OS in single-user mode in order to change the root password. Note, booting the OS.
    – marcelm
    Jun 7, 2019 at 15:41
  • 12
    @marcelm The attacker only gets to that mode because he has control of the boot sequence. The OS does not defend against this because "you've already lost the fight at this point".
    – DevSolar
    Jun 7, 2019 at 15:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .