OK, so obviously someone calling a SUID program shouldn't be able to set these options at all, right? So I guess the bug must be that they forgot to clear this env var when starting a suid program? Given that there have been so many vulnerabilities like this you'd think they would have really audited environment variable usage to avoid this but maybe it slipped through?
... NO WAIT! It's worse! They apparently intentionally allow some tunables to be tuned across a SUID boundary. Looking at the commit that is blamed for introducing this problem, it is explicitly dealing with the filter logic for tunables in SUID mode!
But whyyyyyyy? Why not just ignore it altogether? Is the use case for tuning ultra-advanced performance settings across SUID so strong that it outweighs the obvious security risks?
I mean, I'll admit, I've never seen this env var before, I have no idea how it's used and whether there's actually a good reason why you'd want to use it over SUID. But boy this seems like a hugely risky feature and sure enough... it broke.
The GLIBC_TUNABLES can be used to "choose" between different versions of e.g. memcpy at runtime. This can be really useful for debugging, if you want to allow/disallow AVX extensions, for example (even if your CPU supports them). This is what I use on x86_64 to make life easier for my "static" version of qemu usermode:
Does removing ERMS actually make life easier? I thought it was the "do the simple thing" option, and an emulator could just turn it into a memcpy on the emulator's side.
Sounds like a DoS vector at least, even if the filter worked correctly. Why should you be able to disable AVX extensions for another user's process? Why would you debug across SUID boundaries?
From what I’ve read from some security researchers, glibc is not really focused on security. For example, it contains CPU-specific manually crafted assembly for optimization purposes, and its memory allocator implements exploitation-friendly features such as thread caches. I’m not surprised by this vulnerability, and I suspect there are many similar ones that haven’t been discovered yet.
musl (used by default on Alpine and Chimera Linux) and the BSD libc’s on the other hand are much more minimal and conservative.
musl has a better track record of standards compliance than glibc. Common method for porting to musl is putting non-standard compliant code into an ifdef glibc.
This is, of course, the same musl that refused to implement TCP DNS requests until very recently. And they only did so because the DNS standards people got fed up with people not implementing it, and made it a requirement.
I do not know about standards, but I know the only deployment images I have problems all the time with random weird DNS failures are the musl-based ones. No idea what causes it, but makes me wish to get rid of all musl usage just to have stable deployments.
pretty much the only place where it's meaningfully slower is the allocator (which has a massive impact) so in chimera we have a special musl build that uses llvm's scudo instead (same as e.g. android) and is faster as well as more secure than glibc's allocator
the rest is mostly fewer specialized implementations of stuff for different cpus, but that rarely makes a difference in practice (i.e. outside of microbenchmarks)
the overall standards compliance is pretty good in musl
Still there's a difference between not doing the maximum possible to prevent theoretical exploits (like caches thing) and adding an externally controlled feature that crosses into SUID territory and begs to be exploited. It's like the difference between not buying the door made of strongest alloy steel and just leaving the key under the potted plant. The latter makes you say "what were you thinking?"
Scroll through some musl code if you have some spare time, they take code golfing with C strings to a whole new level. What saves them is only that they skip the insane stuff in glibc.
Last time i looked, the musl library allocator was also exploitable by similar style 'house of' attacks. Maybe its been fixed now. I dont know if you can make a judgement call that musl is better because it has 'less code' when its still open to exploit mechanisms that glibc fixed many moons ago.
The "house of" attack method are attacks against the allocator, its been a while since I've looked into it, I hope musl have hardened their allocator against this kind of attacks.
I did not say that it did. I'm saying that I believe the same kind of attacks work against the musl allocator, or at least I think they did at that time.
Musl was not being used by the business I worked in, therefore I had no interest in continuing investigation other than trying to get an understanding of how other implementations dealt with it.
hah.. even worse, if you follow down the thread in your last link, apparently there is an SXID_IGNORE which they decided was better implemented as an SXID_ERASE for some variables.
for each GLIBC_TUNABLES that it finds, it makes a copy of this variable (at line 284), calls parse_tunables() to process and sanitize this copy (at line 286), and finally replaces the original GLIBC_TUNABLES with this sanitized copy (at line 288)
To sanitize the copy of GLIBC_TUNABLES (which should be of the form "tunable1=aaa:tunable2=bbb"), parse_tunables() removes all dangerous tunables (the SXID_ERASE tunables) from tunestr, but keeps SXID_IGNORE and NONE tunables
...already made me expect what I'd see, and indeed the code there is quite unnecessarily complex. The first simplification I'd do is not make a copy of the variable's value, and the second one is to use the standard C string functions extensively; it's notable that there's no occurrence of strchr() anywhere in that function, despite it being a very useful function for parsing key-value pairs.
Yes, that's the CVE referenced by the Phoronix article and the oss-security post. The researchers coordinated their disclosure with the security teams from the major Linux distros, so packages with the fix should be available for most of them today.
The relevant code is a textbook example of how to make an inscrutable mess of string processing in C. You can do better, even in C, with some care and better hygiene. But the language does not prevent you (or hell, even discourage you) from creating such abominations.
But it's possible to minimize privileges across binaries with that. I think the possible preventable failure is having too much code within setuid/root bounds.
Small silver lining for the folks here that manage Red Hat Enterprise Linux systems.
The bug was introduced in glibc 2.34 so I'm guessing RHEL 7 (glibc-2.17) and RHEL 8 (glibc-2.28) are not affected. That just leaves RHEL 9 which is running glibc 2.34.
(and it's not obvious if 2.34 is easily exploitable either, though it has the same bug, as it uses sbrk instead of __minimal_malloc. So at least the exploit here won't work, though maybe there is another one).
As most genuine multi-user setups are probably running EL (at least, nearly all the ones I've ever used...), this is a pretty big silver lining...
Fortunately polkit can't be abused to do something like privilege escalation, right [1]?
Ok, I'll drop the snark. Do you know of any distributions that approach your idea seriously and ships absolutely no setuid binaries? Ideally they also make sure the user won't install an external package that ships setuid executables.
It's certainly technically possible, you just need to mount everything (including `/`) as nosuid. But even `su`, `sudo` and... `pkexec` need suid to work. So I don't think it's easy to have a usable linux environment with zero suid binaries. Or am I wrong?
In case of this bug, since the bug is in ld, my educated guess is that even one suid binary is be enough for the privilege escalation attack to work.
Assuming a sufficiently secured access method via SSH (ex strong ciphers only, key only, etc), you can get by just fine without su/sudo, of course, youll have to switch users manually, by logging in as a root-like user (ex root aliased, or root itself). Services and such can still operate as other users, as (as far as i know) systemd and rc.d dont rely on suid.
Also, side rant, su/sudo were developed from what i would call being lazy (uhg i dont want to open a new terminal to run a command as root) which has led to a lot of abuse. But, i blame ubuntu for its widespread use and abuse, the first user made by a ubuntu install has full sudo privs out of the box. And then, every guide thereafter just became "just sudo su" (which uhg, in itself). The lazy factor by sudoing everything has led to uses of sudo i wish id never seen. I wish we never had it.
That dismissive attitude gives the free software community its bad and well-deserved reputation. There are reasons why some of glibc is written in C or assembly, but 99% of it is just untested neckbeard bullshit that is easily replaced by something safer. There is no legitimate reason why glibc parses environment variables this way.
The fact that they haven't rewritten glibc's string parsing wouldn't make their criticism wrong.
If all of glibc had been written in assembly for every single target triplet, one wouldn't be wrong to point out that there was no benefit to doing that instead of writing it in C, and that it probably took more work and was more error-prone, even if they weren't willing to help port said code to C.
Just the same, they could have written this in C++.
Much of LLVM's libc is written in C++ with exposed C bindings (or all, I haven't checked 100%). For example, their libc stdio implementation is completely in C++.
You could say the same thing about Rust and Relibc, but it seems much less likely that a C project would incorporate Rust than that it would incorporate C++.
GLIBC_TUNABLES is apparently an environment variable that lets you turn various performance knobs affecting glibc internals: https://www.gnu.org/software/libc/manual/html_node/Tunables....
OK, so obviously someone calling a SUID program shouldn't be able to set these options at all, right? So I guess the bug must be that they forgot to clear this env var when starting a suid program? Given that there have been so many vulnerabilities like this you'd think they would have really audited environment variable usage to avoid this but maybe it slipped through?
... NO WAIT! It's worse! They apparently intentionally allow some tunables to be tuned across a SUID boundary. Looking at the commit that is blamed for introducing this problem, it is explicitly dealing with the filter logic for tunables in SUID mode!
https://patchwork.ozlabs.org/project/glibc/patch/20210316070...
But whyyyyyyy? Why not just ignore it altogether? Is the use case for tuning ultra-advanced performance settings across SUID so strong that it outweighs the obvious security risks?
I mean, I'll admit, I've never seen this env var before, I have no idea how it's used and whether there's actually a good reason why you'd want to use it over SUID. But boy this seems like a hugely risky feature and sure enough... it broke.