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

71–80 of 370 posts

Re: Dirty Frag: Universal Linux LPE

#71

Post by john_strinlai »

dundarious wrote: post #65
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…

You can't sudo echo and redirect from the non-sudo shell like that. echo 3 | sudo tee /proc/sys/vm/drop_caches or sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' Also fixed your typo in /proc...

thanks. copy pasting from the github via my phone, and should have taken the extra few mins

Re: Dirty Frag: Universal Linux LPE

#72

Post by miduil »

synack wrote: post #48
oncallthrow wrote: post #17

can this also be used to obtain container escape ?

If your container has setuid binaries and these modules are loaded, yes.

It's poisoning the filesystem cache, if you don't have a setuid binary handy you just poison anything else that gets executed by the host.

Re: Dirty Frag: Universal Linux LPE

#73

Post by stevenhuang »

pjmlp wrote: post #43
grosswait wrote: post #24

Earlier quoted context omitted.

It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.

No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land. Some folks like the termux rebels, occasionally find out there is a sherif in town. > As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code…

That's all user space platform specifics, it has no relation to your previous statement where you said 'android is not linux'.

Someone can statically build a freestanding executable/so targetting arm64 linux (specifically the right android linux kernel version) and it will run fine on Android. The syscall interface, process model, file descriptors, signals, memory mapping, all of this is Linux, this is what people mean when they say Android is just Linux.

Re: Dirty Frag: Universal Linux LPE

#74

Post by vsgherzi »

unethical_ban wrote: post #12

Here's a general question, are these vulnerabilities hitting Linux more than BSDs due to hit being a larger target or because its architecture is less secure by design?

It’s two things. 1. Less eyes are on the bsds

2. Bsds don’t have the same optimizations that Linux has. Bsds generally try to pursue corrrectness

That being said there were just a bunch of vulnerabilities in freebsd

macOS has had its own dirty cow attack and I know there’s for sure more memory ones just based on the way the xnu kernel works.

So no Linux isn’t really worse per say

Re: Dirty Frag: Universal Linux LPE

#77

Post by tptacek »

eqvinox wrote: post #60
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.

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.

Re: Dirty Frag: Universal Linux LPE

#78

Post by lofaszvanitt »

jacobgkau wrote: post #38
john_strinlai wrote: post #15

Earlier quoted context omitted.

it was published publicly by an unrelated third party

They're asking the nature of the third party's discovery/publishing. Someone on the inside who decided to leak it anonymously? Someone else who was able to access some private communication they shouldn't have been able to see? Or a third party who happened to discover the same vulnerability (which seems less unlikely than normal since this is so similar to Copy Fail), but didn't follow disclosure procedures?

Following disclosure procedures? The main cause that kills the need to take security seriously.

Re: Dirty Frag: Universal Linux LPE

#79

Post by lofaszvanitt »

flumpcakes wrote: post #11
baggy_trough wrote: post #2

Disclosure Timeline 2026-04-29: Submitted detailed information about the rxrpc vulnerability and a weaponized exploit that achieves root privileges on Ubuntu to security@kernel.org. 2026-04-29: Submitted the patch for the rxrpc vulnerability to the netdev mailing list. Information about this issue was published publicly. 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-d…

7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.

WTF cares? Publish them without disclosure is the true way, otherwise noone would care about security and your data.

Re: Dirty Frag: Universal Linux LPE

#80

Post by formerly_proven »

firer wrote: post #32
formerly_proven wrote: post #31

Earlier quoted context omitted.

These are all page cache poisoning attacks (dirtyfrag, copyfail, dirtypipe). Maybe the page cache should have defense-in-depth measures for SUID binaries?

SUID mitigations have nothing to do with the vulnerability itself - just the exploit. If there's a root cronjob that runs a world readable binary, you could modify it in the page cache and exploit it that way. Modifying the page cache is a really strong primitive with countless ways to exploit it.

True! Building protections (e.g. physical pages in the page cache are not writeable 100% of the time) just for executables has of course countless circumventions as well (e.g. config files). Yeah, there is probably not that much to be done there, actually. Looking at some of the diffs it seems to me like the kernel makes it really not particularly obvious when/how this goes wrong. E.g. the patch for this is to look at an additional flag on the socket buffer to fix an arbitrary page cache write. This feels rather action at a distance. Logically this of course makes sense, the whole point of splice et al is to feed data from one file-like into another file-like, whatever those ends might be. That erases the underlying provenance of the data.
Post reply on HN