Linux efivars filesystem allowing users to brick hardware

U

usdmatt

Just had a bit of fun reading through the various forums/mailing-lists about this one:

https://github.com/systemd/systemd/issues/2402

It seems that Linux makes EFI variables available as a filesystem, like it does with just about everything else. That way you can use standard filesystem tools cat/rm/etc to manage them. Unfortunately it seems some hardware vendors are setting default variables, then relying on these during boot. So running an rm under / can, rather than just wiping your disk as expected, actually remove these variables and make the system completely unusable.

It's not strictly their fault, but systemd is getting a bit of flack for it because they mount efivars read/write by default and have closed the issue. Their (rather useless in my opinion) argument is basically that it's just one of many ways you can destroy a system (although I don't think many of those are permanent in hardware), and some utilities need write access to these variables to work properly. The advice is to mount the file system ro in fstab yourself.
 
Expose such details to world&dog, and giving out the opportunity for LP and co to pull the trigger of the gun you just happen to point towards the ground (more or less) - What can possibly go wrong?

I think they are all to blame.
 
Yeah the obvious reason to fix this in kernel is that if you just make it read only, it's trivial to re-mount. It provides decent protection for the administrator but not much if a hacker gets root access on your machine.

I don't get why it's rw in the first place though, or why there's so much resistance to make it ro. Sure some applications need to write there, but seriously how often in a machines lifetime will users actually write efi vars. Is it that bad to have those programs error out and tell you to remount it rw, or just do it internally themselves.

You can blame the manufacturers, which a lot are doing, but is it actually breaking the specs for them to create their own efi variables that they use during boot? Obviously it's incredibly bad design (they should use the variables if set, but fall back to safe defaults, or re-create them, if not set), but does it actually break the efi spec?

Edit: Reading the twitter posts a bit more he suggests that making everything that uses efivars handle it being read only gracefully would take just as long as fixing the kernel, which is a fair point.
 
I do kind of agree, which is why I found it strange that they are so adamant about not making it read-only. Considering it's exposed as a file system, you'd expect the utilities to gracefully handle it being mounted read-only, or not mounted at all, already. Also, in the several years or more a machine is in use, surely you only actually need to write to EFI a handful of times.

However the twitter posts are written by the person who developed efivarsfs as far as I can see, so I can only assume what he is saying is accurate.
 
Well, one could assume it be a good idea to check write operations in the file system against security level and user ID - than perform the write if it is done by root and the system is single-user and in secure mode. Like changing some of the file system flags like append-only, for example. What is the problem there? (As if I did not know...)

As for systemd, I'd say this is some kind of plague that comes up in any ecosystem which is densely packed, and it will be culling the herd somewhat. I'm waiting for the first exploit against it and the tantrum following when it turns out you can not exchange it for something else any more.
 
To be fair, exposing EFI variables through a filesystem is okay, and mounting it as writable-by-default is the sort of "oops, I hadn't thought of that"-mistake that all of us could have made (I certainly could have). The problem can be fixed by not allowing a unlink operation; I believe that setting the "u" attribute with chattr will do the trick (you can still remove it with echo -n '' > efi_var). We can argue whether the kernel or systemd or whoever should fix it—but that's not the problem here.

The real problem, like usually with systemd, is the response to this which is "there is no problem, move along". A rm -rf / bricking a system is spectacularly surprising, and is nowhere near as dangerous as "exposing /dev/sda" (rm -rf /dev/sda will not brick your system, or even wipe your disk). Really, all that is needed is a typo: "rm -rf / usr" will do the trick. Removing all your files is annoying and will cost you some time, but bricking your system is several orders of magnitude worse.

But hey, it's probably not as bad as systemd induced hearing damage.
 
Setting the immutable flag has been mentioned but because it's not actually a filesystem and they are just mapping filesystem calls to add/update/remove the variables I don't think there is actually any concept of file attributes, or anywhere to store them.
 
Indeed, this can happen to anyone. But when you write software that can modify such vital parts of the system, some safeguards should be planned and implemented. Simply mounting it writable is a silly mistake, but that does not mean seasoned admins will not do that. They only do that less.
Carpetsmoker said:
The real problem, like usually with systemd, is the response to this which is "there is no problem, move along". ... Really, all that is needed is a typo: "rm -rf / usr" will do the trick. Removing all your files is annoying and will cost you some time, but bricking your system is several orders of magnitude worse.
Click to expand...
*whistle* Bumblebee? *cough*
Carpetsmoker said:
But hey, it's probably not as bad as systemd induced hearing damage.
Click to expand...
What the...? I mean, sound, you hear that. What else does this thing do/did this thing do (prior to fix) unannounced?
 
You must log in or register to reply here.
Back
Top