[HN Gopher] Glibc Dynamic Loader Hit by a Nasty Local Privilege ...
___________________________________________________________________
Glibc Dynamic Loader Hit by a Nasty Local Privilege Escalation
Vulnerability
Author : mfiguiere
Score : 53 points
Date : 2023-10-03 19:25 UTC (3 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| escape_velocity wrote:
| 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.
| catern wrote:
| The problem is setuid. Just get rid of that and this becomes
| irrelevant.
| saagarjha wrote:
| The problem is computers. Just get rid of them and this becomes
| irrelevant.
| vore wrote:
| Well, 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.
| coder543 wrote:
| I'm not saying polkit isn't an improvement, but it also
| isn't a panacea: https://github.blog/2021-06-10-privilege-
| escalation-polkit-r...
| msm_ wrote:
| 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.
|
| [1]: https://github.blog/2021-06-10-privilege-escalation-
| polkit-r...
| [deleted]
| pengaru wrote:
| Yikes.
|
| 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.
| mcculley wrote:
| It is a failure that setuid executables still exist in modern
| Linux.
| blablabla123 wrote:
| 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.
| skitter wrote:
| And 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...
| lfittl wrote:
| 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.
| kentonv wrote:
| Looking 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....
|
| 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.
| akira2501 wrote:
| > 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.
| aleden wrote:
| 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: GLIBC_TUNABLES=glibc.cpu.hwcaps=
| -AVX -AVX2 -AVX_Usable
| -AVX2_Usable -AVX512F_Usable
| -SSE4_1 -SSE4_2 -SSSE3
| -Fast_Unaligned_Load -ERMS
| -AVX_Fast_Unaligned_Load
| akyuu wrote:
| 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.
| dralley wrote:
| >musl (used by default on Alpine and Chimera Linux) and the
| BSD libc's on the other hand are much more minimal and
| conservative.
|
| Read: slower and with less comprehensive standards compliance
| (even if some of those standards are a bit nutty).
___________________________________________________________________
(page generated 2023-10-03 23:01 UTC)