The Stack Clash

https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

by fcambus • 9 years ago

279 69 9 years ago

0x05• 9 years ago

This looks pretty brutal.

Quote from Kurt Seifried of RedHat http://www.openwall.com/lists/oss-security/2017/06/19/2

"I just want to publicly thank Qualys for working with the Open Source community so we (Linux and BSD) could all get this fixed properly. There was a lot of work from everyone involved and it all went pretty smoothly."

Debian security advisories rapid fire:

glibc https://lists.debian.org/debian-security-announce/2017/msg00...

linux https://lists.debian.org/debian-security-announce/2017/msg00...

exim4 https://lists.debian.org/debian-security-announce/2017/msg00...

libffi https://lists.debian.org/debian-security-announce/2017/msg00...

And just a sample from the Qualys announcement (out of many more), "local-root exploit against Exim", "local-root exploit against Sudo (Debian, Ubuntu, CentOS)", "local-root exploit against /bin/su", "local-root exploit against ld.so and most SUID-root binaries (Debian, Ubuntu, Fedora, CentOS)", "local-root exploit against /usr/bin/rsh (Solaris 11)", as well as proof of concepts for OpenBSD, FreeBSD and so on.

kseifried3• 9 years ago

Yup, it is, Qualys did some amazing work, and I suspect there are still more problems like this. So if you find stuff like this please let us (Red Hat / etc.) help you help us help everyone (I think that parses correctly =).

blacksmith_tb• 9 years ago

Given macOS's BSD roots, any chance that it could be also be affected?

dgellow• 9 years ago

Could someone explain the situation like if I was 5?

dangerlibrary• 9 years ago

Qualys found some exploits, told parties responsible for fixing the problems, those parties fixed the problems.

These are remarkable because they are conceptually straightforward but the power of the exploits was potentially substantial.

edit: original first sentence was "told Red Hat, Red Hat fixed them." Apparently that was wrong and people (appropriately!) want credit attributed to the right parties.

kseifried3• 9 years ago

