oss-security - Re: ASLRn't is still alive and well on x86 kernels, despite CVE-2024-26621 patch

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6771f9536d49185fc8f1ea9905c13cf4dd8776d2.camel@debian.org>
Date: Wed, 10 Jul 2024 22:54:19 +0200
From: Yves-Alexis Perez <corsac@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: ASLRn't is still alive and well on x86 kernels,
 despite CVE-2024-26621 patch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 2024-07-08 at 12:37 -0400, Will Dormann wrote:
>  As reported in the Debian bug, running the program repeatedly with a 
> 2MB file will report the same address every time on a vulnerable system, 
> and will be randomized on a system that is behaving as expected.
> 
> In testing some platforms that I had readily available, I've concluded:
>   - Modern (e.g. 6.x kernel) x86 platforms load a large-enough libc at 
> the same address every time. (i.e. no practical ASLR -- "ASLRn't")
>   -  Modern (e.g. 6.x kernel and large-enough libc) x86_64 platforms 
> running 32-bit code will load a large-enough library at the same address 
> every time.
>   - Modern x86_64 systems with the CVE-2024-26621 patch will randomize 
> the load address of large libraries loaded by 32-bit apps.
>   - Modern x86 systems with the CVE-2024-26621 patch will NOT ranzomize 
> the load address of large libraries.  (i.e. is still vulnerable to 
> "ASLRn't" despite the patch)

Hey,

I'm testing on my Debian sid laptop with Linux kernel 6.9.7-1. This is amd64
but running test-mmap built with -m32, and I get:

for i in {0..10}; do ./test-mmap < zeros; done
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7df3000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d98000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d6f000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7de7000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7df6000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7cfd000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d25000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d48000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7dad000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7d7b000
mmap(NULL, 2097152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 0, 0) = 0xf7df4000

So it *looks* to me like it's “properly” randomized (for a 32b process). I
don't have a 32b install handy so I can't test but I'd assume the -m32 to
exhibit the same behavior? This is with vm.mmap_rnd_compat_bits=8.

Or am I doing something wrong?
- -- 
Yves-Alexis
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmaO9PsACgkQ3rYcyPpX
RFtwbAf/esGTSILYL1Seffq43QtauizeyRAth/3U2o39SbC/KD5Bpx2wwT3+3WX5
ag96yhhBWpf6ef3JgSlblYqCZeFLRFyVYbpLQm4GpfVHDOzvJI1qaF6wPlxyXetn
CFy/mQq/CWVNNQ9BH4FvU0SRwaKa7ijszvkDk/RsqS/8e5nR5ufGDyH0LlZU8HJ4
LTLQLLHUA1Xt9xXhBuuNm7iMh0HmesQKOQcPQM0/e6ea7I3enLJNm14gv3eYWUIO
RnG+TqwpbGW1E4NlcxZ7qo7sXabmn6tKTg5gQh5X9ADDgW0rvpeKEtYda1rO8M79
/od7a49ITS3XR7tjNswxNBdqelt8Tg==
=8zdL
-----END PGP SIGNATURE-----

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.