Red Hat, Ubuntu, Debian, and Gentoo Release Patches for 'Looney Tunables' Linux Vulnerability

Thursday ZDNet reported... As security holes go, CVE-2023-4911, aka "Looney Tunables," isn't horrid. It has a Common Vulnerability Scoring System score of 7.8, which is ranked as important, not critical.

On the other hand, this GNU C Library's (glibc) dynamic loader vulnerability is a buffer overflow, which is always big trouble, and it's in pretty much all Linux distributions, so it's more than bad enough. After all, its discoverers, the Qualys Threat Research Unit, were able to exploit "this vulnerability (a local privilege escalation that grants full root privileges) on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13." Other distributions are almost certainly vulnerable to attack. The one major exception is the highly secure Alpine Linux. Thanks to this vulnerability, it's trivial to take over most Linux systems as a root user. As the researchers noted, this exploitation method "works against almost all of the SUID-root programs that are installed by default on Linux...."

The good news is that Red Hat, Ubuntu, Debian, and Gentoo have all released their own updates. In addition, the upstream glibc code has been patched with the fix. If you can't patch it, Red Hat has a script that should work on most Linux systems to mitigate the problem by setting your system to terminate any setuid program invoked with GLIBC_TUNABLES in the environment.

Fuuuuu

[ArmoredDragon]

And glibc needing updates is the biggest thing that tends to break binary compatibility on linux...

Re:Fuuuuu

[test321]

I am a gentoo user for 20 years, I recompile glibc whenever it updates. No issues ever. Just don't mess with compile options (building glibc with -O3, -ggdb3, or -ffast-math will break glibc and then you need to reinstall the system) or downgrade in version number. The patches in question appeared in gentoo on Oct 4, I rebooted twice, once because the cat stepped on the power button, the other time after building a new kernel. All good.

Re:

[gweihir]

Oh? What are you doing wrong?

Re:

[ras]

He's not using Debian, or some derivative. If he was, it's likely the patch is already installed, and he didn't know it. Debian back ports the fix to the existing version, so it's almost invisible. He may need to restart some services, but Debian will do that for him to if he's willing to risk a few second downtime.

Re:

[gweihir]

Debian does not do automatic updates though. There may be a package for it (no idea), but I am running my own cron-job for that. Exactly one problem (easily fixed) in doing that for now about 20 years on several servers. Doing the same for a Gentoo server for 2 years now. Again, no problems and the Gentoo documentation does explicitly not recommend automatic updates.

So is a libc update high-risk with some distros?

Re:

[OrangeTide]

glibc compatibility is a one-way trip on Linux. You can go forward but it really sucks at going backwards. Some other operating systems have ways to pin versions and toolchains to ensure compatibility. GNU/Linux seems to go out of its way to make binary distribution a Sisyphean endeavor for closed source application developers.

Re:

[serafean]

That's because the target is system administrators, and those want to know which program uses which version of what library, to be able to track issues on the system, and have the possibility to update said libraries without the need to wait for every single application to update itself.

Re:

[OrangeTide]

I think the target is whatever the glibc team wants it to be, probably whatever suits their own personal use. If the rest of us can come along for the ride is just an added bonus but not the primary concern for developers.

Containers completely smashes your idea that system administrators want to know which program uses which version of what library. A lot of administators are looking to container-based deployments to ease much of the dance with dynamic libraries that we've been doing for the last 30 years.

Re:

[loonycyborg]

It's solved problem currently if you're using flatpak. It has own glibc in its runtimes. Any apps will be built against particular runtime which amounts to a way for app developers, including closed source, to pin their glibc as well as all other deps. Runtimes even get security updates until they become deprecated.

Re:

[OrangeTide]

I think containers are a bit of a hack around the library dependency problem. Flatpak, snap, docker, and others are wildly popular probably because they are so easy to deploy. Even back in the day we'd try to chroot things and hack around system calls with ptrace monitors (very slow!) just to get some software to run in its own environment. Maybe it was inevitable that we ended up with namespaces and a complex set of bind mounts, and I blame how big of a pain in the ass maintaining a stable *nix machine can

