Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

github.com

Post reply on HN
Print view View original

101–110 of 180 posts

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#101

Post by snuxoll »

deathanatos wrote: post #64
kbenson wrote: post #42

Earlier quoted context omitted.

That is an extremely uncharitable reading of what he wrote, and I don't think it captures the essence of his intent at all. He said: > Well, there are tools that actually want to write it. It needs to be accessible in some manner. > The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. Agreement it needs to be guarded, because it's a problem if it can hos…

Not only is root root, and should be permitted to access and modify the system as desired, it seems to me that the root of this problem is that motherboard manufacturers are shipping faulty boards. I shouldn't be able to brick my motherboard from my operating system, and that I can is a bug. You're telling me there isn't so much as a factory reset on these boards? Perhaps systemd could shield users from their motherb…

> You're telling me there isn't so much as a factory reset on these boards?

Quite a few boards have a backup EEPROM to initialize from if the primary EEPROM fails to boot, but who knows if those that do will bother to reinitialize the UEFI variables stored in NVRAM. Honestly, since they are just supposed to be stored in NVRAM what happens if your board battery runs out of juice, will it still brick?

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#102

Post by snuxoll »

mikeash wrote: post #12
ajross wrote: post #3

To be fair, userspace access to these variables is required in order to manage EFI boot. Having them there to be deleted (by root!) accidentally is probably bad, but this isn't a meaningful security fix. The real crisis here is that modern firmware is developed in an environment so fragile and isolated that it's simply unable to recover from configuration that is "wrong". I had a laptop that I bricked about two years…

I don't think this is meant to be a security fix, it's just meant to make it so you can't accidentally break your hardware with what seems like an unrelated filesystem command. I agree that the stupid firmware is ultimately to blame, and mounting this stuff read-write is a fairly reasonable initial decision. But given the existence of this stupid firmware, the resistance to implementing an easy mitigation by mounting…

Technically, denial of service is a security issue - I have modern servers that boot via UEFI (since GPT is required to support large disks), hopefully with less buggy implementations but if someone manages to get root on a server they could totally kill the hardware.

Having to reinstall an OS because some script kiddie decided to `rm -rf --no-preserve-root /` your server bites, but actually bricking the system requiring a board replacement is scary. (Of course, they could technically be a jerk and flash your UEFI EEPROM, but most servers have a backup they will restore from in case the primary has been corrupted).

