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
