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

101–110 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#101

Post by refulgentis »

firer wrote: post #18

This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what yo…

It’s very hard to see a root vuln similar to, but not the same as, another discovered by AI, as a lesson about AI not exploring.

Is there a counterfactual where you would say it explored well enough, besides both vulnerabilities published as one?

Re: Dirty Frag: Universal Linux LPE

#102

Post by oncallthrow »

arian_ wrote: post #66

Every time someone finds a universal Linux privilege escalation, somewhere a sysadmin whispers 'this is why we don't run as root' while nervously checking if their containers are actually isolated.

> this is why we don't run as root

The entire point is that you can escalate to root

Re: Dirty Frag: Universal Linux LPE

#105

Post by toast0 »

eqvinox wrote: post #100
toast0 wrote: post #96

Earlier quoted context omitted.

splice is documented to return EBADF if "One or both file descriptors are not valid, or do not have proper read-write mode." So it seems surprising to me that you can call it when the out fd is not writable? But I didn't retain the information about the vulnerability, so I'm missing something. There was something about copy on write, IIRC?

"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 make sense to limit splice such that it can't do the task it was built for. Maybe splice should just not write to the input fd? :P

Re: Dirty Frag: Universal Linux LPE

#106

Post by minimaltom »

arian_ wrote: post #66

Every time someone finds a universal Linux privilege escalation, somewhere a sysadmin whispers 'this is why we don't run as root' while nervously checking if their containers are actually isolated.

This attack class lets you escalate from any user to UID 0. Not running as root won't save you, in fact, this attack is for those processes not running as root.

However, if you are in a user namespace where UID 0 doesn't map to system-wide capabilities, and you dont share page cache for the setuid binaries on the system, this attack doesn't lead to LPE.

Re: Dirty Frag: Universal Linux LPE

#107

Post by zepearl »

eqvinox wrote: post #54
zepearl wrote: post #33

So if I understand correctly 3 modules are involved: - esp4 (kernel config "CONFIG_AF_RXRPC") - esp6 (kernel config "CONFIG_INET_ESP") - rxrpc (kernel config "CONFIG_INET6_ESP") Is this correct?

You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.

damn you're right, thx

Re: Dirty Frag: Universal Linux LPE

#108

Post by chuckadams »

TacticalCoder wrote: post #88
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.

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

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

Re: Dirty Frag: Universal Linux LPE

#110

Post by thaniri »

KamiNuvini wrote: post #76

Does anyone know whether Debian is vulnerable? I tried the exploit on a Debian 12+Debian 13 machine but wasn't able to reproduce it myself.

I was able to reproduce this issue on kernel 6.12.57+deb13-amd64 running Debian 13 (Trixie), but unable to reproduce it on kernel 6.1.0-42-amd64 running Debian 12 (Bookworm).

For anyone not on the security stream of Debian packages for Bookworm, kernel version 6.1.0-42-amd64 is actually immune to copy.fail. Surprising that it looks to be immune to dirtyfrag. If you haven't already patched on the security stream, you can choose any kernel version that kept commit 2b8bbc64b5c2. I am thinking that the same commit might accidentally be keeping certain Debian 12 kernel versions safe from dirtyfrag as well.

Post reply on HN