How is being able to break into any Linux machine through grub2 secure?

Question

How is the ability of a person who gained physical access to your computer to get root with those steps in any way secure?

1. When grub2 menu opens press e to edit the Linux start options

2. Change:

   "linux   /vmlinuz-2.6.35-23-generic root=UUID=e7f1e48d-0015-485f-be7d-836217a31312 ro   quiet splash" 
   

   to:

   "linux   /vmlinuz-2.6.35-23-generic root=UUID=e7f1e48d-0015-485f-be7d-836217a31312 ro init=/bin/bash"
   

3. Now you have root access just do:

   mount -o remount,rw /
   passwd user
   mount -o remount,ro / 
   sync
   

4. reboot the computer and you win.

My question is, how is being able to break into any Linux machine through grub2 secure? I don't understand that fact about Linux, thank you for your answers.

Solution 1

Note: The security advice given in this answer is (intentionally) simplified and does not fully reflect how certain components of computer security actually work. The entire point of this answer is that security is a complicated and multi-faceted topic, and that threat modeling is very important. Someone will always find a way around things; there is no such thing as a "perfectly secure system". No security system will permanently keep out a determined attacker. With that said, on to the answer!

---

How is the ability of a person who gained physical access to your computer to get root [using Grub/Bash] in any way secure?

Because if Linux decided to start doing that, hackers would just exploit other security holes. The first rule of security is that if I have physical access to your system, it's game over. I've won.

Plus, imagine your X server broke and you don't have a GUI anymore. You need to boot into a recovery console to fix things, but you can't because that's insecure. In this case, you're left with a totally broken system but hey, at least it's "secure!"

But Kaz, how is this possible? I set a password on my Grub so that you can't change my init to Bash!

Oh, you did, did you? Interesting, because this looks like your photo album. GRUB doesn't have any inherent security factor at all. It's just a bootloader, not a step in some secure boot and authentication chain. The "password" you've set up is, in fact, pretty darn easy to bypass.

That, and what sysadmin doesn't carry a boot drive on them for emergencies?

But how?! You don't know my password (which is totally not P@ssw0rd btw)

Yeah, but that doesn't stop me from opening your computer and pulling out your hard drive. From there, it's a couple simple steps to mount your drive on my computer, giving me access to all of your system. This also has the awesome benefit of bypassing your BIOS password. That, or I could have just reset your CMOS. Either/or.

So... how do I not let you get access to my data?

Simple. Keep your computer away from me. If I can touch it, access a keyboard, insert my own flash drives, or take it apart, I can win.

So, can I just like put my computer in a datacenter or something? Those are pretty secure, right?

Yeah, they are. But, you're forgetting that humans are hackable too, and given enough time and preparation, I could probably get into that datacenter and siphon all of that sweet, sweet data off your computer. But I digress. We're dealing with real solutions here.

Okay, so you called my bluff. I can't put it in a datacenter. Can I just encrypt my home folder or something?

Sure, you can! It's your computer! Will it help stop me? Not in the slightest. I can just replace something important, like /usr/bin/firefox with my own malicious program. Next time you open Firefox, all of your secret data is siphoned off to some secret server somewhere secret and you won't even know. Or, if I have frequent access to your machine, I can just set up your home folder to be copied to /usr/share/nonsecrets/home/ or any similar (non-encrypted) location.

Okay, what about full disk encryption?

That's... actually pretty good. However, it's not perfect yet! I can always perform a Cold Boot Attack using my trusty can of compressed air. Or, I can just plug a hardware keylogger into your computer. One's obviously easier than the other, but the way doesn't really matter.

In the vast majority of cases, this is a good stopping place. Maybe pair it with TPM (discussed below), and you're golden. Unless you've angered a three-letter agency or a very motivated hacker, nobody's going to go through the effort required past this stage.

Of course, I can still get you to install some malware/backdoors by offering you a PPA or similar, but this gets into the very murky area of user trust.

So... how are iPhones so secure? Even with physical access, there's not much you can do.

