Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

Post reply on HN
Print view View original

141–150 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#141

Post by JackSlateur »

tptacek wrote: post #92
angry_octet wrote: post #90

Earlier quoted context omitted.

Unfortunately that is not what they proposed. To stretch the automotive analogy too far, you could say: if you invite a carjacker in, their seatbelt is not going to stop them from carjacking you.

"Avoid shared-kernel attack surfaces" is not an unreasonable proposition in 2026.

Virtual machines are still the best design and has been for something like 20 years

Containers are good, as long as they all share the same purpose (read: same application, no multi-tenant)

We all know that multi-users systems (and thus, containers) have a very wide attack surface, while VM attack surface is very limited ..

This is why I am totally convinced that:

  - redhat and friends are a terrible idea (licencing forces collocation which reduces segmentation)
  - per-instance pricing (read: cloud public, but not only that) are terrible: for the same reason. Paying per consumed CPU/ram is sane, paying per VM unit is damageful

Re: Dirty Frag: Universal Linux LPE

#143

Post by hughw »

arcfour wrote: post #53
normie3000 wrote: post #25

So umm... should I rush home and turn off all my computers?

Are they already vulnerable to RCE as an unprivileged user? Hopefully not. An LPE only allows an attacker who can already execute code on the system to become root. So, bad, yes, but it doesn't mean you are immediately pwned.

Should I rush to Lambda or ECS and turn off all my containers sharing a host with who the hell knows?

Re: Dirty Frag: Universal Linux LPE

#144

Post by jeroenhd »

miduil wrote: post #5

This again does not work under Android, at least in termux compiled with clang/gcc.

The exploit as posted contains x86 shellcode, so you'd need to drop in the appropriate shellcode to test if it really works.

Android wasn't vulnerable the last time, so far it's been a shining beacon of hope for proper SELinux configuration that I wish was more widely available in other places.

Re: Dirty Frag: Universal Linux LPE

#146

Post by [deleted] »

akerl_ wrote: post #116
chromacity wrote: post #85

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.

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.

[deleted]

Re: Dirty Frag: Universal Linux LPE

#147

Post by Sohcahtoa82 »

chromacity wrote: post #127
akerl_ wrote: post #116

Earlier quoted context omitted.

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

> This is a pedantry for the sake of it.

Par for the course for HN.

Re: Dirty Frag: Universal Linux LPE

#148

Post by eqvinox »

toast0 wrote: post #105
eqvinox wrote: post #100

Earlier quoted context omitted.

"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd. Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check. (Except I didn't say that here. Oops. Getting confused with my posts.)

OK, I may likely have too much sleep debt to understand, but given the bug is that splice can write to the input fd, you're suggesting maybe splice should only let you use an input fd if the process has access to write to it? But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't…

Yes, it'd curtail splice() usage quite heavily. Maybe too much.

But apparently we can't be trusted with the page cache…

Maybe the kernel using supervisor-read-only flags could be made to work, only issue then is what happens if something does in fact need to write…

Re: Dirty Frag: Universal Linux LPE

#149

Post by kinow »

Just got an email from one HPC I have access in Germany. I guess all HPCs ans services like GH Actions are going to be offline for a bit. I think last time was on a Friday too, so it might be another Friday to organize emails, files, rotate backup/passwords...

Re: Dirty Frag: Universal Linux LPE

#150

Post by zzrrt »

akerl_ wrote: post #133
chromacity wrote: post #127

Earlier quoted context omitted.

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.

Post reply on HN