Top
Best
New

Posted by flipped 16 hours ago

Dirtyfrag: Universal Linux LPE(www.openwall.com)
664 points | 272 commentspage 2
fulafel 7 hours ago|
Both of these (copy fail and dirtyfrag) exploit obscure socket address families. Are these filtered by commonly used seccomp profiles in eg docker (assuming seccomp can express it)?
YZF 6 hours ago|
At least in the k8s setup I looked at the dirtyfrag were filtered (by default).

"XFRM SA registration requires CAP_NET_ADMIN".

RandomGerm4n 4 hours ago||
Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits. For most users a system with a kernel as minimalistic as the Android GKI kernel combined with sensible SELinux policies, would likely be sufficient.
fulafel 4 hours ago|
Both of the modules are (also) for desktop/workstation use. Though AFS could probably be retired generally.
hughw 12 hours ago||
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!
stsewd 11 hours ago||
I got the same running it inside a container, but got a shell when running it directly in the host. This only shows that the exploit doesn't work inside a container. So, containers aren't vulnerable, or the script needs some adjustments to make it work in containers.

Since copy fail can be used to escape containers (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), I'm guessing the exploit needs some changes only.

cyphar 6 hours ago||
The repo you linked works by replacing files that are being used by other privileged containers on the same system. That works for the Kubernetes case (I'm a little surprised they don't use static binaries for their own privileged containers, seems a little dangerous to share any kind of data with untrusted tenants even if it's read-only) but not standalone containers.

However, there is a much an easier way of doing a breakout -- you can corrupt the host runc binary in a way analogous to CVE-2019-5736. The next time a container is spawned, the host runc binary will get run as as root and that's that.

Ironically, the first version of the protection against this attack I wrote also protected against page cache poisoning (by making a temporary copy of the runc binary during container setup in a sealed memfd and re-execing that) but the runtime cost of copying a 10MB binary at container startup was seen as too expensive by some users[1] so we ended up with a setup that shares the same page cache. I also distinctly remember arguing at the time that something like Dirty Cow could always happen in the future, and the memfd approach was better for that reason -- maybe I should've stuck to my guns more... :/

In practice the solution for containers is to update your seccomp policy to block the vulnerable syscall.

[1]: https://github.com/opencontainers/runc/issues/1980

Havoc 12 hours ago||
Wouldn't count on container being a reliable testing platform for this. Loads of stuff - legitimate or otherwise - fails in containers
miduil 15 hours ago||
This again does not work under Android, at least in termux compiled with clang/gcc.
staticassertion 15 hours ago||
I assume because the rxrpc module is not loaded / provided and because unprivileged user namespaces are not allowed, which should be sufficient to mitigate. Curious if someone else has more details though.
jeroenhd 13 hours ago|||
The exploit as posted contains x86 shellcode, so you'd need to drop in the appropriate shellcode to test if it really works.

Android wasn't vulnerable the last time, so far it's been a shining beacon of hope for proper SELinux configuration that I wish was more widely available in other places.

ronsor 15 hours ago|||
Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
miduil 15 hours ago|||
Yes, it demonstrates that it's possible to harden well - at least for some cases. It appears depending on the environment hardened kernel / runtime environments are pretty much possible to have safeguards working today already.
__float 13 hours ago||||
> desktop Linux doesn't (and won't for UX reasons)

Can you elaborate?

mike_hearn 3 hours ago|||
Locking down a desktop OS to modern standards really requires what Apple did with macOS, which requires a degree of central coordination that's beyond the Linux community. It mandates huge changes in almost every area of the OS stack, and all apps have to be sandboxed by default out of the box.

Developers don't like mandatory sandboxing. It has to be forced on them. So you can see the difficulty of doing it in the open source community, which has for decades now had the worst security of any desktop OS platform (even Windows is better).

akdev1l 13 hours ago||||
A very comprehensive SELinux deployment for one.

SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.

lunar_rover 12 hours ago||||
To solve the issue from the source, you need to enforce security through means like mandatory access control. The problem is that existing desktop and server systems are too mature for that to be practical, you'll have to rework almost everything and users will certainly reject it violently due to the breakages.
mike_hearn 3 hours ago||
Apple have shown it can be done with macOS. Not only is every app sandboxed in a usefully robust way (even ones distributed outside the app store) but this has been done in a way smooth enough that users didn't revolt.
danudey 13 hours ago|||
Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc.

Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.

croes 9 hours ago|||
Android has other problems

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

pjmlp 15 hours ago||
Because Android is not Linux, as much as some pretend it is.

In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.

grosswait 15 hours ago||
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.
akdev1l 13 hours ago|||
The JVM has nothing to do with Android. There is no JVM running android apps.

There was Dalvik VM at one point but now it’s just the Android Runtime.

pjmlp 15 hours ago|||
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 can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.

https://android-developers.googleblog.com/2016/06/improving-...

These stable APIs,

https://developer.android.com/ndk/guides/stable_apis

tadfisher 13 hours ago|||
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...

pjmlp 6 hours ago||
Yes, at which point it isn't GNU/Linux, rather something else built on top of the Linux kernel.

As for termux,

https://wiki.termux.com/wiki/Termux_Google_Play

stevenhuang 14 hours ago||||
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.

pjmlp 6 hours ago||
Yes, exactly PlayStore isn't GNU/Linux, normies don't use ADB.
dzaima 15 hours ago||||
That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way)

Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)

esseph 15 hours ago||||
https://www.androidpolice.com/google-support-linux-kernels-a...

Google relies on Linux LTS kernels. When the Linux LTS team dropped support from 6 years down to 2 years, Google stepped in to cover the 4-year gap.

It is Linux. It's basically a distro.

pjmlp 6 hours ago||
When people say Linux they mean GNU/Linux.
cyphar 6 hours ago|||
In common parlance, yes -- because there is no practical distinction. But in cases where something is just using the Linux kernel without GNU and other common userpand components (and there is a practical distinction) then it's definitionally untrue to say that it's "not Linux" if you really meant to say "it's not GNU/Linux".
nonameiguess 3 hours ago|||
Alpine Linux is not using GNU. I'm sure there are others. No definition you can ever come up with will have no exceptions in widespread use. Live with it.
anthk 13 hours ago|||
- Waydroid

- Is totally Linux

eqvinox 14 hours ago||
If you don't need it (rootless containers), you can disable unprivileged userns to block these two:

  echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns
May also break sandboxes (e.g. browser) though.
netheril96 10 hours ago||
We need an easy way to ensure that only kernel modules in an whitelist can load. I’m tired of blacklisting modules I never need.
bytejanitor 3 hours ago||
Is there a CVE identifier available for this yet?
zepearl 15 hours ago||
So if I understand correctly 3 modules are involved:

- esp4 (kernel config "CONFIG_AF_RXRPC")

- esp6 (kernel config "CONFIG_INET_ESP")

- rxrpc (kernel config "CONFIG_INET6_ESP")

Is this correct?

eqvinox 15 hours ago|
You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.
zepearl 14 hours ago||
damn you're right, thx
kinow 13 hours ago|
Just got an email from one HPC I have access in Germany. I guess all HPCs ans services like GH Actions are going to be offline for a bit. I think last time was on a Friday too, so it might be another Friday to organize emails, files, rotate backup/passwords...
More comments...