Live data from Hacker News

Dirty Frag: Universal Linux LPE

openwall.com

341–350 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#341
post #92

Earlier quoted context omitted.

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

Yes that is reasonable, but dispensing with all on machine controls is not.

isn't root level access one of the selling points of the cloud vm product line?

Re: Dirty Frag: Universal Linux LPE

#342

Earlier quoted context omitted.

It's weird to say I want to "die on this hill" because that's not even something I believe. There was nothing especially difficult about this particular vulnerability. My only observation that nobody did find it before, then an LLM security firm went out looking for Linux LPEs, and thus it was discovered. That is a very difficult fact pattern to which to attach the conclusion "LLMs have sabotaged security research" (…

The finding started with human intuition and was assisted by an LLM. You can yell "AI sec firm" 1000 times. A human got it started. You shouldn't die on that hill.

Of the MANY things I've completed in the last year that I would never have done without an LLM, a human got 100% of them started. The ideas were mine in every case.

But it is still a fact that I have been taking on all sorts of tasks I would never have taken on if I didn't have power tools.

Re: Dirty Frag: Universal Linux LPE

#343
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?

I haven't updated mine. I have a firewall and it's not exposed to the Internet. Need a key to SSH in. Same with my public facing server. Almost none of these exploits are "drop everything now and patch" unless you are somehow exposing yourself stupidly.

It's a "drop everything and patch" if you have a large multi-user server where you don't completely trust all of the users. Like say in a university with a server that students can log in to, like I have just had the joy of updating (and had RHEL break ZFS on me yet again).

But yes, in most other cases no it isn't a "drop everything" exploit - but it does mean one less layer in the multi-layer security, as unprivileged remote exploits now become root-access remote exploits.

Re: Dirty Frag: Universal Linux LPE

#345

Earlier quoted context omitted.

Not of the host system, assuming we're talking about a compromised VM, running as a non-root user.

I assume you mean container, not VM. But yes, container makes it harder.

Worth adding also that you can only use these vectors to corrupt the page cache for files reachable in your mount namespace.

Usually with containers, almost nothing is shared with the host namespaces (tho likely shared with other container namespaces, hopefully none of those are --priv).

Re: Dirty Frag: Universal Linux LPE

#347

Earlier quoted context omitted.

What are the differences? I think of both as Unix-type sytems with macrokernels. I have no practical experience with BSDs.

Jeez, care to reply instead of downvoting? I would really like to know. I do keep an eye on the BSDs as a good example in some areas where Linux is bad.

Didn't downvote. But if you don't know the difference, then you seemed pretty confident in describing their differences.

BSDs are an actual fork of UNIX from the 90s. Linux is a kernel whose code is not forked from UNIX. The userland is most often GNU, which stands for GNU's Not Unix.

Re: Dirty Frag: Universal Linux LPE

#348
post #29
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…

No, unless I'm misreading it it's the *same* root cause: high 32 bits of Extended ESN in IPsec == authencesn module/cipher mode. The wrong thing got fixed for copy.fail, because people jumped to blame AF_ALG. [ed.: yes it's the same authencesn issue. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... it doesn't say authencesn in the code, only in a comment, but nonetheless, same issue.] [ed.2: the RxRPC…

But if dirtyfrag is mitigated, copyfail is still active...
Post reply on HN