Glad I only run Alpine
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
RedHat and related: https://access.redhat.com/security/cve/CVE-2023-6246
Not affected
Not affected
Not affected
etc.
That's why you need to rock and roll
(Arch btw.)
Try having unattended-upgrades
with a rolling distro.
I don't want unattended upgrades >:/
Just don't upgrade for a while and you become debian
It's not like windows forcing you to reboot every Tuesday so Edge can come back
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.
So this means you need either Alpine repos or compile everything yourself?
Void offers musl too. Unless they've discontinued it.
But
compile everything yourself?
I do (almost) exactly that. I run Gentoo almost everywhere. The 'almost' is because Gentoo now offers an official bin repository too, so I can mix compiled and pre-compiled software. (Although you've always had the option to set up your own binary host).
"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.
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.
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.
Wait, why has a compiler system log functionlity?
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
glibc is a library, gcc is the compiler.
Security-critical C and memory safety bugs. Name a more iconic duo...
I'd have kinda preferred for public disclosure to have happened after the fix propagated to distros. Now we get to hurry the patch to end-users which isn't always easily possible. Could we at least have a coordinated disclosure time each month? That'd be great.
Public disclosure is typically done 90 days after Deva are privately notified. That should be enough time for security-critical bugs.
They did follow that. You can read their disclosure timeline in their report.
Problem is that the devs of glibc aren't the only people interested in getting glibc patched but us distro maintainers too.
What I would have preferred would be an early private disclosure to the upstream maintainers and then a public but intentionally unspecific disclosure with just the severity to give us distro people some time to prepare a swift rollout when the full disclosure happens and the patch becomes public.
Alternatively, what would be even better would have been to actually ship the patch in a release but not disclose its severity (or even try to hide it by making it seem like a refactor or non-security relevant bugfix) until a week or two later; ensuring that any half-decent distro release process and user upgrade cycle will have the patch before its severity is disclosed. That's how the Linux kernel does it AFAIK and it's the most reasonable approach I've seen.
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.
The hero we need."; DROP TABLE "users";
If it isn't little Bobby Tables again.
Debian (versions 12 and 13), Ubuntu (23.04 and 23.10), and Fedora (37 to 39). Other distributions are probably also impacted.
https://security-tracker.debian.org/tracker/CVE-2023-6246
Don't know if Fedora has any similar easy way of tracking vulnerabilities
Patch time