Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

171–180 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#171
post #153
post #13

I'm curious what broke the embargo. Did it leak or did a third party find it independently?

No embargo exists (or could possibly exist) in the first place. Linux is open source, so every patch fixing the security bug is immediately visible to everyone. There is no workaround to that by the very design how the kernel is developed. The "embargo" people talking about is the rather stupid notion that if people keep their mouth shut and not write "THIS IS A LPE" straight in the patch description, everyone can pr…

My (novice) understanding is that embargoes are intended to provide time to 1) develop a patch and 2) distribute the patch.

For Linux/public open source, what you said is right about 2). Once the patch is visible to anyone, it's trivial to identify exploits for unpatched systems. But 1) is still a valid use-case for embargoes for Linux vulns, right? Like, if this patch had taken a few weeks to develop before being confirmed working and published, that's potentially valid grounds for not sharing details during that time (within reason), no?

Re: Dirty Frag: Universal Linux LPE

#172
post #77
post #60

Earlier quoted context omitted.

I don't think the copy.fail people understood the issue they found, as is evident by the heavy focus on AF_ALG/aead_algif, which is essentially "innocent" as we're seeing here. I think LLMs are great for vulnerability discovery, but you need to not skimp on the legwork and understanding what even you just found there.

Right but without the LLM the bug doesn't get found at all.

That's not necessarily true. Who's to say the security researchers wouldn't have found it if they'd searched the code manually?

Re: Dirty Frag: Universal Linux LPE

#173

Earlier quoted context omitted.

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

Sure, but distros not using systemd were not affected.

Re: Dirty Frag: Universal Linux LPE

#174

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…

Now I think about it, it's kinda weird if non-root users can cause kernel modules to get loaded, without any hardware changes having happened.

If the kernel modules for esp4, esp6 and rxrpc aren't loaded - how is it that a non-root attacker can cause them to get loaded?

Re: Dirty Frag: Universal Linux LPE

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

> Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline?

I always assumed that distro maintainers got early access to patches before going mainline but maybe that’s not true?

Re: Dirty Frag: Universal Linux LPE

#176
post #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?

So you think someone is going to break into your house, find your default credentials somehow and get root access?

Re: Dirty Frag: Universal Linux LPE

#177
post #172
post #77

Earlier quoted context omitted.

Right but without the LLM the bug doesn't get found at all.

That's not necessarily true. Who's to say the security researchers wouldn't have found it if they'd searched the code manually?

It would have taken a LOT longer but often this kind of manual search is so tedious people just don't do it. LLMs don't get bored.

Re: Dirty Frag: Universal Linux LPE

#179

Earlier quoted context omitted.

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

Sure, but distros not using systemd were not affected.

[deleted]

Re: Dirty Frag: Universal Linux LPE

#180
post #151

Ran as a fresh new default user in a ubuntu:latest container git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Result: dirtyfrag: failed (rc=3) Good news!

Wouldn't count on container being a reliable testing platform for this. Loads of stuff - legitimate or otherwise - fails in containers
Post reply on HN