Glibc Dynamic Loader Hit by a Nasty Local Privilege Escalation Vulnerability

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by kentonv on Tuesday October 03, 2023 @04:30PM (#37757133)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by akira2501 on Tuesday October 03, 2023 @05:41PM (#37757963)

> 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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by akyuu on Tuesday October 03, 2023 @06:21PM (#37758436)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by dralley on Tuesday October 03, 2023 @06:50PM (#37758664)

>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).

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by yjftsjthsd-h on Tuesday October 03, 2023 @07:06PM (#37758787)

I was under the impression that musl does care about standards compliance, hitting problems mostly when people expect non-standardized behavior.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by saagarjha on Tuesday October 03, 2023 @07:55PM (#37759137)

Musl is somewhat the embodiment of malicious compliance to the standard.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by blueflow on Tuesday October 03, 2023 @07:16PM (#37758863)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by kazinator on Tuesday October 03, 2023 @07:31PM (#37758978)

Counterexample: musl's crypt() does silly things, like treat all unrecognized inputs as DES, even if the salt characters are invalid.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by q66 on Wednesday October 04, 2023 @09:49AM (#37765148)

at least it actually supports blowfish

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by kelnos on Tuesday October 03, 2023 @09:16PM (#37759745)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by blueflow on Wednesday October 04, 2023 @04:26AM (#37762396)

And glibc is the one not implementing strlcpy and strlcat until June 2023.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by pantalaimon on Wednesday October 04, 2023 @05:46PM (#37772262)

strscpy is the better API anyway

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by fanf2 on Wednesday October 04, 2023 @10:45AM (#37765937)

It was made a requirement by RFC 7766 in 2016 https://www.rfc-editor.org/rfc/rfc7766#page-6

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by dralley on Wednesday October 04, 2023 @03:01PM (#37769978)

That doesn't necessarily contradict "the DNS standards people got fed up with people not implementing it, and made it a requirement."?

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by fanf2 on Thursday October 05, 2023 @09:26AM (#37778319)

It took musl about 6 years to implement the requirement.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by smsm42 on Wednesday October 04, 2023 @12:40AM (#37760927)

[delayed]

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by q66 on Wednesday October 04, 2023 @09:48AM (#37765133)

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

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by 1vuio0pswjnm7 on Tuesday October 03, 2023 @07:38PM (#37759024)

"musl (used by default on Alpine and Chimera Linux) and the BSD libc's on the other hand are much more minimal and conservative."

Also available on Void Linux.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by stefan_ on Tuesday October 03, 2023 @09:32PM (#37759850)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by q66 on Wednesday October 04, 2023 @09:51AM (#37765170)

musl's code is hardly pretty, but considering every linux libc's code is cursed and especially glibc's, musl still more or less wins there

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by worthless-trash on Tuesday October 03, 2023 @10:00PM (#37759995)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by CyberDildonics on Wednesday October 04, 2023 @07:47PM (#37773230)

the musl library allocator was also exploitable by similar style 'house of' attacks

What are you basing this on? Can you demonstrate how this works?

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by worthless-trash on Thursday October 05, 2023 @03:28AM (#37775768)

Not in a HN news comment, I don't have that level of dedication to this because its definitely non trivial. However you can read about them in use against the glibc allocator are here: https://github.com/DhavalKapil/heap-exploitation/blob/master...

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by CyberDildonics on Thursday October 05, 2023 @10:31AM (#37779094)

The link you have here is 'attacking' by directly changing the meta data in C with pointer offsets and doesn't mention musl anywhere.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by worthless-trash on Thursday October 05, 2023 @11:09AM (#37779600)

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.

I'm sorry for any confusion.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by CyberDildonics on Thursday October 05, 2023 @01:50PM (#37781685)

I believe the same kind of attacks work against the musl allocator

Why is this even an attack and why would musl have whatever weakness is claimed here?

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by worthless-trash on Friday October 06, 2023 @08:28AM (#37789829)

Gotcha.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by smsm42 on Wednesday October 04, 2023 @12:37AM (#37760904)

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?"

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by aleden on Tuesday October 03, 2023 @06:48PM (#37758640)

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

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by remexre on Tuesday October 03, 2023 @07:59PM (#37759165)

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.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by saagarjha on Tuesday October 03, 2023 @08:54PM (#37759615)

rep movsb has stronger requirements than memcpy, in particular with regards to behavior when the source and destination overlap.

[ Parent | on HN ]

Re:Glibc Dynamic Loader Hit by a Nasty Local Privilege Escal... by remram on Wednesday October 04, 2023 @08:44PM (#37773612)

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?

[ Parent | on HN ]