Earlier quoted context omitted.
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.
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.
Dirty Frag: Universal Linux LPE
161–170 of 370 posts
Re: Dirty Frag: Universal Linux LPE
#162Earlier quoted context omitted.
Linux is not Unix: it is not derived from AT&T Unix.
Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".
Re: Dirty Frag: Universal Linux LPE
#163this is why you don't contact distro mailing list. responsible disclosure is dead.
More information may come out, or I might be missing something, but assuming that the above is accurate, this isn't a problem with responsible disclosure or mailing list opsec; it's a problem with the nature of open source. Right? Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline?
Re: Dirty Frag: Universal Linux LPE
#164Earlier quoted context omitted.
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.
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?
Re: Dirty Frag: Universal Linux LPE
#165Earlier quoted context omitted.
Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".
I’m fairly certain they’re referring to POSIX compatibility, not calling a Linux a Unix.
Re: Dirty Frag: Universal Linux LPE
#166Earlier quoted context omitted.
Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
> desktop Linux doesn't (and won't for UX reasons) Can you elaborate?
Re: Dirty Frag: Universal Linux LPE
#167If 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 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 s…
Re: Dirty Frag: Universal Linux LPE
#168Earlier quoted context omitted.
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 L…
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.
Re: Dirty Frag: Universal Linux LPE
#169If 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 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.
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 alrea…