Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

161–170 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#161
post #133

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.

One is remotely accessible. The other is locally accessible.

Re: Dirty Frag: Universal Linux LPE

#162

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

I’m fairly certain they’re referring to POSIX compatibility, not calling a Linux a Unix.

Re: Dirty Frag: Universal Linux LPE

#163
post #152

this is why you don't contact distro mailing list. responsible disclosure is dead.

At present it looks to me like the embargo was broken by someone identifying the patch as fixing a vulnerability, not someone leaking the mailing list.

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

#164
post #161

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

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?

Re: Dirty Frag: Universal Linux LPE

#165

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

Oh damn, you are probably right.

Re: Dirty Frag: Universal Linux LPE

#166
post #7

Earlier 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?

To solve the issue from the source, you need to enforce security through means like mandatory access control. The problem is that existing desktop and server systems are too mature for that to be practical, you'll have to rework almost everything and users will certainly reject it violently due to the breakages.

Re: Dirty Frag: Universal Linux LPE

#167

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 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…

Don't disagree, but there are eBPF mitigations that work as alternatives to unloading kernel modules.

Re: Dirty Frag: Universal Linux LPE

#168
post #161

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

Re: Dirty Frag: Universal Linux LPE

#169

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 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…

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.

Re: Dirty Frag: Universal Linux LPE

#170
After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?
Post reply on HN