![]() |
|
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.