For your convenience:
The researchers pointed out that the vulnerability cannot be exploited remotely. An attacker can trigger the issue by providing crafted inputs to applications that employ these [syslog] logging functions [in apps that allow the user to feed crafted data to those functions].
This is a privilege escalation.
This may be difficult to exploit in practice - I don’t think most user applications use syslog.
Unless you have user access to a system with gcc on it.
"A qsort vulnerability is due to a missing bounds check and can lead to memory corruption. It has been present in all versions of glibc since 1992. "
This one amazes me. Imagine how many vulnerabilities future researchers will discover in ancient software that persisted/persist for decades.
That’s not the main part of the article, just a footnote, for anyone wondering.
The flaw resides in the glibc’s syslog function, an attacker can exploit the flaw to gain root access through a privilege escalation.
The vulnerability was introduced in glibc 2.37 in August 2022.
So, it must be with the BSDs too?
BSDs use libc
Iirc bad does not use glibc, but I’m not very involved with BSD.
It wouldn’t make sense. Glibc is LGPL licensed, not really compatible with the BSD license…
Wait, why has a compiler system log functionlity?
glibc is a library, gcc is the compiler.
You are probably confusing the glibc with gcc and g++. Glibc is an implementation of the C standard library, made by GNU (thats where the g in the name comes from).
If you were to look into it, it uses the syscalls to tell the underlying computer system what to do when you call functions, such as
printf.If you want to read more, see here
C is just crazy. You accidentally forget to put the bounds in a sorting function, and now you are root.
According to the link in the article, the qsort() bug can only be triggered with a non-transitive cmp() function. Would such a cmp function ever be useful?
You don’t necessarily have to write a non-transitive cmp() function willingly, it may happen that you write one without realizing due to some edge cases where it’s not transitive.
Debian (versions 12 and 13), Ubuntu (23.04 and 23.10), and Fedora (37 to 39). Other distributions are probably also impacted.
Patch time
https://security-tracker.debian.org/tracker/CVE-2023-6246
Don’t know if Fedora has any similar easy way of tracking vulnerabilities
12 and 13 have patches out in the security repo. Apt update && apt upgrade fixed it right up.
Let’s go Musl!
meanwhile rust
Doesn’t compile where musl does.
While there may be challenges and specific configurations required, you absolutely can compile Rust on and targeting to a musl-based system.
I meant, Rust suppports vewer architectures.
Rust actually supports most architectures(SPARC, AMD64/x86-64, ARM, PowerPC, RISC-V, and AMDGPU*). The limitations are from LLVM not supporting some architects(Alpha, SuperH, and VAX) and some instruction sets(sse2, etc.); z/Architecture is a bit of an outlier that has major challenges to overcome for LLVM-Rust. This is not going to be a problem when GCC-Rust is finished.
AMDGPU, *Not 100%, but works well enough to actually use in production and gets better all the time.
Thanks! My bad, sorry.
Np. It’s a common point of confusion.
You can userustup target listto see all available architectures and targets.
The vulnerability is on logs, and that has nothing related to the library. Even less with the language…
The vulnerability is in the library’s logging function, which is coded in the C language. musl is also C (afaik), it’s just a more modern, safer rewrite of libc.
I’m not sure what you mean by a “vulnerability in the logs”. In a logger or parser, sure, but did you think text data at rest was able to reach out and attack your system?
True, the logging is part of the library, but it’s totally centered on what the developers are logging. It’s a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn’t mean the library is broken and has to be replaced. The library’s logs need to be audited, and this as true for glibc as it is for musl, no exception, and it’s not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).
BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that’s not a syntactic error, and it’s not violating any compiling rules. It’s that something is logged that shouldn’t.
Also, the report indicates that the vulnerability can’t be exploited remotely, which reduces the risk for several systems…
The vulnerability has nothing to do with accidentally logging sensitive information, but crafting a special payload to be logged which gets glibc to write memory it isn’t supposed to write into because it didn’t allocate memory properly. glibc goes too far outside of the scope of its allocation and writes into other memory regions, which an attacked could carefully hand craft to look how they want.
Other languages wouldn’t have this issue because
-
they wouldn’t willy nilly allocate a pointer directly like this, but rather make a safer abstraction type on top (like a C++ vector), and
-
they’d have bounds checking when the compiler can’t prove you can go outside of valid memory regions. (Manually calling .at() in C++, or even better - using a language like rust which makes bounds checks default and unchecked access be opt in with a special method).
Edit: C’s bad security is well known - it’s the primary motivator for introducing rust into the kernel. Google / Microsoft both report 70% of their security vulnerabilities come from C specific issues, curl maintainer talks about how they use different sanitizers and best practices and still run into the same issues, and even ubiquitous and security critical libraries and tools like sudo + polkit suffer from them regularly.
I see, I didn’t dig into the cause, being sort of a buffer overflow. Indeed that would be prevented by other languages, sorry for my misinterpretation. Other vulnerabilities unintentionally introduced by developers on logging what shouldn’t are not dependent on anything other than auditing them, but that was not the case then.
-
musl is not a programming language
That’s why I said library or language (someone else suggested rust).
Yikes.
I’d switch to musl on all of my boxes if it weren’t that nearly all precompiled software (closed source, games mainly) are compiled against glibc.
Just use flatpak and podman, in a punch you can proot into a different system / zfs data set / btrfs sublime
I replied to another comment with this, but Debian 12(stable, bookworm) and 13(testing, trixie) are affected by this but 12(stable, bookworm) has a patch out in the security repo.
If you wanna know wether or not you’re affected,
apt list libc
will show your version and the one you want is 2.36-9+deb12u4
If you don’t have that,
apt update && apt upgrade
will straighten you out
13(testing, trixie) has 2.37, but it’s not fixed yet.
E: Edited to use apt list instead of apt show.
Local attacker
Important detail
as i said on reddit
“GNU Library C?”
GNU C Library(glibc) as apposed to C Library (libc).
Who calls it “GNU Library C” though?
I’d just like to interject for a moment. What you call “GNU Library C” is actually GNU with Linux library C and some C++ for those nifty templates, or as we like to call it “GNU/Linux Library C/C++”. Which, to be honest, it’s more like “GNU/Linux Library C/C-with-Classes” the way they’re teaching it at school, oh well.
Carry on.
I was, it seems, too subtle. I don’t call it “GNU Library C”. Nobody does. I call it the “GNU C library”. It’s weird that the author calls it that.
Aaaaaand I somehow missed that.
Then again, wouldn’t have changed much. I’d just infodumped you on the GNU/Linux C Library, or as we sometimes call it the GNU plus Linux C library with macros.
Aaaaaand I somehow missed that.
Not the only one it seems - that’s on me.
GNU plus Linux C library with macros.
🤣
