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

211–220 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#211

Post by AshamedCaptain »

chuckadams wrote: post #108
TacticalCoder wrote: post #88

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

The entire argumentation here is ridiculous. There's a big jump from "IFUNC undermines RELRO" to "IFUNC is the issue". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, spawn a copy of sshd with a patched config if necessary.

Re: Dirty Frag: Universal Linux LPE

#213

Post by LelouBil »

echoangle wrote: post #184
cluckindan wrote: post #156

Earlier quoted context omitted.

So a threat actor buys access to a managed kubernetes service, or other linux-based shared hosting platform, and now they have access to the computer. Hell, GitHub Actions would do.

Is there any service that relies on Linux user separation or containers to separate different user accounts? I’m pretty sure you’re not supposed to do that and the proper way is to run different instances in virtual machines.

Right, you're not supposed to do that...

Re: Dirty Frag: Universal Linux LPE

#214

Post by staticassertion »

thayne wrote: post #207
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".

How would the attacker cause one of these modules to get loaded without already having root?

Trivially. Kernel modules autoload through various unprivileged mechanisms.

Re: Dirty Frag: Universal Linux LPE

#215

Post by sounds »

john_strinlai wrote: post #3

"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: " Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is t…

Is there any additional info on where it was "published publicly by an unrelated third party"? From the timeline in the writeup:

> 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.

> 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.

Edit: nevermind, details are further down in the thread:

https://openwall.com/lists/oss-security/2026/05/07/12

And

https://news.ycombinator.com/item?id=48055863

Re: Dirty Frag: Universal Linux LPE

#216

Post by staticassertion »

progval wrote: post #59
bawolff wrote: post #22

Earlier quoted context omitted.

Its not the reporter's fault that other people broke the embargo.

They don't have to publish a working exploit as soon as the embargo is broken, though.

An exploit was already published.

Re: Dirty Frag: Universal Linux LPE

#217

Post by spartanatreyu »

Tiberium wrote: post #4

Do you think with modern LLMs in a few years projects like Linux will have all those low-hanging security bugs fixed? Are we witnessing a transition period, or will nothing change?

LLMs don't matter, linux's codebase has been growing much faster than it can be secured so this is all inevitable.

Transitioning components to rust eliminates certain categories of bugs leaving the rest of the bugs to be dealt with.

We'd likely end up needing another language with stronger type and effect systems to eliminate more categories of bugs. Probably something which enforces linear types, capabilities, units of measure types, and effects.

And you'd have to update linux itself to switch to capabilities.

Re: Dirty Frag: Universal Linux LPE

#218

Post by [deleted] »

thayne wrote: post #207
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".

How would the attacker cause one of these modules to get loaded without already having root?

[deleted]

Re: Dirty Frag: Universal Linux LPE

#219

Post by croes »

lunar_rover wrote: post #160
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.

In many ways non mobile computers are very much still stuck in 1999. Android is significantly more secure than other Linux systems because it's much younger and had the chance to integrate mandatory access control into the entire stack.

Unless your Android doesn’t get any security updates anymore.

https://durovscode.com/google-android-security-update-warnin...

Re: Dirty Frag: Universal Linux LPE

#220

Post by aerodexis »

firer wrote: post #49
tptacek wrote: post #40

Earlier quoted context omitted.

I don't follow. LLMs spotted these bugs in the first place . You seem to be saying that these discoveries are indications that they're bad for vulnerability discovery.

From what I understand, the copy fail bug was found by researcher who noticed something weird and then using AI to scan the codebase for instances where that becomes a problem. I bet that with a slightly looser prompt/harness, the LLM could have found these twin bugs too. Yet at the same time, I also think that if the human researcher had manually scanned the code, he'd have noticed these bugs too. FWIW I do think LL…

They could also have found all these things at the same time - and are slow-rolling the disclosures.
Post reply on HN