Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Jul 2024 12:37:08 -0400
From: Will Dormann <>
Subject: ASLRn't is still alive and well on x86 kernels, despite
 CVE-2024-26621 patch

Hi folks,

Back in 2022, a Debian bug report was created that described weaknesses 
in ASLR: <>
As the result of this, x86_64 ASLR was weakened, and x86 ASLR was 
practically disabled, as the result of libc libraries being larger than 
2MB in modern platforms.

Later in early 2024, this issue was given the "ASLRn't" moniker and 
published through other channels: <>

Eventually CVE-2024-26621 was assigned to the vulnerability, and the 
Debian ticket was eventually closed.

The problem with the fix for CVE-2024-26621 seems to be that it perhaps 
only appears to have an effect on 32-bit x86 code running on a x86_64 
Linux kernel. This was made obvious due to the recent Qualys writeup on 
regreSSHion CVE-2024-6387 
Qualys was able to successfully exploit CVE-2024-6387 in a "reasonable" 
amount of time due to the lack of ASLR on an x86 platform.

To make testing this stuff easier, I've put together a toy python script 
to easily see if the platform is vulnerable to ASLRn't or not: 
Specifically, if any app running on the platform might expose a 
large-enough libc at a predictable address.  It will also report lack of 
PIE in "cat", and also the apparent entropy/bitmask of randomizations 
present. When testing platforms with a libc smaller than 2MB, this 
python script won't suffice and you'll likely need a test app such as 
what's listed in the Debian bug 
  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)
  - Older Linux (5.x and earlier) randomize loaded libraries as expected.

It's unclear to me whether the inapplicability of the CVE-2024-26621 to 
x86 kernels was intentional, or whether it was a compromise with known 
side effects.  Granted, the availability of modern x86 Linux is somewhat 
limited (e.g. Debian, Kali, OpenSUSE Tumbleweed), but IMO if Linux 
kernel is to continue to support the platform, any regression of a 
mitigation that has been around for years should probably warrant a 
(new) CVE.

As for x86_64 kernels, the ASLR entropy of libc appears to drop from ~29 
bits to ~20 bits with the change that introduced ASLRn't. Whether this 
is CVE-worthy is beyond me, as the strength of the protections provided 
by ASLR are indeed weakened by the change in where libraries are loaded. 
  But arguably ~20 bits of ASLR may be considered "fine" and that the 
benefits of the change in loading addresses outweighs the risk.

Brief testing on a 6.1.21 32-bit ARM platform shows that 2MB mapped 
files are indeed randomized, so perhaps this all is an x86-specific 
issue. Though I have not tested any platform other than ARM and x86.


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.