[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aef747a9-2ed5-44f6-9f10-d045566aa18c@grsecurity.net>
Date: Mon, 1 Jul 2024 22:46:41 +0200
From: Mathias Krause <minipli@...ecurity.net>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on
glibc-based Linux systems
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
