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.

▲

akerl_ an hour ago | parent | next [-]

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.

▲

chromacity 42 minutes ago | parent | next [-]

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".

▲

akerl_ 34 minutes ago | parent | next [-]

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.

	▲	zzrrt 5 minutes ago \| parent \| next [-]
		> having a module that a local administrator can load This is a local privilege escalation, so local administrator privs were not needed. > 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.
	▲	ftheplan9 21 minutes ago \| parent \| prev [-]
		This is so braindead. Compiling the module was turning it on. Pedantic dipshit. Literally never stop choking on it.

▲

Sohcahtoa82 12 minutes ago | parent | prev [-]

> This is a pedantry for the sake of it.

Par for the course for HN.

▲

zzrrt 13 minutes ago | parent | prev [-]

> It’s an optional module that is loaded on demand.

According to https://github.com/V4bel/dirtyfrag: "on Ubuntu, the rxrpc.ko module is loaded by default." And apparently the other modules are loaded, or loadable without privs, on the other distributions.

It seems to be exploitable in default configuration on all distributions. So I think the complaint stands. Some obscure feature most of us don't need was enabled by default.

▲

JeremyNT an hour ago | parent | prev | next [-]

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?

▲

chromacity 43 minutes ago | parent [-]

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.

	▲	akdev1l 34 minutes ago \| parent [-]
		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.

▲

ActorNightly 33 minutes ago | parent | prev | next [-]

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.

▲

TacticalCoder 2 hours ago | parent | prev [-]

> ... 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)".

	▲	chuckadams an hour ago \| parent [-]
		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