Actually no, Qualys told Red Hat and SUSE initially (I asked for early access to confirm how bad it was, Red Hat and SUSE are capable of handling very sensitive embargoed material as we have enough engineers internally to do Kernel/glibc/etc stuff in house) and then we (Red Hat and SUSE) agreed that 1) this was as bad as Qualys said and 2) we need to get the entire community involved ASAP (via the distros list and CC's for people not on it like the Kernel people and so on).

flipp3r• 9 years ago

Slightly easier to read: https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...

"The Stack Clash is a vulnerability in the memory management of several operating systems. (...) It can be exploited by attackers to corrupt memory and execute arbitrary code."

"If you are using Linux, OpenBSD, NetBSD, FreeBSD, or Solaris, on i386 or amd64, you are affected. Other operating systems and architectures may be vulnerable too, but we have not researched any of them yet: please refer to your vendor’s official statement about the Stack Clash for more information."

brohee• 9 years ago

On Linux and most Unices (at least on ix86), the heap starts at the bottom of the address space, and the upper bound grows up as you allocate more memory, while the stack starts at the top of the memory space and grows downward as you allocate more stack (stack allocation : mostly function calls and the odd alloca()). malloc() who manages the heap as no idea of where the stack currently ends, and thus can allocate memory at an adress that is also claimed by the stack. When writing to this address, this permit to smash the stack without needing an actual buffer overflow in the attacked code.

There is good news, this looks way harder to attack on 64 bit systems (all the CVE are on 32 bit OS), possibly because the adress space is so huge, and standard OS counter measure like ASLR, stack gap etc all help protecting against the attack.

jwilk2• 9 years ago

all the CVE are on 32 bit OS

Section IV.1.7 ("64-bit exploitation") mentions CVE-2017-1000379.

clarry6• 9 years ago

malloc() who manages the heap as no idea of where the stack currently ends, and thus can allocate memory at an adress that is also claimed by the stack

The other way around. The kernel has already mapped pages for the stack, and would never hand such pages to malloc unless there's a serious bug in the vm subsystem.

However, code that uses the stack has no idea where the stack ends. And reaching out of the stack is only detected via page faults. If that access happens to land on a mapped page with the right permissions, there is no fault and the code can effectively grow the stack into heap region.

geofft7• 9 years ago

If you're looking for a background on the attack itself, I did a writeup of the basic attack some time ago at https://ldpreload.com/blog/stack-smashes-you . The new thing is that Qualys has developed this into a real class of exploits against lots of software; I think we all thought that it was relatively rare to run into this vulnerability.

staticassertion3• 9 years ago

Take note of the Grsecurity section. We already have the technology necessary to mitigate or significantly reduce the impact of these vulnerabilities.

Solid writeup.

0x05• 9 years ago

On 32bit x86, couldn't the SS segment selector be mapped to a completely different set of memory compared to CS/DS/ES and thus remove the possibiliy of the stack and the heap clashing?

jwilk2• 9 years ago

How would you distinguish between stack pointers and non-stack pointers? Making pointers longer than 32-bit doesn't sound appealing.

0x05• 9 years ago

Good point, I forgot about C allowing passing around pointers to stack variables. Hmm.

cbhl• 9 years ago

It's not clear to me why compiling all userland code with -fstack-check would help. Couldn't you work around that by copying or creating an executable in assembly that doesn't write every 4 KB?

jacksnipe• 9 years ago

Well then you wouldn't be running code generated by -fstack-check, would you?

sloppycee• 9 years ago

The issue isn't that a user can run their own code that can stack smash, rather that a user can exploit the smash to run their code in a privileged context (set-guid, i.e. sudo, su, etc.).

jtchang• 9 years ago

That is a crazy number of CVEs. At a quick glace I am seeing a lot of local root exploits. Generally speaking if a attacker has an account on your system you are already hosed. But this doesn't bode well for more vulnerabilities of this nature that don't require local root.

staticassertion3• 9 years ago

Generally speaking if a attacker has an account on your system you are already hosed.

Keep in mind that software is moving towards a sandboxed world, especially with containers. Local attack surface is becoming increasingly valuable.

geofft7• 9 years ago

On the other hand, all of these are local exploits against userspace software, not against the kernel. So assuming your container's security model works (... which is a big assumption), the most an attacker can do is gain privileges within the container, if you have setuid-container-root binaries inside, or perhaps get arbitrary code execution or something inside the container. But they shouldn't be able to escape.

(That said, the same class of attack is in theory possible in the kernel, although the kernel tends to be way more disciplined about stack usage than userspace software.)

bjornsing3• 9 years ago

Generally speaking if a attacker has an account on your system you are already hosed.

Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them?

pja• 9 years ago

Much larger attack surface => far easier to find exploitable bugs.

fictioncircle2• 9 years ago

Isn't that just saying "I don't believe in multiuser systems and/or their security models"...? If so, what specifically do you have against them?

[Core Services] + SSH is generally something you can harden effectively against attacks.

[2903429034902323094230 binaries] is something you generally struggle to maintain security patches/etc on.

The simple fact is, there is just too much attack surface on a vanilla Linux box once you have an account that you can reliably do EVERYTHING you need to do to secure it 24/7/365.

At least imho, given my time constraints/budget.

ryanlol• 9 years ago

Only clueless people believe in secure multiuser Linux. It's not about the binaries on the box, it's because the kernel is made out of swiss cheese.

kseifried3• 9 years ago

There will probably be more CVEs as people find other setuid apps that can be manipulated (people know what to look for now).

cookiecaper• 9 years ago

I mean, it's certainly some level of access if there's a local privilege escalation, but it's not "your box is already pwned". Proper isolation and correct permissions on the system will keep the damage isolated. I've seen attacks that were more-or-less nerfed because they couldn't find an open local privilege escalation.

I don't think these should be written off as "Well, you're screwed anyway" like we tend to do when discussing security against an attacker who has direct physical access to the hardware. Isolated user accounts are widely used as the model for running services because they provide significant (if non-total) benefit.

busterarm• 9 years ago

A classic always worth reading: http://insecure.org/stf/smashstack.html

age_bronze• 9 years ago

I'm very surprised. I was sure -fstack-check was on by default. The fact that it isn't secure without it is known for years. Windows compilers have had that check for years. The bug isn't in any executables, gcc and all other compilers should have -fstack-check on by default, with optional disable. I'm even more suprised that people who are supposed to know what they are doing don't compile with it.

starmole• 9 years ago

I'm trying my hardest to understand how this is a novel problem. Maybe somebody can help me?

If I control the stack pointer and can write to where it points, I can write to arbitrary in process memory. Sure!

Is that just valuable as a ROP trick?

But if I have that, isn't just writing to the actual stack more valuable? Why does stack growth matter at all besides being a complication where one can not write to one specific page?

How does this get you to write to out of process memory?

clarry6• 9 years ago

If I control the stack pointer and can write to where it points, I can write to arbitrary in process memory. Sure!

But you don't usually have that sort of control. Normally you'd use something like a buffer overflow on a stack allocated buffer.

This thing is a problem even if you have no buffer overflows on stack and do not have arbitrary write access to anywhere on stack.

What's happening here that the program gets confused about how large its stack is, and keeps utilizing more memory than it should for the stack. But that memory is allocated for heap objects, so a simple write to one of these (not requiring any sort of buffer overflow or other such bug to exploit) could be used to smash the stack.

caf6• 9 years ago

Firstly, it's not exactly a novel problem - as the advisory points out, there were earlier public examples of the bug class in 2005 and 2010.

That aside, the issue here is that you can have a program that correctly writes only to properly allocated objects on the heap, and to properly allocated objects on that stack: but if you can get the stack to grow down into the heap without it being detected, now your properly-allocated objects on the heap alias part of the stack (and your properly-allocated objects on the stack alias part of the heap). So now the correct writes done by the program can write to unintended places, like return values on the stack or function pointers in the heap.

The core trick is the "without it being detected" part. What they've done is find places - some of them in library code - that the stack is grown by more than the size of the guard page in one go, and where writing to the guard page itself can be avoided (or in the BSD case, they've found ways that the guard page itself can be disabled). There's also some other clever tricks around expanding the stack and the heap.

The Stack Clash

Related Stories