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

Reply via email to