6 ms·
Glibc dynamic loader hit by a nasty local privilege escalation vulnerability
- lfittl 3y agohttps://www.openwall.com/lists/oss-security/2023/10/03/2 https://www.openwall.com/lists/oss-security/2023/10/03/2 is probably a better link (without ads and unnecessary images), which is essentially what the article is citing 1:1.
- 1vuio0pswjnm7 3y agoLooney Tunables: Local Privilege Escalation in the glibc's ld.so (CVE-2023-4911)
- TacticalCoder 3y agoAre you sure it's the correct CVE? That one is fixed in Debian stable (and probably others): https://security-tracker.debian.org/tracker/CVE-2023-4911 https://security-tracker.debian.org/tracker/CVE-2023-4911
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- justinludwig 3y agoYes, 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.
- userbinator 3y agoReading these parts of the analysis... 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.
- pantalaimon 3y agostrtok would be the function to use, it’s silly to open-code it like that
- stevekemp 3y agoYeah I linked to that same writeup in this earlier piece: https://news.ycombinator.com/item?id=37754973 https://news.ycombinator.com/item?id=37754973 I guess this isn't entirely a duplicate thread though.
- eviks 3y agoBut then this link is unreadable on a phone since the text doesn't reflow
- catern 3y agoThe problem is setuid. Just get rid of that and this becomes irrelevant.
- userbinator 3y agoThe problem is multiple users. Just get rid of that and this becomes irrelevant.
- saagarjha 3y agoThe problem is computers. Just get rid of them and this becomes irrelevant.
- vore 3y agoWell, there's polkit now to avoid granting such broad permissions via setuid, so it's not like there isn't a viable alternative right now.
- mcculley 3y agoIt is a failure that setuid executables still exist in modern Linux.
- blablabla123 3y agoBut 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.
- kentonv 3y agoLooking at the details here I have to say it sure looks like the glibc people were asking for trouble. 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.html 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/20210316070755.330084-5-siddhesh@sourceware.org/ 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.
- akira2501 3y ago> Why not just ignore it altogether? 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.
- akyuu 3y agoFrom 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.
- skitter 3y agoAnd some people say string handling in C is easy. Maybe using memory unsafe languages for anything security related isn't such a good idea after all…
- stonogo 3y agoFeel free to replace libc with a memory-safe implementation.
- jeffbee 3y agoThat 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.
- tpush 3y ago> [...] its bad and well-deserved reputation. I contest that reputation exists in anything but your own mind or bubble.
- secondcoming 3y agoeasily done by _someone else_, I assume?
- trealira 3y agoThe 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++. https://github.com/llvm/llvm-project/tree/main/libc/src/stdio https://github.com/llvm/llvm-project/tree/main/libc/src/stdi... 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++.
- pengaru 3y agoYikes. 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.
- escape_velocity 3y agoSmall 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.
- cozzyd 3y ago(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...
- intorio 3y agoRHEL 8 is impacted, the fix that introduced the issue was back ported: https://access.redhat.com/security/cve/cve-2023-4911 https://access.redhat.com/security/cve/cve-2023-4911