Well, yes and no. I mean, if I was motivated enough, I could read the flash chip and get everything I need. But, iPhones are fundamentally different inasmuch as they're a fully locked down platform from the very start of the bootup process. This, however, causes you to sacrifice usability and the ability to recover from catastrophic failures. GRUB (except when very specifically designed) is not meant to be a chain in a security system. In fact, most Linux systems have their security chains start post-boot, so after GRUB has finished doing its thing.

iPhones additionally have cryptographic signature enforcement (also discussed below), which makes it very hard for malware to sneak on to your phone.

But what about TPM/SmartCards/[insert crypto tech here]?

Well, now you're pairing physical security into the equation, it becomes more complicated still. But, this isn't really a solution because TPMs are relatively computationally weak and the actual disk encryption doesn't take place on-chip. If your TPM is (somehow) strong enough where it does encryption on the chip itself (some very fancy hard drives have something like this), the key won't ever be revealed and things like cold-boot attacks are impossible. However, the keys (or the raw data) might still be present in the system bus meaning they can be intercepted.

Even so, my hardware keylogger can still get your password, and I can easily load some malware onto your machine a la the Firefox exploit I mentioned earlier. All I need is for you to leave your house/computer for maybe an hour.

Now, if you take your TPM/smartcard/whatever with you, and all the encryption is actually done on the chip (meaning your key isn't stored in RAM at all), then it's practically impossible for me to get in at all. This assumes, of course, that there isn't any known security vulnerability I can exploit and that you follow good security practices.

But what if I have some form of cryptographic/digital signature enforcement on all of my programs to make sure they're legit?

As demonstrated by various smartphone companies, this is a very good way of dealing with security. You've now nullified my ability to inject some code onto your machine to do nefarious things. Effectively, you've disabled my ability to retain persistent access to your machine remotely.

However, this still isn't a perfect method! Digital signature enforcement won't stop a hardware keylogger, for one. It also needs to be completely bug-free, meaning there's no way I can find an exploit that allows me to load my own certificate into your machine's certificate store. Furthermore, this means every executable on your system needs to be signed. Unless you want to manually go through and do all of that, it's going to be very hard to find Apt packages and the like that have digital signatures on everything. In a similar vein, this blocks legitimate uses for unsigned executables, namely recovery. What if you break something important, and you don't have the (signed) executable to fix it?

Either way, an effort to do this on Linux has basically been all but abandoned and no longer works for new kernels, so you'd need to create your own.

So, it's impossible to keep you out of my computer?

Effectively, yes, sorry. If I have physical access and enough time and motivation, it is always possible to get into a system. No exceptions.

In reality, though, most evil people won't try to go this far just for some cat pictures. Typically, just full-disk encryption (or even just running Linux!) is enough to deter most script kiddies from having their two seconds of fame.

TL;DR: Just don't let people you don't trust near your computer and use LUKS. That's typically good enough.

Solution 2

If you want it tied down use a password. From the link:

GRUB 2 Password Protection Notes

Grub 2 can establish password requirements on:

• All menuentries
• Specific menuentries
• For specific users: For example, user "Jane" can access Ubuntu but not the Windows recovery mode, which is only accessible by "John", the superuser.

• The administrator must enable password protection manually by editing the GRUB 2 system files.

• Users and passwords should be identified in the /etc/grub.d/00_header or another GRUB 2 script file.

• Unless universal protection of all menuentries is is desired, the specific entries must be identified:

  • Manually by editing the Grub 2 /etc/grub.d/ scripts such as 10_linux and 30_os-prober

  • Manually by editing a custom configuration file created by the user.

  • Either of the above methods enables GRUB 2 to automatically add the password requirement to the the configuration file (grub.cfg) whenever update-grub is executed.

  • Manually by editing /boot/grub/grub.cfg. Edits to this file will be removed when update-grub is run and password protection will be lost.

• If any form of GRUB 2 password protection is enabled, the superuser's name and password are required to gain access to the GRUB 2 command line and menu-editing modes.

• The username and/or password do not have to be the same as the Ubuntu logon name/password.
• Unless GRUB 2's password encryption feature is used, the password is stored as plain text in a readable file. See the Password Encryption section for guidance on using this feature.

---

By default(!) in this case usability trumps security. If you can not trust the people that are around you keep the machine with you at all times. People who need more security tend to encrypt their whole system making the need for a password mandatory.

Solution 3

Your intentional hack starts with this:

1. When grub2 menu opens press 'e' to edit the linux start options

But you can password protect the e option as discussed here: How to add the GRUB password protection to the OS load process instead of when editing boot options

You can take the extra step of encrypting the grub password as discussed in the link. Indeed with perhaps 3% of the population (wild guess) using Linux / Ubuntu at home it's a good idea for System Administrators to protect against the e function on production systems at work. I imagine if Ubuntu is used at work then 30 to 40% would be using it at home too and maybe 10% of those will be learning how to do the e on their home systems.

Thanks to your question they have just learned more. With the link above though, System Administrators have another task on their to-do list to protect production environments.

Comments

[Rinzwind]

Who said physical access needs to be made impossble? When someone has physical access -ALL- bets are -OFF-. The owner of a machine should -ALWAYS- have access to his machine when he is next to it. Otherwise it would be possible to brick it with no ways of recovering.

[Anwar]

To be fully secured, you need this solution

[negusp]

@Anwar Haha so true

[njzk2]

I recommend reading the gentoo security handbook, it starts just with that: wiki.gentoo.org/wiki/Security_Handbook/Full#Physical_securit‌​y

[paulzag]

Oh no commerades! @Clutchy discovered our secret. We all must take the cyanide capsules now.

[Kaz Wolfe]

@paulzag Understood, I'm going to go trigger the server room self-destruct mechanism. Glory to RMS!

[user253751]

@Clutchy Do you have any ideas for how to this security flaw might be fixed?

[Clutchy]

@immibis Personally no, I am new to security. Is there a similar thing you can do on a mac?

[Boris the Spider]

@Clutchy yup: single user mode. And in any case, I can always simply take the disk out and put it into another computer. This works for Mac, Windows, Linux, BSD - you name it. Unless of course you have FDE; but there are ways around that too. If you give your computer to someone you don't trust; then it's GAME OVER...

[Barafu Albino]

If you need that kind of security, you can encrypt all your HDD. Recent versions of Grub allow you to have even kernel itself on an encrypted partition! So without a password there is a standart copy of grub and a single encrypted LUKS partition and that's all you get from gaining physical access to a machine that is powered off.

[Neil McGuigan]

"If I violate a sacrosanct security principal, why is my system not secure?"

[Byte Commander]

Related: How to secure my laptop so that hacking by physical access is not possible?

[user2338816]

You'll generally need a significantly more expensive server if you want to protect against basic physical access. Questioning Linux can be pointless without simultaneously questioning most of the physical hardware platforms it runs on.

[Eliah Kagan]

Related: Why there is no password to root under Recovery Mode?

[Santanor]

Or just encrypt your home partition.

[Kaz Wolfe]

@user13161 This still allows a malicious entity to replace something like /bin/bash with their own evil script, which will do Bad Things with an un-encrypted home folder.

[v7d8dpo4]

GRUB lets you use a LUKS encrypted boot partition, in which scenario the password to boot can't be bypassed. See wiki.archlinux.org/index.php/Dm-crypt/….

[Kaz Wolfe]

@v7d8dpo4: Encrypting /boot is actually useless imo. It'll add a boot password, but you'd still need to decrypt / to actually do anything useful, so you're just adding some extra overhead for little to no benefit. Plus, I can just use my own Grub disk to bypass your encrypted boot if only /boot is protected. Or I can just read the drive like normal.

[Martin Bonner supports Monica]

Full disk encryption will probably be enough to stop law enforcement. If your threat model includes an attacker who can install a hardware keylogger, then I don't think there's a defence. (Smartcard perhaps.)

[Kaz Wolfe]

@MartinBonner Hmm, yeah, I forgot about smartcards. They'd work, unless the attacker has the ability to reverse-engineer the smartcard chip or otherwise use some known exploit. Yeah, FDE is enough, but I'm just going over the top to point out that physical access is the end-all :D

[pjc50]

iPhones (6 onwards, I think) not only have full "disk" encryption, but it's linked to the pincode/biometric login. So if you're willing to have your computer refuse to boot without intervention, you too can tie its disk encryption to a hardware token / password / TPM module. It's just quite a lot of work.

[Adam Martin]

@pjc50 my BlackBerry PRIV, (and I assume some other android devices) allow the same full device encryption with password-requiring boot. But yeah, even these devices can go down if you have the money/time (clone it with the bruteforce protections removed).

[TheWanderer]

I didn't know about that cold boot thing, and that it was literal.

[Gandolf989]

I would have thought that a current version of Linux with full disk encryption with a 25 characters encryption key using upper/lower case letter, numbers and special characters would keep my laptop safe. I wonder if someone has built a device to overwrite system memory with all 1's then all 0's before doing a halt. I would imagine that it would work in a similar fashion to the disk wipe utilities that have been around forever. Not that I need any of that. My cat pictures should already be safe.

[Kaz Wolfe]

@Gandolf989 Such a thing already exists! It's basically a door lock. To successfully pull off a cold boot attack, I need to be fast. Like, less than a minute to freeze your RAM sticks fast.

[Boris the Spider]

@Gandolf989 it's nothing to do with halting the system! You freeze and remove the RAM while the machine is running. There is absolutely nothing you can do to prevent it as the keys must be in RAM to access the data. You could maybe encrypt the RAM with a TPM; but the speed penalty would be astronomical...

[Gandolf989]

I was just thinking if there was a way to stop the cold boot attack by forcing the system to shutdown and then delaying someone from doing the cold boot attack. All of this is a hypothetical debate though. I don't plan on freezing my own ram.

[Byte Commander]

Let's be honest, those passwords can easily be bypassed with physical access. They protect a system from noobs, but not from attackers with some basic skills (using google might already be enough) and physical access.

[Byte Commander]

Let's be honest, those passwords can easily be bypassed with physical access. They protect a system from noobs, but not from attackers with some basic skills (using google might already be enough) and physical access.

[WinEunuuchs2Unix]

@ByteCommander It's all about physical access. BIOS can be setup with administrator password so it can never boot from USB, or DVD. Someone can open the case, short two pins on the motherboard and password is reset to blanks (no password required to change BIOS boot order).

[fuzzyTew]

I always install the /boot partition to a USB key, and keep the key with me where-ever I go, and configure full disk encryption. If I wipe my RAM on shutdown, how is my security?

[fuzzyTew]

Reply to my own question: I think if I use full-disk encryption, keep my /boot partition on my person, and wipe my ram on shutdown, my attacker's options are limited to either finding my machine running and alone (key is in ram & accessible on the bus: keep it turned off), adding a physical device to watch my system run and hoping I don't find the device, adding malicious code to firmware used by my system (hardware devs could deter by checking sigs), or compromising my system using non-physical means. But I would be interested in others' views.

[Kaz Wolfe]

Late comment, but I'd like to point out that this can occasionally be defeated in simple ways. There might be some (documented) manufacturer command to clear an HDD password without triggering a format. Similarly, I might be able to just "borrow" the hard drive platters and put them in my own controller -- the password is (usually) stored in the controller's NVRAM, not on the platters themselves.

[Scooby-2]

@Kaz, you are absolutely right in what you say, but emphasis must be put on the word "occasionally" in your phrase "this can occasionally be defeated in simple ways." As hard drive technology continues to improve, contrary to what you say, nearly all manufacturers now store their firmware and passwords on the platters so changing the controller card will not help. There is software around to unlock drives without wiping the data, but it only works on old drives.