New Linux glibc flaw lets attackers get root on major distros

https://www.bleepingcomputer.com/news/security/new-linux-glibc-flaw-lets-attackers-get-root-on-major-distros/

by PaulHoule • 2 years ago

166 99 2 years ago

tomsmeding• 2 years ago

Duplicate, more discussion here: https://news.ycombinator.com/item?id=39194093

wslh• 2 years ago

I have not found Rust mentioned there. Am I right if we say that using Rust will reduce the security attack surface in Linux? I see now it is mentioned in this thread and there are different views about this.

tialaramex• 2 years ago

The obvious ways to do this in Rust are safe, on the other hand, if you write some Rust where all it does is call this glibc function then Rust didn't magically save you because the function is broken. Does that help?

smolder• 2 years ago

Being that it is a buffer overflow, yes, if glibc were in Rust I think it shouldn't have happened. I believe I saw a libc reimplementation project in Rust, but that's a big effort and not something I would expect to be drop-in for a long time. That said, I think we should try to avoid turning every vulnerability discussion into one about the merits of Rewriting it in Rust.

shirro• 2 years ago

Memory safety isn't exclusive to Rust. Language designers and implementers solved these problems years ago with safer languages (better type systems, removing pointers) or safer runtimes (jvm, .net etc). Rust is notable because it brings a lot of prior art together in one place and the compiler prevents most problems at compile time. As long as programmers don't use unsafe Rust it can produce safer code without runtime overhead. There are a lot of safer languages than C. Not all are suitable for writing system libraries.

nextaccountic• 2 years ago

Yes, but only if the relevant code can be written in Safe Rust (that is, without using unsafe). This is not always a given, but surprisingly, a huge amount of code can be written in Safe Rust and therefore won't have buffer overflows.

GoblinSlayer6• 2 years ago

FWIW C can do it too to some extent, here's postfix: https://github.com/vdukhovni/postfix/blob/master/postfix/src...

cutler• 2 years ago

Just curious whether Rust would have averted these issues?

voxl• 2 years ago

The answer is probably yes. The issue is caused by a heap-memory overflow. In Rust, if you're storing an array on the heap then there will be bounds checks on the array access. If you're using a vec then it would automatically grow (so again bounds checks).

ape4• 2 years ago

It would be quite something to rewrite glibc in Rust! Of course, its the C/C++ run time.

loeg4• 2 years ago

Yeah, unless you bypassed the bounds checking with unsafe{} for performance reasons. (The is an unlikely place to do so.)

uecker3• 2 years ago

There was a similar bug in the past in Rust: Integer overflow causing a buffer overflow: https://github.com/rust-lang/rust/pull/54399/commits/8ac88d3...

So the answer is: Not necessarily. I agree though that the memory safety features in Rust would help reduce the risk. On the other hand, one could also write safer C by abstracting away buffer management. The world is not black and white.

ajross4• 2 years ago

It's actually questionable. The vulnerable code is described really well in the Qualys report: https://www.qualys.com/2024/01/30/cve-2023-6246/syslog.txt

Basically: the code was an optimization trying to avoid a heap allocation by using a stack buffer instead, but its fallback for "it doesn't fit in 1k of stack memory" wasn't tested and didn't work right.

Rust struggles with alloca-style code too, to the extent that users who want to do this kind of trickery usually resort to unsafe. There's a link elsewhere in this topic to a Rust library vulnerability that looks similar.

The upshot is that if the code had been written idiomatically and just used the heap like it was supposed to, it probably would have worked fine. The glibc authors got fancy, loaded a footgun, and it went off, something that Rust is equally capable of.

WhereIsTheTruth2• 2 years ago

rust disables bound checking in the release builds, so no, you are wrong

foobiekr3• 2 years ago

There's a kind of naive thing going on on HN where peopel see a bug and ask whether or assert Rust will fix it. The problem is they are homing in on just the bugs Rust addresses - this is fine, I've had this conversation at work (not involving Rust, even) for two decades, including discussions about Java.

The problem is that Rust solves _a_ class of issues without even beginning to address other kinds of problems, and so this sort of thinking is evolving toward a mindset that "oh it's rust so no security issues", which is completely wrong.

eichin• 2 years ago

Perhaps an innoculation against this is to respond "Yes, but so would Ada"

