CT_00_011 - Stack Clash Support (GCC)

Owned by Jeff Law
Last updated: Aug 14, 2024
2 min read

About

Stack clash is an exploit which utilized large frame allocations to "jump the guard page" creating a scenario where the heap and stack collided under attacker control.  This can be used to gain full control of a vulnerable application.  Stack probing techniques can be used to mitigate the vast majority of vulnerabilities in this space, but implementing them requires significant work for each and every target to be supported.


Stack class mitigations are a soft requirement for distributions such as Fedora and a hard requirement for Red Hat Enterprise Linux.



Stakeholders/Partners

RISE:

Ventana: Raphael Zinsly – lead developer

Ventana: Jeff Law – design/implementation review

Samsung: Alexy Merzlyakov – binary/rpm scanner based on Nick Clifton's annobin framework

Red Hat: Nick Clifton – annobin scanning framework



External:


Dependencies

  • There is a minor dependency on wording in PSABI for a extreme corner case.   Essentially PSABI will need to spell out certain requirements for callers that the callee can depend on to implement efficient stack clash mitigation.   This is a technical ABI change, but it is expected all binaries in the wild would satisfy the new ABI requirements as-is without a rebuild.

Status

Development

COMPLETE


Development Timeline1H2024
Upstreaming

COMPLETE


Upstream Version

gcc-15 (target)

Spring 2025




Contacts

Raphael Zinsly (Ventana)

Jeff Law (Ventana)


Dependencies

None



Updates

 

  • Marking as complete as the code was recently committed into GCC.

 

  • Using Alexy's scanner 6421 packages out of >22000 packages with RISC-V binaries, DSOs and relocatable .o files are potentially vulnerable to stack clash attacks
  •  A gcc-14.1.1 with Raphael's stack clash mitigations is building so that we can start testing how many of those 6421 vulnerabilities are fixed.

 

  • Using Alexy's scanner we're able to start scanning packages for issues.  Those issues which show potential problems can then be rebuilt with Raphael's work to verify the vulnerability has been closed.
  • ~22000 packages with binary data need scanning (out of > 65000 total packages)
  • Roughly 1/3rd of the packages are being flagged by Alexy's scanner.

 

  • Internal (Ventana) implementation review in progress.  Generally looks good.  Significant testing effort should spin up late this week.

 

  • Considering the GCC development effort functionally complete.
  • During investigation of glibc smoke test, discovered that the standard prologue code can create a window where it writes data into unallocated stack space.  This could potentially cause some programs to misbehave if they get an interrupt in the "right" window.  Stack clash work fixes this issue, but Ventana will submit a fix for this problem independently of stack-clash

 

  • The stack-clash implementation bootstraps when on by default
  • It appears that the implementation works correctly for the smoke test (realpath in glibc)
  • GCC's testsuite for stack clash is passing at this point
  • Building scanning tools to help identify vulnerable code and verify that the implementation closes the vulnerability
  • Upstreaming plan: late spring, shortly after gcc-15 opens for develoment

 

  • Implementation of naive protection making good progress.   Handles scalar and vector (following the aarch64 implementation for vector in particular)
  • Probing of outgoing argument area not started
  • Kito is aware of need to make minor changes to PSABI to document expectations from compilers

 

  • Project reported as priority for 1H2024.