Tested Amazon Linux 2023 and it doesn't appear to be vulnerable in the default configuration. Would be interested if anyone finds anything different.
Dirty Frag: Universal Linux LPE
111–120 of 370 posts
Re: Dirty Frag: Universal Linux LPE
#112Earlier quoted context omitted.
AFAIU, Linux and the BSDs have basically the same architecture - the BSDs just value secure and simple, understandable code more highly than Linux vs features and performance.
This is really not a correct statement beyond the fact that both are a type of Unix.
Linux is not Unix: it is not derived from AT&T Unix.
Re: Dirty Frag: Universal Linux LPE
#113[dead]
Re: Dirty Frag: Universal Linux LPE
#114[dead]
Re: Dirty Frag: Universal Linux LPE
#115Earlier quoted context omitted.
No, they did not. Careful of falling for the psychosis. > This finding was AI-assisted, but began with an insight from Theori researcher Taeyang Lee, who was studying how the Linux crypto subsystem interacts with page-cache-backed data. https://xint.io/blog/copy-fail-linux-distributions
Theori is an AI security research firm.
It seems as though this issue occurred to him, then he used their tool ("Xint Code") to analyze the codebase for instances of it.
Re: Dirty Frag: Universal Linux LPE
#116If 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.
It’s not enabled by default. It’s an optional module that is loaded on demand. The entire setup of the kernel promotes compiling in the core set of things your users will need and offering basically everything else as a module to load on demand.
Re: Dirty Frag: Universal Linux LPE
#117Earlier 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…
What's amazing about Linux is that you don't have to use the system's libc, and you don't have to use dynamic linking.
That said, newer Androids use seccomp to restrict which syscalls you can use, basically to what bionic exposes anyway. This doesn't seem to affect Termux and friends, which can apparently run full X11 applications without root.
(edit) Notably, splice() is still callable, so maybe the POC needs to be tweaked...
Re: Dirty Frag: Universal Linux LPE
#118"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…
Just FYI, you can also mitigate it with `echo 1 > ...`; you don't need to drop everything, dropping `1` clears the page cache and that's enough.
Tested locally on Ubuntu 26.04:
1. Ran the exploit and got root
2. Configured the mitigations
3. Ran `su` again with no parameters and immediately got root again unprompted
4. Cleared the page cache
5. `su` asked for a password
Re: Dirty Frag: Universal Linux LPE
#119If 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 said a target for an easy win here is RHEL, which compiles a lot of modules into the kernel rather than leaving them as loadable modules, so the mitigation for e.g. copy fail was impossible. Maybe they could do with a few less of those?