IshKebab2• 2 years ago

I don't think so. Rust solve a class of security issue, but that class is 2/3 of all security issues! That's overwhelmingly more secure.

And it's not like it has no effect on the final third either. The stronger type system and ownership system make non-memory related bugs less likely too.

Your comment makes it sound as if you have a better solution. But Rust is the best one we know so far, so this kind of naysaying does more harm than good.

spookie• 2 years ago

This makes me think the musl people are right. Glibc is quite a large attack surface.

loeg4• 2 years ago

Fwiw, the analogous logic in musl libc[1] uses log_ident set to the empty string if openlog() was called with NULL ident[2]. It also formats twice to buf[1024] without checking that the first format's length isn't in excess of the stack buffer but that's likely always safe given how short the stuff printed in the first format is.

[1] https://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c#n...

[2] https://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c#n...

knorker3• 2 years ago

Interesting. The first snprintf() could return a negative value (at least by the glibc snprintf manpage), and then therefore the second vsnprintf will overwrite... something.

Maybe their implementation can't return negative, or only if the fmt string (constant, here) is invalid? I wouldn't count on it, especially of it being true forever. That's pretty sloppy code.

o11c2• 2 years ago

More relevant, it caps `log_ident` to a very short length. If my math is correct, the max length of the first snprintf is 72 bytes (actually less with real-world valid PIDs), and the buffer is 1024.

As usual, MUSL is secure at the cost of giving up usefulness. A 32-byte buffer might seem like a lot, but there are dozens of programs with a name longer than 31 bytes on my system. `dbus-update-activation-environment` is the most interesting (most others are gcc/binutils), and I know dbus in general uses syslog, though I haven't traced this particular entry point.

snvzz3• 2 years ago

In a sane world, most distributions would have long switched to musl and libressl, from glibc and openssl.

Arnavion• 2 years ago

Distributions can't switch to libressl until all the software they package also supports it. libressl is incompatible with openssl, so programs that are compiled against the one cannot run against the other, and both cannot be loaded into the same address space. That's why the few distributions that did switch to libressl eventually switched back.

GoblinSlayer6• 2 years ago

I wonder. su called PAM to authenticate the user, PAM called syslog to log authentication failure. Even if syslog was in another library, it would still be called, you would just have more libraries.

PhilipRoman2• 2 years ago

Meh, local privilege escalation.

I think by now everyone has accepted that the Unix/Linux account system is insecure by design and exists just to prevent accidental damage.

There are ways to restrict it but the default configuration simply exposes too much of an attack surface. I still give separate accounts to some services as defense in depth, but it mostly exists to slow down untargeted attacks.

smarkov• 2 years ago

What's the preferred method of limiting permissions then? Virtualization? Containerization? AppArmor?

christophilus• 2 years ago

I use containerization, but it’s not perfect. Also on the front page today: https://news.ycombinator.com/item?id=39250975

PhilipRoman2• 2 years ago

For normal services namespaces are enough (make sure to set no_new_privs, one of the best Linux features). Run it with the bare minimum of mounts required, no shared /tmp, etc. For all its faults, systemd actually gets this right, by allowing to easily harden services.

Note that this exploit relies on being able to run as root (typically through setuid). If you don't fully trust a service, don't let it ever talk to code running as root in the first place. No opening sockets in /tmp, no listing processes in /proc, no dbus shenanigans, no sudo or su. One of this issues with this was that some programs require setuid for bad reasons (IIRC historically ping was setuid to be able to send ICMP packets). From a quick check (find -type f -perm -4000) most of these problems have been eliminated, via linux capabilities or otherwise.

These tactics successfully saved me from log4shell.

worksonmine• 2 years ago

Depends on what you want to achieve. AppArmor/SELinux prevent access to files and directories. Virtualization and containerization tries to build a jail. You can combine the solutions, a container running a distro with SELinux like any from the Red Hat ecosystem.

They have all had vulnerabilities, My preferred method is to not install stuff I don't need, and fix any dangerous configuration for the programs I do need. I prefer Podman over Docker because of rootless for example.

marcosdumay• 2 years ago

Containerization doesn't protect at all against privilege escalation. And AppArmor is a very partial improvement.

The way to protect against this is with an external supervisor. But then you have to care about privilege escalations attacks against the supervisor. Hopefully that one is much simpler than Linux so it has much fewer vulnerabilities.

