Local privilege escalation in glibc’s ld.so | Hacker News Reader

Local privilege escalation in glibc’s ld.so

qualys.com

36 pointsstevekemp6 comments

From yesterday:

Glibc dynamic loader hit by a nasty local privilege escalation vulnerability - https://news.ycombinator.com/item?id=37756357 - Oct 2023 (56 comments)

Once again qualys writeups are outstandingly clear, and full of just the right kind of detail to make them interesting.

(I especially appreciate that they take the time to discuss things that didn't work out, or paths that were excluded for some reason.)

although we discovered this buffer overflow manually, we later tried to fuzz the vulnerable function, parse_tunables(); both AFL++ and libFuzzer re-discovered this overflow in less than a second, when provided with a dictionary of tunables

How prevalent is the use of fuzzers in FLOSS infrastructure projects? I know the Linux kernel is regularly fuzzed, but even there I'm not sure if this is done by regular kernel developers/maintainers or third-party researchers.

Systemd at least gets fuzzed continuously...

https://github.com/systemd/systemd/tree/main/test/fuzz

https://github.com/systemd/systemd/actions

But it's not like you just point a fuzzer at a project and voila magic it's all getting fuzzed...

The "yes we fuzz" checkbox can be checked while still having substantial gaps in the coverage.

Most FOSS software has minimal testing. Fuzzers are only used by companies with their own security teams doing due diligence on their stacks.

"Exploitation method described in this advisory works against almost all of the SUID-root programs that are installed by default on Linux; a few exceptions are:

- sudo on all distributions, because it specifies its own ELF RUNPATH (/usr/libexec/sudo), which overrides our l_info[DT_RPATH];

- chage and passwd on Fedora, because they are protected by special SELinux rules;

- snap-confine on Ubuntu, because it is protected by special AppArmor rules."

Reply on news.ycombinator.com