[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250315170905.GA21652@localhost.localdomain>
Date: Sat, 15 Mar 2025 17:09:39 +0000
From: Qualys Security Advisory <qsa@...lys.com>
To: Hanno Böck <hanno@...eck.de>
CC: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: expat vulnerability CVE-2024-8176 / impact of
recursion stack overflow vulnerabilities
Hi Hanno, all,
On Fri, Mar 14, 2025 at 07:53:24PM +0100, Hanno Böck wrote:
> I believe from the above that current systems should not be vulnerable
> to this type of vulnerability. I am unsure about systems that do not
> apply -fstack-clash-protection.
We have not looked into this specific expat vulnerability yet, and we
have not tried to exploit a stack-clash vulnerability in a long time,
but maybe what follows will be useful anyway.
The TL;DR is probably: stack-clash vulnerabilities are not exploitable
for arbitrary code execution anymore, because (to the best of our
knowledge) all major Linux distributions use -fstack-clash-protection
nowadays; and even without -fstack-clash-protection, most of these
vulnerabilities are not exploitable anymore thanks to the Linux kernel
mitigation that was introduced in 2017 (a 1MB stack_guard_gap).
1/ Over the years we have disassembled various binaries in various Linux
distributions, and it is clear that at least *SUSE, Fedora, Ubuntu,
Debian, and Red Hat Enterprise Linux 9 and derivatives compile
everything (or at least everything security-sensitive) with
-fstack-clash-protection, which makes it impossible to exploit such
vulnerabilities for arbitrary code execution.
2/ Even without -fstack-clash-protection, such a vulnerability must
satisfy two key (and unlikely) requirements to be exploitable:
- at least one single stack allocation must exceed 1MB to bridge the gap
between the main stack and another memory region, because the kernel's
stack_guard_gap was increased from a few kilobytes to 1MB in 2017 --
most likely this stack allocation must be a variable-length array or
an unbounded alloca();
- this large stack allocation must not be fully written to, otherwise
the stack_guard_gap is written to and causes a crash, not a memory
corruption or code execution.
3/ The last kind of stack-clash vulnerability that we exploited was in
2019, in systemd-journald. It was exploitable because we could alloca()
an array of up to 4GB, and we could prevent this array from being fully
written to. But even in 2019, *SUSE and Fedora were not exploitable
because they were already using -fstack-clash-protection:
https://www.qualys.com/2019/01/09/system-down/system-down.txt
>From https://blog.hartwork.org/posts/expat-2-7-0-released/:
> Please leave recursion to math and keep it out of (in particular C)
> software: it kills and will kill again.
:-) Also:
https://www.openwall.com/lists/oss-security/2025/03/15/1
Thank you very much! With best regards,
--
the Qualys Security Advisory team
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.
