stack_clash.md

November 8, 2017 ยท View on GitHub

Notes about stack clash

The 3rd "nuclear" bomb named "The Stack Clash" dropped by Qualys to the planet Penguin since the era of "Attacking the core". An old exploit vector being weaponized by the stack clash can target any SUID/SGID programs by exploiting the flaw in guard-page and automatic stack expansion feature. From Grsecurity's blog( another "An Ancient Kernel Hole is (Not) Closed" in LWN), we can see there are some silent fixes1 2 by Linus Torvalds( as always). Let's see the summary about defensive mitigation:

  1. PaX's ASLR can defeat offset2lib easily since...2001?

  2. Stack/heap protectioned provided by linux kernel has only one single page( 4KB by default in i386) due to some compatibility issues. PaX's implementation doesn't have this problem and its gap is 64KB by default. You can set the number at runtime via "sysctl vm.heap_stack_gap"( We have another auditing item for the hardening solution. Thanks to the full disclosure).

  3. PaX's STACKLEAK can detect if moving sp to the start of the stack.

  4. Some resctrictions provided by PaX/Grsecurity on SUID programs. GRKERNSEC_BRUTE is one of them. It will raise the bar to those who try to gain the control of EIP. Qualys gave the test results about Debian 8.6 with PaX/Grsecurity:

    • GRKERNSEC_BRUTE disabled: 200 hrs to gain control of EIP, then ~1500 yrs to brute force the PaX's ASLR to getting root shell
    • GRKERNSEC_BRUTE enabled: ~1365 days to gain control of EIP, then...you don't wanna know-_-

PaX/Grsecurity also restricted SUID program's RLIMIT_STACK up to 8MB and the environment arg/strings up to 512KB.

  1. GNU cflow and GCC's -fstack-check can be considered in the situational hardening solution and the performance impact trade-off must be made. For example, Gentoo Hardened enabled -fstack-check since gcc-4.8 (around 2014?) and can mitigate most exploitations of Stack Clash.

Spender/PaX team also pointing out the possibility of similar issues in kernel stack. KSPP doesn't try to understand STACKLEAK while trying to copy+paste stuff from PaX/Grsecurity. On the other hand, VMAP_STACK is not solid as KSPP claimed. Forge the mitigation by introducing more exploitable bugs is not the proper way to do it. Instead, Grsecurity moved the thread_info off the kstack in the early days and then forged it with other defensive code as a feature KSTACKOVERFLOW in 2014.

The stack clash is the full disclosure of a exploit vector after offset2lib. It seems Greg K Hartman didn't want to accept the original offset2lib patch( He's likely to accept more security mitigation because Linux foundation need KSPP to making more money from membership sales. That's why we lost the ark, remeber?. Maybe it's just Google want him to do so?;-)). Kees Cook's patch merged 5 months later. Unfortunately, the exploitation method demonstrasted in stack clash can bypass the previous offset2lib upstream fix, which means we are expose to both high risk exploit vectors now: offset2lib and stack clash. There are tons of known/0-day bugs can be utilized by exploit writer to forge their weapon. Offset2lib troubled some industry( ask ppl from finacial industry) at once. Are we going to face massive exploitation with stack clash( maybe in the form of ransomeware?) in the future? Murphy's law seems to tell us shit happens as always.

May we screw again!

Update( Sep 28): Red Hat didn't backport the one of fixes for stack clash and yet we don't know why RH didn't treat the fix as a security issue. According to the Qualys security advisory, this issue( CVE-2017-1000253) affected RHEL/CentOS 6/7.

Update( Jun 25 2017): CVE-2017-1000370( offset2lib bypass) is still not fixed. RedHat says this issue is still in "Under Investigation" just could be implying that they are waiting for the patch from the upstream "community". The whole fixes for the stack clash are originally from PaX/Grsecurity's fix in 2010. The funny thing is Linus Torvalds called PaX/Grsecurity "Their patches are pure garbage." a few days ago. A couple of silent fixes being fully disclosure and then Linus seems "inviting" PaX team/Spender send him the patch. Linus shouldn't call PaX/Grsecurity is the garbage because there's a group of ppl called themselves KSPP got paid by big corps and Linux foundation are still trying to copy+paste PaX/Grsecurity to the upstream, and more importantly, Linus himself merged a lot patches. LF/CII may never care about exploitable bugs which could be turned into massive exploitation by malware or weaponized exploit target on the high value asset. They only cares about money. We suggest those who concerns the real sense of security should go re-assessment the security risk of linux kernel which running on your IMPORTANT machines.