Hi folks,
Back in 2022, a Debian bug report was created that described weaknesses
in ASLR: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024149>
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: <https://zolutal.github.io/aslrnt/>
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
<https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt>
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:
<https://gist.github.com/wdormann/544a9e89fe35a84135e58eb5c7b1721d>
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
<https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1024149;filename=test-mmap.c;msg=8>.
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.
-WD