tempmac• 2 years ago

extra laptops/servers...? meh

dmm• 2 years ago

On Linux, Chromium uses setuid or user namespaces to restrict the access of sandboxed components and seccomp-bpf to reduce the kernel attack surface.

Check out the Chromium docs on this topic: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...

blibble2• 2 years ago

at this point I think it's beyond clear any setuid root binaries shouldn't be written in C

hannob• 2 years ago

I mean, I don't disagree, but it probably would not have helped in this case.

This is based on a buffer overflow in glibc itself. It is my understanding that rust still calls into libc for many lowlevel system functions. And if you call C code from rust, well, it's still C code with C code bugs.

Ultimately, if you want to get rid of those, you'd have to rewrite the libc in Rust.

blibble2• 2 years ago

I very much doubt a rust program is going to pull in glibc syslog()

in this case it was in a pam module

and dynamic modules loaded into setuid binaries (pam/nss/...) are also super-high risk and should be memory safe too

grayhatter3• 2 years ago

Ultimately, if you want to get rid of those, you'd have to rewrite the libc in Rust.

No, you can eliminate these bugs by getting better at writing code. The language is independent from the quality of any given code.

Rust is capable of introducing theses bugs, but the language is more explicit when you do. One languages isn't more secure than another. They each attempt to fill a niche, some trade language usability for correctness, some trade correctness for being easy to use.

wongarsu2• 2 years ago

Given the unix philosophy of providing important functionality only in the c runtime library and having all software dynamically link against it, wouldn't the most crucial step in this be to replace glibc with an implementation that isn't written in C?

pjmlp6• 2 years ago

UNIX philosophy has nothing to do with dynamic linking, in fact during the first decade of its existence only static linking was available.

hossbeast• 2 years ago

You are conflating C with glibc

fulafel• 2 years ago

If your setuid program links to glibc and uses the logging there, then you are incorporating glibc into your setuid program. You could also not do that.

tremon• 2 years ago

"Although [$reasons], we decided to not pursue this avenue of exploitation, because:"

I see lots of ground for further research.

(from https://www.qualys.com/2024/01/30/cve-2023-6246/syslog.txt, the article from the duplicate HN thread)

charcircuit• 2 years ago

There is 0 reasons to have setuid binaries. Additionally, having users escalate a program to root, with no restrictions on what root can do, is even worse. setuid is a total hack and is embarrassing how many Linux distros are using it.

PlutoIsAPlanet• 2 years ago

How are users supposed to change their password?

rleigh• 2 years ago

While using a setuid binary to edit the password/group "databases" is the historical default, there's no real technical reason why it must be that way. The passwd program could communicate with the database service via a socket. Likewise the NSS and PAM stuff could communicate with the same service via a socket. No reason for it to be lots of in-process loadable modules in this day and age.

deathanatos3• 2 years ago

… this C is code is just a case exemplar of the problems with C.

We have `l` and `1` being used in the same passage. Single letter variables are bad to start with, but `l` is particularly cursed since, if you happen to be using a font where `l` and `1` are homoglyphs, good luck reading that passage. But that's sadly the default in a number of OSes/environments, and indeed, the site this code is hosted on. One might presume `l` stands for length, … but there's also `vl`, `bufsize` and `sizeof bufs`. `bufs` and `buf`, although the former, `bufs`, is a singular buffer, leading one to wonder why the variable name is pluralized. I'm pretty such it's because it's stack-allocated (as opposed to the heap alloc'd `buf`, and thus `bufs` is "buf[fer], s[tack]". This is just nuts, and it should be no surprise there are multiple CVEs.

The OG code was had CVEs. The commit that "introduced" this — which I almost feel is wrong to say — attempted to use `bufsize` for the buffer size, which certainly feels more right that the OG, but alas, the variable is never meaningfully initialized. This CVE is on the patch to fix a CVE! And in the original CVE's bug report, the ominous words of "Doesn't seem too serious" were uttered.

I'm sure it's fixed now, though, right?

syslog is just a bad interface logging interface, to boot.

GoblinSlayer6• 2 years ago

Even Comic Sans differentiates between l and 1. I wonder how many confuse them.

New Linux glibc flaw lets attackers get root on major distros

Related Stories