11 ms·

The Stack Clash

279 points by fcambus 9y ago

0x0 9y ago
This looks pretty brutal. Quote from Kurt Seifried of RedHat http://www.openwall.com/lists/oss-security/2017/06/19/2 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/msg00146.html https://lists.debian.org/debian-security-announce/2017/msg00... linux https://lists.debian.org/debian-security-announce/2017/msg00148.html https://lists.debian.org/debian-security-announce/2017/msg00... exim4 https://lists.debian.org/debian-security-announce/2017/msg00147.html https://lists.debian.org/debian-security-announce/2017/msg00... libffi https://lists.debian.org/debian-security-announce/2017/msg00149.html 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.
- kseifried 9y 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 9y ago
  Given macOS's BSD roots, any chance that it could be also be affected?
dgellow 9y ago
Could someone explain the situation like if I was 5?
- dangerlibrary 9y 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.
  - deleted 9y ago
    [deleted]
  - kseifried 9y 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 9y ago
  Slightly easier to read: https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash 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 9y 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.
staticassertion 9y 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.
0x0 9y 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?
- jwilk 9y ago
  How would you distinguish between stack pointers and non-stack pointers? Making pointers longer than 32-bit doesn't sound appealing.
  - 0x0 9y ago
    Good point, I forgot about C allowing passing around pointers to stack variables. Hmm.
    - 0x0 9y ago
      What if you set up SS to mirror DS, but with a limited range so that any attempt to access memory outside the stack via SS: causes a page fault? Wouldn't any exploit running ESP down into the heap be thwarted by any stack-related instruction (push, pop, or an interrupt?)
      - ajenner 9y ago
        The accesses causing issues here are not guaranteed to use SS - that only happens for effective addresses [ebp+...] and [esp+...]. If ESP is copied into another register first (which in practice will almost always be the case) then the access will use DS. PUSH will always use SS but that's not the issue here (that only moves ESP by 4 bytes so it'll always hit the guard page). And in modern OSes, interrupts don't use the user mode stack at all - the CPU will switch to kernel mode and use a kernel stack since the user mode stack isn't guaranteed to be valid.
        0x0 9y ago
        Interesting. I was just curious if it would be impossible to write shellcode without triggering an SS:ESP access (via call,push,pop,ret) that would page fault due to protection/selector limits, because that seemed like a neat way to mitigate.
cbhl 9y 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 9y ago
  Well then you wouldn't be running code generated by -fstack-check, would you?
- sloppycee 9y 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 9y 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.
- staticassertion 9y 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.
  - geofft 9y 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.)
    - staticassertion 9y ago
      Good points! I also appreciated your writeup on this class of attacks.
    - kevinr 9y ago
      As we have seen with old SSL versions and Windows XP, it will be 10-15 years before the whole world is migrated onto containerized software, so this exploit should have a long, long active life.
    - caf 9y ago
      It probably makes sense these days to differentiate between "local root" and "container root" in security advisories.
busterarm 9y ago
A classic always worth reading: http://insecure.org/stf/smashstack.html http://insecure.org/stf/smashstack.html
age_bronze 9y 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 9y 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?
- clarry 9y 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.
- caf 9y 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.

279 points by fcambus 9y ago

0x0 9y ago

This looks pretty brutal. Quote from Kurt Seifried of RedHat http://www.openwall.com/lists/oss-security/2017/06/19/2 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/msg00146.html https://lists.debian.org/debian-security-announce/2017/msg00... linux https://lists.debian.org/debian-security-announce/2017/msg00148.html https://lists.debian.org/debian-security-announce/2017/msg00... exim4 https://lists.debian.org/debian-security-announce/2017/msg00147.html https://lists.debian.org/debian-security-announce/2017/msg00... libffi https://lists.debian.org/debian-security-announce/2017/msg00149.html 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.

kseifried 9y 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 9y ago
Given macOS's BSD roots, any chance that it could be also be affected?

dgellow 9y ago

Could someone explain the situation like if I was 5?

dangerlibrary 9y 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.
- deleted 9y ago
  [deleted]
- kseifried 9y 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 9y ago
Slightly easier to read: https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash 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 9y 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.

staticassertion 9y 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.

0x0 9y 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?

jwilk 9y ago
How would you distinguish between stack pointers and non-stack pointers? Making pointers longer than 32-bit doesn't sound appealing.
- 0x0 9y ago
  Good point, I forgot about C allowing passing around pointers to stack variables. Hmm.
  - 0x0 9y ago
    What if you set up SS to mirror DS, but with a limited range so that any attempt to access memory outside the stack via SS: causes a page fault? Wouldn't any exploit running ESP down into the heap be thwarted by any stack-related instruction (push, pop, or an interrupt?)
    - ajenner 9y ago
      The accesses causing issues here are not guaranteed to use SS - that only happens for effective addresses [ebp+...] and [esp+...]. If ESP is copied into another register first (which in practice will almost always be the case) then the access will use DS. PUSH will always use SS but that's not the issue here (that only moves ESP by 4 bytes so it'll always hit the guard page). And in modern OSes, interrupts don't use the user mode stack at all - the CPU will switch to kernel mode and use a kernel stack since the user mode stack isn't guaranteed to be valid.
      - 0x0 9y ago
        Interesting. I was just curious if it would be impossible to write shellcode without triggering an SS:ESP access (via call,push,pop,ret) that would page fault due to protection/selector limits, because that seemed like a neat way to mitigate.

cbhl 9y 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 9y ago
Well then you wouldn't be running code generated by -fstack-check, would you?
sloppycee 9y 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 9y 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.

staticassertion 9y 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.
- geofft 9y 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.)
  - staticassertion 9y ago
    Good points! I also appreciated your writeup on this class of attacks.
  - kevinr 9y ago
    As we have seen with old SSL versions and Windows XP, it will be 10-15 years before the whole world is migrated onto containerized software, so this exploit should have a long, long active life.
  - caf 9y ago
    It probably makes sense these days to differentiate between "local root" and "container root" in security advisories.

busterarm 9y ago

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

age_bronze 9y 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 9y 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?

clarry 9y 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.
caf 9y 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.