I’m really tired of these constant flag days where we rediscover that components of everything that are written in C are vulnerable to easily triggerable subtle bugs.
“No way to prevent this” says users of only programming language where this regularly happens
When will enough be enough and we start implementing libc in a sane language?
Or make the suid binary not runnable AT ALL by non wheel group members. There is a NixOS option that does this, which makes sudo exit with an error, handled by the kernel. This solves all suid related vulnerabilities.
security.wrappers = let
owner = "root";
group = if cfg.execWheelOnly then "wheel" else "root";
setuid = true;
permissions = if cfg.execWheelOnly then "u+rx,g+x" else "u+rx,g+x,o+x";
in {
For folks looking for the full advisory, it’s at https://www.qualys.com/2024/01/30/cve-2023-6246/syslog.txt
Time to rewrite glibc in Rust ???
https://lobste.rs/s/hces2w/baby_steps_slowly_porting_musl_rust and https://github.com/sunfishcode/c-ward are relevant, although glibc would be a greater task.
that would be relibc
That would certainly be interesting, and expose a C API that programs can link to. Hell, it would be amazing.
Nobody actually likes writing C, they cope or write macros instead.
I’m really tired of these constant flag days where we rediscover that components of everything that are written in C are vulnerable to easily triggerable subtle bugs.
When will enough be enough and we start implementing libc in a sane language?
We can do that, however I’ll claim that not just the implementation but also the interface of libc in general and glibc in parti ular is busted.
Glibc is a random grab-bag of stuff that was added over the decades, including but not limited to
Do most programs need POSIX collation? Termios? monetary.h??? Why am I pulling in all that crap just to get a fast memset?
libc in rust (unfinished): https://gitlab.redox-os.org/redox-os/relibc
Suid binaries are evil.
They can be run in very different initial conditions, and thus make paths in code that are not designed for this available for execution.
Instead of such binaries, one should make services that can be run from root, under well-known initial conditions.
In https://stal-ix.github.io / we don’t have any suid binaries in system, even sudo works as ssh client + local ssh daemon.
Or make the suid binary not runnable AT ALL by non wheel group members. There is a NixOS option that does this, which makes sudo exit with an error, handled by the kernel. This solves all suid related vulnerabilities.
I’m not sure how it is done on other distros, but it’s
security.sudo.execWheelOnlyon NixOS: https://github.com/RGBCube/NixOSConfiguration/blob/master/modules%2Fsudo.nix#L17Suid binaries are definitely not evil.
This sounds like it just sets the permissions to
rwsr-xr--.The implementation of
execWheelOnly:So, you seem to be correct.
Is a suid binary a requisite for this flaw to be exploited?
It would be quite unusual for a daemon to be started with an overflowing argv0 by other means.
Not that weird though. For example some services will create per-slice/task/customer processes that change the argv0 to include the identifier.
Thanks for expanding! I found the linked article about light on these details.
Ah, so that would explain why I just saw a glibc update for my Fedora 39 install today.
I had wondered what prompted that.