Re:

[MSG]

What? glibc has *highly* stable interfaces. Where did you get this idea?

Not why Alpine linux isn't immune

[micheas]

Alpine Linux and several limited purpose distributions use Clibc instead of glibc.

Hence, Alpine Linux isn't vulnerable, just as, FreeBSD, Windows 11, OsX, and QNX aren't vulnerable to this vulnerability, as they don't ship with the vulnerable software.

Re:

[Anonymous Coward]

Alpine hasn't used uClib in like 10 years, it uses musl.

I don't know who slipped that "highly secure" thing in there, laugh, as Alpine's security or lack of has nothing to do with this bug.

Probably some Alpine fanboi wanking their doodle.

Re:

[korgitser]

In my experience, an Alpine fanboy is a Docker fanboy. There is this weird cult of clueless dolts that know nothing about security, but have convinced themselves that it comes from using Alpine, and circle jerk congratulate each other for finding the true path. The kind of dolts who can cobble together a dockerfile to put a passwordless mongodb with customer data up on aws open to the whole world, yet be able to sleep like a baby at night knowing they did everything right because it's Docker and it's Alpine

Slackware is not Loony

[jmccue]

FWIW, Slackware patched it in vurrent on Oct 3. For people who do not know, Current is the Test version that will eventually become the next version of Slackware.

http://slackware.osuosl.org/slackware64-current/ChangeLog.txt

And Slackware v15.0 was not vulnerable since it is on version glibc-2.33. :)

https://slackware.osuosl.org/slackware64-15.0/ChangeLog.txt

Re:

[arfonrg]

Yup. Everyone seems to think Slackware is outdated and yet, current's versions and patches tend to beat other distros.

I've been patched for days now.

Re:

[serafean]

Almost everyone got this in their repos oct 4 at the latest.
Just checked my Gentoo install log: glibc updated on Wed Oct 04 2023 10:33:51 GMT+0 .

Rewrite it in Rust

[DMJC]

And kill these crappy memory holes forever.

Re:

[ChunderDownunder]

Redox OS has its own relibc - I think porting it to Linux was a secondary goal.

Re:Rewrite it in Rust

[ledow]

Please explain how you're going to rewrite memory handling, symbol and dynamic loader code in Rust without surrounding it with unsafe() anyway, in which case it not only destroys the memory-safe guarantees of the enclosed code, but also destroys the Rust guarantees of anything - including "safe" code - near it in memory.

Sure, you can go some way to mitigate certain things, but Rust cannot assume handle low-level memory etc. without unsafe statements (because that's basically literally what unsafe exists for), so you'll end up with essentially the same code but wrapped in Rust, rather than decades-old tested C.

Re:

[cc1984_]

Please explain how you're going to rewrite memory handling, symbol and dynamic loader code in Rust without surrounding it with unsafe() anyway, in which case it not only destroys the memory-safe guarantees of the enclosed code, but also destroys the Rust guarantees of anything - including "safe" code - near it in memory.

Sure, you can go some way to mitigate certain things, but Rust cannot assume handle low-level memory etc. without unsafe statements (because that's basically literally what unsafe exists for), so you'll end up with essentially the same code but wrapped in Rust, rather than decades-old tested C.

Just because something is imperfect doesn't mean that it isn't better to switch. If you have a 15 million lines of code in your codebase, how much needs to be unsafe? If it's in C, a memory unsafe operation could be lurking in any of those 15M lines. If written in Rust, then the number of lines needed to be handled with kid gloves is greatly reduced, and you can concentrate your audits on the functions you know to be unsafe, because you've explicitly marked them as such because the thing wouldn't compile ot

Re:

[loonycyborg]

Before those 15 million lines of code will be rewritten in Rust it will be already replaced by next big thing. Could as well rewrite in C++ with shared_ptr.