231–240 of 370 posts
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?
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.
This would reduce the amount of ring 0 code. But I've never seen such advice.
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)?
"XFRM SA registration requires CAP_NET_ADMIN".
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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 me…
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!
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 som…
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.
Earlier quoted context omitted.
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…
As for termux,