Re: CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems

[Mathias Krause <minipli () grsecurity net>]

On 01.07.24 17:36, jvoisin wrote:
> [...]
> I gave a cursory look at the musl libc (https://musl.libc.org/) with the
> help of the lovely #musl people, and it doesn't seem to be affected:
>
> - Its syslog implementation (
> https://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c ) doesn't
> seem to (sub)call async-signal-unsafe functions.

Just wanted to provide some comment on the below, as there still seem to
be misunderstandings related to what kernel and userland bugs / features
lead to reduced ASLR. Focusing solely on the thp_get_unmapped_area()
kernel related one isn't sufficient -- especially when we're looking at
old distros, as the Qualys folks did.

> - Thanks to its small size, it's not affected by ALSRn't.

As pointed out in the blog[1], file size is far from the only factor to
weaken ASLR. Userland bugs -- pardon me, "features" -- make the kernel
play the devils advocate. And Alpine Linux at least from v2.6 (back then
still making use of uClibc) up to v3.8 fell for the binutils trap:

~ # cat /etc/alpine-release
3.8.5
~ # ./paxtest/contrib/check_align.sh /lib/libc* /usr/sbin/sshd
/lib/libc.musl-x86_64.so.1 (max align=0x200000)
/lib/libcrypto.so.43 (max align=0x200000)
/lib/libcrypto.so.43.0.1 (max align=0x200000)
/usr/sbin/sshd (max align=0x200000)
~ #

Fortunately (-- a bug?, a feature?) does musl's runtime linker ignore
alignment requirements of loaded DSOs and so it's only the behaviour of
recent'ish kernels (v5.10+) that will make sure the program interpreter
-- which also happens to be musl's libc, oh well -- and the binary's
PT_LOAD segments get properly aligned and their ASLR bits reduced
accordingly.

Oh, well... But sure, Alpine Linux 3.8 is out of support for 4+ years by
now. Nobody should be affected by any of this any more, less so run it
on recent kernels.

Cheers,
Mathias

[1] https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr