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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Tobin Shields
  • 662
  • 1
  • 8
  • 12
  • 4
    Look at KonBoot for Windows. No OS is secure under a physical attack, as mentioned in the answer. – multithr3at3d Jun 06 '19 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 07 '19 at 02:59
  • 12
    [3rd Immutable Law of Security](https://blogs.technet.microsoft.com/rhalbheer/2011/06/16/ten-immutable-laws-of-security-version-2-0/): *If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.* – 8bittree Jun 07 '19 at 20:25

2 Answers2

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.

allo
  • 3,173
  • 11
  • 24
Ghedipunk
  • 5,766
  • 2
  • 23
  • 34
  • 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 07 '19 at 05: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 07 '19 at 08: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 07 '19 at 08: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 07 '19 at 09:08
  • @JochenLutz: there are other ways, of course. But a key logger is a simple solution that should not be ignored because it lowers a lot the bar of "sufficiently advanced opponent"... (btw aren't there UEFI style secure boot systems for RedHat...?) – vladmihaisima Jun 07 '19 at 12:12
  • 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 07 '19 at 15:11
  • Thanks so much for this (and all of the other) great responses. It's a harsh reality to know that physical access is really considered a 'lost cause.' I totally understand that defense-in-depth is important and you should have security controls put into place to prevent a physical attack in the first place, but this seems to make insider threats much more powerful as well as really punishing for a lack of physical security. – Tobin Shields Jun 07 '19 at 19:42
  • It's possible to mitigate evil maid attacks (modifying the bootloader or kernel, or even BIOS) by using a TPM for measured boot. Also, modern disk encryption is slightly malleable, which is not great. But even if you protect from that, an attacker can still plug in a JTAG probe to hijack the hardware! – forest Jun 08 '19 at 02:58
  • @Joshua: `There wasn't room in the bootloader to backdoor it and the encrypted volume started right after the bootloader.` not necessarily a good assumption. If the attacker has physical access they can clone the harddrive and swap it with a slightly bigger one, then they'll have enough space to attach their backdoor. – Lie Ryan Jun 08 '19 at 04:25
  • @LieRyan: In those days, we had the 7.9GB barrier, so no they could not. – Joshua Jun 08 '19 at 04:33
  • @MatthieuM. Could be irrelevant if user had time to shutdown PC and very irrelevant if they managed to physically destroy the key. However, that is not so common situation overall… – val is still with Monica Jun 08 '19 at 13:14
  • GRUB can boot kernels from LUKS-encrypted partitions. Combine it with UEFI secure boot and UEFI password and you have mostly secure encrypted disk (assuming no UEFI backdoors/bypasses and that they can't offline-flash rogue SB keys) – gronostaj Jun 08 '19 at 20:39
  • @forest : Also, TPM does not protect against [IME](https://en.wikipedia.org/wiki/Intel_Management_Engine#Ring_%E2%88%923_rootkit) modification. See [SA-00075](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00075.html) ([Silent Bob is Silent](https://www.f5.com/labs/articles/threat-intelligence/strike-back-at-silent-bob-scan-and-block-ports-used-by-intel-amt-26907)) and SA-00086. Of course, the IME is an always-on, Ethernet MITM, with direct unobservable access to all of your hardware. AMD's is called PSP. – Eric Towers Jun 08 '19 at 20:42
  • @EricTowers Actually it does protect against CSME modification (it hasn't been called IME in nearly a decade). The CRTM of the BIOS boot block validates the CSME region along with the rest of the BIOS before the engine even starts up. Any modifications to its firmware would be detected. – forest Jun 09 '19 at 07:11
  • @forest : There is no "before the engine even starts up". The IME (AMT, SBA, ISM, and a plethora of other pointless marketing names) is running prior to power-on and remains running after power-down. – Eric Towers Jun 09 '19 at 17:23
  • @EricTowers So? It still can't affect the CRTM, and SRTM makes it possible to detect if it has been modified even if it is on. After all, the CSME can't control the TPM (well... not if you're using a dTPM, of course). As for remaining powered on, that's only true for specific vPro systems and only happens when it is configured to do so. If it was compromised e.g. over the HECI interface, then SRTM would detect that. By design, SRTM can't be compromised even by malware running at ring 0 (or "ring -2/-3"). – forest Jun 10 '19 at 06:05
  • @forest : SRTM cannot save you (from physical access). [CVE-2018-6622](https://nvd.nist.gov/vuln/detail/CVE-2018-6622), almost a year old now and with no specific mitigations. [Less technical article](https://www.bleepingcomputer.com/news/security/researchers-detail-two-new-attacks-on-tpm-chips/). – Eric Towers Jun 10 '19 at 16:55
  • @EricTowers The mitigation is to disable S3 state, which is a feature with negative security ramifications in the context of measured boot anyway (maybe changing the DSDT in S3 state and then triggering a hotplug event to re-read it and have the kernel execute the malicious AML?). – forest Jun 14 '19 at 06:47
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.

DevSolar
  • 911
  • 6
  • 10
  • _"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 07 '19 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 07 '19 at 15:49