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 stackguardgap).
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 stackguardgap 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 stackguardgap 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