EDIT: Though, now that I think about it, this is still only going to stop users from hosing their systems. A malicious user could still run an arbitrary binary or kernel module that hoses the UEFI variables as well. Or by modifying the UEFI boot config to load some other custom UEFI binary to hose it... firmware vendors really just need to get their crap in gear, software (even running in UEFI boot services mode shouldn't be able to hose it).

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#103

Post by JoshTriplett »

simoncion wrote: post #94
jerf wrote: post #45

Earlier quoted context omitted.

(Honest question, I lack hardware to check this on myself:) What do non-systemd systems do about this?

If I had a system that I booted in UEFI mode, I could tell you, but all of my hardware (even the ones running UEFI) boot OSs in BIOS mode. Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades. GRUB2 seems to use efibootmgr to write stuff to EFI, and efibootmgr appears to lack a "detect if efivarfs is mount…

> Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades.

Why not leave it unmounted entirely, and only mount it when installing new boot entries?

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#104

Post by snuxoll »

moonbug wrote: post #38
endgame wrote: post #26

And that's the sort of thing that could easily sneak into the `curl http://some/url | sudo bash`-style of installs that are popular these days.

Good.

I could do it in an RPM post-install script too if it will get people to stop whining about running arbitrary scripts.

All software you install on your system through binaries is potentially suspect to an extend. Sure, I trust the Fedora build system to do the right thing, so I can with some certainty assume anything in the Fedora Collection or EPEL is "safe" - but when I need to install 3rd party software to get my video card working I can throw all that out the window.

Be sane when testing any binary you install, at least with RPM's or DEB's I can verify the GPG key of the vendor - assuming they bother to use one at all... piping scripts directly from curl to bash is bad because of the potential of the stream ending early and leaving in an inconsistent state, that's the only thing that is notable worse versus installing a package (and can be worked around by downloading it first, THEN executing it).

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#105

Post by snuxoll »

Silhouette wrote: post #44
Someone wrote: post #10

The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ( (note that you can…

The comments by Lennart Poettering, IMO, are a prime example of the schism between what is needed for reaching "the year of Linux on the desktop" and what some hackers think is best. I tend to think the Linux on the desktop thing is a bit of a diversion, but this issue and Poettering's response certainly lend weight to the concerns many have raised about systemd. What happened to defence in depth? Even if your users…

Did Lennart have anything to do with the actual efivars implementation in the kernel? If so, then yeah, shame on him by all means. I agree it's a broken abstraction, but it's what the kernel developers decided on (and they sure like making system configuration available with filesystems, see sysfs and procfs).

Ultimately access is needed to even configure the bootloader, and right now that means it needs to be mounted RW. Let's go yell at the kernel developers instead of taking it out on systemd for using a virtual filesystem instead of a syscall.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#106

Post by cnvogel »

eeZi wrote: post #88
JulianMorrison wrote: post #27

Why not just turn off recognition of "rm" in the efivarfs? That is, the response to "unlink" of a file that represents a system abstraction of firmware should be something drastic only to the unlinker. SIGSEGV or something. "Go away, don't do that."

Well there are use cases where you'd want to remove an EFI variable.

Then just require the efivars to have different semantics, just have a look like unbind works for drivers. If you really want to be super cautious, add a safeguard to enable this.

    echo 1       >/sys/...efi.../enable_remove
    echo varname >/sys/...efi.../remove_var

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#107

Post by cnvogel »

endgame wrote: post #26

And that's the sort of thing that could easily sneak into the `curl http://some/url | sudo bash`-style of installs that are popular these days.

Are you arguing about malicious attempts to mess up, or brick, your computer, facilitated by efivars presenting an interface accessible by simple shell scripts?

Well... If there would be an api requiring, for example, a special syscall (or maybe even uglier, an mmap of /dev/men), I'm 100% percent sure that the default install of all Linux distributions would include an /sbin/efivars command exposing this API to every shell script running as root... So nothing would be gained.

For safeguards against accidental damage, on the other hand, in completely in favour.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#108

Post by simoncion »

JoshTriplett wrote: post #103
simoncion wrote: post #94

Earlier quoted context omitted.

If I had a system that I booted in UEFI mode, I could tell you, but all of my hardware (even the ones running UEFI) boot OSs in BIOS mode. Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades. GRUB2 seems to use efibootmgr to write stuff to EFI, and efibootmgr appears to lack a "detect if efivarfs is mount…

> Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades. Why not leave it unmounted entirely, and only mount it when installing new boot entries?

> Why not leave it unmounted entirely, and only mount it when installing new boot entries?

Because there are -presumably- reasons to read EFI variables? If they're exposed through efivarsfs, then it's a convenient way to access them.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#109

Post by krylon »

mmastrac wrote: post #4

These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these day…

> Systemd hate is en vogue these days

To be fair, Lennart Poettering could probably end war and famine forever in a single day, and some people would still find something wrong with that.

On the other hand a certain amount of skepticism and criticism is very much in order. (I am saddened, though, by the way online discussions so easily deteriorate into name-calling and bitter ranting.)

Just to be clear, I was highly skeptical of systemd initially, now I have two systems running Debian Jessie, and quite honestly I haven't noticed much of a difference one way or the other. So at least now I am more confident that we are not all going to die because of systemd. On the other hand, I wish there had been more initial coordination / portability work to make sure stuff like GNOME keeps working smoothly on *BSD as well.

Re: Systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm'

#110

Post by Ao7bei3s »

pjmlp wrote: post #95
microcolonel wrote: post #91

Earlier quoted context omitted.

The point is that that would offer no benefit. A root user can just mount it rw again in a single call.

So in a similar vein, why bother with alias rm='rm -i' at all?

But that doesn't actually exist by default, and so it's not a good example.

A better example is that `/` is a special case for `rm`.

(Besides: I'm not a fan of `rm -i`, precisely because it's non-default. You'll get used to it, and then someday you accidentally some files on a system where you didn't add the alias.)

Post reply on HN