If this indeed works on all major distributions, I just continue to be amazed by how irresponsible the maintainers are. We're talking about optional kernel functionality that's presumably useful to something like <0.1% of their userbase, but is enabled by default?... why?
This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet. Except it's not 1999 anymore.
Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask. They just don't know who is using what. It's always possible for users to go back and tailor their builds for the stuff they actually want.
And... I remember the early days of Linux where I ran `make menuconfig` and selected exactly the functionality I wanted in my kernel. I'd... rather not end up back there.
That said a target for an easy win here is RHEL, which compiles a lot of modules into the kernel rather than leaving them as loadable modules, so the mitigation for e.g. copy fail was impossible. Maybe they could do with a few less of those?
You can make precisely the same argument for network services. Who knows, maybe you need telnet and UUCP and NFS and ftpd running on your system?... why should the distro maintainer decide?
Well, because you probably don't, and it's a security risk, so no need to put millions at risk for the benefit of that one person who wants to tinker with packet radio or whatever. Similarly, it would be prudent for distros to not allow autoloading of modules that are extremely niche while giving a simple way to adjust the settings if you want to. God knows they have plenty of GUI configurators and config files already.
The thing is that we could simply split those modules into separate packages
No reason why you couldn’t just `dnf install -y kmod-rxrpc` if for whatever reason you need that.
Now I think about it, it's kinda weird if non-root users can cause kernel modules to get loaded, without any hardware changes having happened.
If the kernel modules for esp4, esp6 and rxrpc aren't loaded - how is it that a non-root attacker can cause them to get loaded?
It seems that this is allowed as part of a dependency chain...
Don't disagree, but there are eBPF mitigations that work as alternatives to unloading kernel modules.
Can you elaborate on that?
Have a look at https://github.com/atgreen/rhel-block-copyfail
Thanks!
From the sound of it, the same mitigations for Copy Fail 1 are also effective here.
No, they are different. I just bundled them together for convenience in this POC. The only real thing in common is that they both use eBPF.
Got it, thanks!
>Distro maintainers blacklisting specific functionality because they believe YAGNI is a pretty big ask
We have forgotten what a distro is, and its modern corruption of the concept is now taken as the definition.
Distributions weren't meant to be competing generic universal bundles of userspace tools in addition to the kernel.
There is no way to disable components you think users won't use and not make it incredibly difficult to use the system. I personally would have no way to know what to enable or not enable based on what I want to do, and I've been using this stupid OS for 25 years.
Linux distro maintainers are the most responsible software maintainers on the planet. Their security practices are miles beyond the stupid programming language package managers, they maintain a select list of packages, vet changes, patch bugs, resolve complex packaging issues, backport fixes, use tiered releases, distribute files to global mirrors, and cryptographically validate all files. And might I remind you, they do all this for free.
In many ways non mobile computers are very much still stuck in 1999. Android is significantly more secure than other Linux systems because it's much younger and had the chance to integrate mandatory access control into the entire stack.
Unless your Android doesn’t get any security updates anymore.
https://durovscode.com/google-android-security-update-warnin...
That is a well know and entirely different issue
Is it?
The claim is Android is much more secure than other Linux, but if 40% of all Android devices don‘t get a security patch and you can’t even do it yourself I would call the more secure per se.
Hardening is one part of security, patchability another. Android lacks in the latter.
You can take many computers from 1999 and update them to the best software available today. Most phones won't even do that for a few years. And that is security in the real sense of the word, as in "this won't just pull the rug from under me".
(Of course the problem isn't Android, it's the chipset vendors that the SW depends on. They drop support fast and never give enough info for anyone else to keep things up to date. Also Google.)
So what? Most devices running Linux don't get security patched, it was ever thus. Think about all the kernels running in wifi routers and other embedded devices.
>if 40% of all Android devices don‘t get a security patch
No system will stay secure once it does not receive updates. That does not exclude it from being more secure than another system based on security feature merits as long as it does get updated.
>Hardening is one part of security, patchability another. Android lacks in the latter.
That is not an inherent flaw with android but OEM devices shipping modified android they don't bother keeping up to date. Some OEMs are trying to mitigate this by increasing security update support up to 7 years which still is not long enough but also doesn't make them less secure than a desktop that gets updated longer.
What people forget is that not only desktop and mobile phone software is different but also the hardware. If your desktop pc hardware is out of date / EOL nobody cares usually. Meanwhile on a phone this can be a lot more relevant because security expectations and threat models are a lot higher, for example see all the zero/one click compromise headlines.
It is an inherent flaw of android. Imagine no Windows update because Lenovo stopped support for 4 year old notebooks
It's 7 years because there limiting factor is hardware firmware support. A lot of desktop hardware does not receive firmware updates above 4 years either but that just gets shrugged off like you do because "OS still gets updates so it means it's secure".
> irresponsible the maintainers are
Today it's 0.1%, tomorrow it might become 100%. User demand is hard to anticipate, so it's reasonable to include small features that don't cost a lot to run by default.
It's not ideal, but you really don't want to prevent user from finishing their task, because maybe then they'll just give you a bad name and switch to another distro.
That's to say, it's not "irresponsible", it's reasonably maximums (at least trying to be).
It’s not enabled by default. It’s an optional module that is loaded on demand. The entire setup of the kernel promotes compiling in the core set of things your users will need and offering basically everything else as a module to load on demand.
This is a pedantry for the sake of it. If it's present by default and an attacker can trivially cause it to be loaded, it's the same as "on by default".
It’s radically different than on by default.
Having a service that automatically starts and listens on the network is radically different from having a module that a local administrator can load.
If you want to block module loads, you’re one sysctl flag away.
> having a module that a local administrator can load
This is a successful local privilege escalation, so local administrator privs were not needed. In default configuration of all distros, apparently.
> If you want to block module loads, you’re one sysctl flag away.
The modules aren't really the point, it's that unnecessary features (to 99% of us?) were accessible by default without privs.
This is "a service that automatically starts". That's what automatic kernel module loading is for!
It's not any different from putting an always-running network service behind socket activation instead. The security boundary/risk is nearly identical between the two.
One is remotely accessible. The other is locally accessible.
The GP you were replying to mentioned a vulnerability "present by default and an attacker can trivially cause it to be loaded".
You responded contrasting a network service with an administrator-loadable module.
This is neither of those. It's an LPE, not a remote exploit. It doesn't require an administrator (root) to load anything. In context of this vuln, it's exactly analogous to socket activation. The scope of an LPE vuln is local; yes. What does that have to do with the rest of your comments?
I don't understand what point you're trying to make here.
I originally replied to a comment saying "This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet". It is not like that.
[flagged]
> This is a pedantry for the sake of it.
Par for the course for HN.
How would the attacker cause one of these modules to get loaded without already having root?
Trivially. Kernel modules autoload through various unprivileged mechanisms.
Maybe it would be reasonable for sysadmins to proactively whitelist used / block all exotic unused modules that are not needed in their system configuration.
This would reduce the amount of ring 0 code. But I've never seen such advice.
Because in order to exploit this, you have to have direct access to the computer. Either through malicious usb device, or by exploiting some supply chain or a known piece of software that will be willingly or automatically installed, and furthermore you need to be able to essentially run arbitrary terminal commands, which is a huge breach of isolation in that software.
If an attacker manages to do all that, its already bad news for you. Escalation to root with this is the least of your worries at that point.
Like someone else below posted, https://xkcd.com/1200/
People need to understand what the vulnerability actually is before freaking out about it.
You are assuming that LPE only applies to the user that holds all the sensitive stuff. But it also applies to users created specifically for isolation. Without LPE they would not have access to anything important even if they were compromised.
So a threat actor buys access to a managed kubernetes service, or other linux-based shared hosting platform, and now they have access to the computer.
Hell, GitHub Actions would do.
Is there any service that relies on Linux user separation or containers to separate different user accounts? I’m pretty sure you’re not supposed to do that and the proper way is to run different instances in virtual machines.
Basically every shared webhost that uses cPanel works like this. The security mechanism they use is called CageFS (https://cloudlinux.com/getting-started-with-cloudlinux-os/41...), which makes it so users can't see other users, but it's not like a VM or something.
Right, you're not supposed to do that...
> ... but is enabled by default?... why?
We could also wonder why XZ was linked to SSH... But only on systemd-enabled distros (which is a lot of them).
Just... Why?
And then make sure to call to incompetence, instead of malice and say non-sense like "Sure, it only factually affects systemd distros, but this is totally not related to systemd". All I saw though was a systemd backdoor (sorry, exploit).
Now regarding copy.fail that just happened: not all maintainers are irresponsible. And some have, rightfully, bragged that the security measures they preemptively took in their distros made them non vulnerable.
But yup I agree it's madness. Just why. And Ubuntu is a really bad offender: it's as if they did a "yes | .." pipe to configure every single modules as an include directly in the kernel.
"We take security seriously, look we've got the IPsec backdoor (sorry, exploit) modules directly in the kernel". "There's 'sec' in 'IPsec', so we're backdoored (sorry, secure)".
xz was not directly linked to ssh, and systemd itself was not providing the backdoor. The weakness is embedded into the architecture of glibc (which has spread to other systems like FreeBSD as well): https://github.com/robertdfrench/ifuncd-up
The entire argumentation here is ridiculous. There's a big jump from "IFUNC undermines RELRO" to "IFUNC is the issue". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, spawn a copy of sshd with a patched config if necessary.
Sure, but distros not using systemd were not affected.
The only reason distros not using systemd were "not affected" is because this particular attack wasn't going after them. They were compromised nevertheless, their compromise was simply consequence-less due to attacker's choices of what to do after the compromise.