9 ms·

Can someone give a short explanation of this exploit please? Something a bit deeper than "an attacker can exploit this confusion to overwrite the stack" from th

Can someone give a short explanation of this exploit please? Something a bit deeper than "an attacker can exploit this confusion to overwrite the stack" from the OP, but not the super detailed PDF he references. I'm hoping to get a feel for the root cause of this exploit.

PeterisP 9y ago
The classic vulnerability is that you manage to grow the heap or the stack so that they collide (they start at opposite ends and grow towards the middle) then you get all kinds of exploits possible by stack overwriting the heap or heap overwriting the stack. While you can prevent the heap from being allocated over the stack, the stack may grow "autonomously" during normal processor instructions where the OS can't intervene. The classic fix was to put a "guard page", i.e. a segment of memory marked as forbidden, so if stack would grow into there, it'd trigger a page fault and then the process can be stopped. However, while stack usually grows in small increments, you may allocate some very large data on the stack and not write or read anything in that buffer - so if you do it correctly, the end of the stack will "jump over" that guard page, leaving it in the middle of the stack but not touching it in any way; and the end of the stack will overlap with the heap, enabling all the fun exploits again.
- mysterypie 9y ago
  OK, if I understand correctly, there is no privilege escalation. Eg., running this exploit in user code doesn't get you root. When they described it as a "kernel hole" I assumed it was much worse. So the word "kernel" is there because the design flaw is in the kernel, not because it allows a complete system takeover (unless it's against a privileged program).
  - qb45 9y ago
    Yes, it's a kernel deficiency which only allows taking over userspace processes and only if you are able to cause them to allocate the right memory and write the right data to it.
  - clarry 9y ago
    > So the word "kernel" is there because the design flaw is in the kernel The vulnerability is in the userland process. However, the kernel can utilize a stop-gap measure that makes exploitation difficult in most scenarios (but this is arbitrary).
    - kronos29296 9y ago
      Then why is nobody trying to fix the vulnerability at the source ie. userland process?
      - cyphar 9y ago
        To butcher an LWN quote, "there are potentially millions of buggy programs, but only one kernel". It's a measure to prevent a class of exploit, rather than depending on people writing safe C code (which I believe decades of software engineering have proven we are collectively incapable of doing).
        clarry 9y ago
        This has nothing to do with the (un)safety of C code. The programs do not have to be buggy at the source level. The compiler is the bug.
      - clarry 9y ago
        To do that, you need to have a compiler that has the right features, and then you need to recompile all your software.
      - PeterisP 9y ago
        There exists a fix for the vulnerability at the source, namely, a compiler feature that will add extra code that will "touch" every 4k page of the stack if large amount is allocated. However, for that fix to be useful, every single distribution needs to recompile every single userland package and distribute it to every single user - i.e., instead of downloading a security patch, you need to download a new version of every executable on your hdd.
  - PeterisP 9y ago
    No, this does mean privilege escalation (pretty much all recent proof of concepts for this problem are local user-to-root escalation) because it allows you to engineer a stack/heap overwrite in many non-buggy binaries that run as root.
  - 21 9y ago
    The other article says that this is a privilege escalation: > The exploits and proofs of concept that we developed in the course of our research are all Local Privilege Escalations: an attacker who has any kind of access to an affected system can exploit the Stack Clash vulnerability and obtain full root privileges. https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...
    - loeg 9y ago
      Only if you find an exploitable setuid program.
- radarsat1 9y ago
  Ok so if I have an application that makes a large stack allocation, it's safe as long as that memory is read/written at least once?
  - lmm 9y ago
    Only if it's accessed at least once in each page (4K), AIUI.
    - radarsat1 9y ago
      Right. If I simply zero the memory with `memset` then I guess it should be ok.
      - mnarayan01 9y ago
        No: See http://en.cppreference.com/w/c/string/byte/memset#Notes http://en.cppreference.com/w/c/string/byte/memset#Notes -- if you don't read from it, the call may be optimized away.
      - clarry 9y ago
        Unless the compiler decides that zeroing the memory doesn't do anything useful and optimizes it out.
        astrange 9y ago
        Initializing your stack buffer probably does count as something useful, but in case it doesn't, try memset_s(3).
      - dom0 9y ago
        Like my brethren say it's probably a good idea to use a "secure" memset that won't have an accident ^W ^W ^W be optimized out.
        loeg 9y ago
        Or keep >4kB objects off stack.
- marssaxman 9y ago
  you may allocate some very large data on the stack and not write or read anything in that buffer We had to deal with something very similar to this when I was working on REALbasic. When targeting Windows, if the compiler happened to generate a function prolog which would allocate more than one page of stack space for local variables, we had to generate extra instructions which would touch each intermediate page, in order, or the kernel would trap the first access beyond the guard page as out-of-bounds. It was an interesting bit of semi-security.
qb45 9y ago
I too had to spend a few minutes to understand it. The problem is with stack growing into memory previously allocated with mmap, including but not limited to mmap being used to back up large malloc allocations. If this happens, writing to objects in the mmap-ed area can be used to overwrite stack frame of the current function, including its return address, and hence control code execution after returning. In 2005 it was discovered that when a process fills up all its address space with allocations, Linux will allow an mmap call to allocate memory directly near the top of the stack so that any stack expansion will run into this allocation. This was not fixed. In 2010, Rafal Wojtczuk developed a working exploit against Xorg using this principle. The problem was finally fixed by enforcing a one page gap at the top of the stack where mmap allocations were forbidden and preventing the stack from growing too close to the nearest mmap allocation. TFA author couldn't resist bitching about some technical issues with this patch which were promptly fixed. Unfortunately, one page gap is not enough because it can be "jumped over": a sufficiently vulnerable application can be tricked to mmap memory directly adjacent to the gap and then create a large stack allocation (alloca, variable length array or just a fixed-length array larger than 4kB) which covers the whole gap. As long as this allocation isn't used, the kernel has no way of knowing that it exists. If the application then is tricked into calling another function before using this allocation, a new stack frame is created behind the big allocation and the safety gap, in mmap area.
- loeg 9y ago
  Isn't this a fundamental problem with all small address space architectures? The mitigation of having user programs touch every stack page to ensure the guard page is trapped works, but at some performance penalty.

PeterisP 9y ago

The classic vulnerability is that you manage to grow the heap or the stack so that they collide (they start at opposite ends and grow towards the middle) then you get all kinds of exploits possible by stack overwriting the heap or heap overwriting the stack. While you can prevent the heap from being allocated over the stack, the stack may grow "autonomously" during normal processor instructions where the OS can't intervene. The classic fix was to put a "guard page", i.e. a segment of memory marked as forbidden, so if stack would grow into there, it'd trigger a page fault and then the process can be stopped. However, while stack usually grows in small increments, you may allocate some very large data on the stack and not write or read anything in that buffer - so if you do it correctly, the end of the stack will "jump over" that guard page, leaving it in the middle of the stack but not touching it in any way; and the end of the stack will overlap with the heap, enabling all the fun exploits again.

mysterypie 9y ago
OK, if I understand correctly, there is no privilege escalation. Eg., running this exploit in user code doesn't get you root. When they described it as a "kernel hole" I assumed it was much worse. So the word "kernel" is there because the design flaw is in the kernel, not because it allows a complete system takeover (unless it's against a privileged program).
- qb45 9y ago
  Yes, it's a kernel deficiency which only allows taking over userspace processes and only if you are able to cause them to allocate the right memory and write the right data to it.
- clarry 9y ago
  > So the word "kernel" is there because the design flaw is in the kernel The vulnerability is in the userland process. However, the kernel can utilize a stop-gap measure that makes exploitation difficult in most scenarios (but this is arbitrary).
  - kronos29296 9y ago
    Then why is nobody trying to fix the vulnerability at the source ie. userland process?
    - cyphar 9y ago
      To butcher an LWN quote, "there are potentially millions of buggy programs, but only one kernel". It's a measure to prevent a class of exploit, rather than depending on people writing safe C code (which I believe decades of software engineering have proven we are collectively incapable of doing).
      - clarry 9y ago
        This has nothing to do with the (un)safety of C code. The programs do not have to be buggy at the source level. The compiler is the bug.
    - clarry 9y ago
      To do that, you need to have a compiler that has the right features, and then you need to recompile all your software.
    - PeterisP 9y ago
      There exists a fix for the vulnerability at the source, namely, a compiler feature that will add extra code that will "touch" every 4k page of the stack if large amount is allocated. However, for that fix to be useful, every single distribution needs to recompile every single userland package and distribute it to every single user - i.e., instead of downloading a security patch, you need to download a new version of every executable on your hdd.
- PeterisP 9y ago
  No, this does mean privilege escalation (pretty much all recent proof of concepts for this problem are local user-to-root escalation) because it allows you to engineer a stack/heap overwrite in many non-buggy binaries that run as root.
- 21 9y ago
  The other article says that this is a privilege escalation: > The exploits and proofs of concept that we developed in the course of our research are all Local Privilege Escalations: an attacker who has any kind of access to an affected system can exploit the Stack Clash vulnerability and obtain full root privileges. https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...
  - loeg 9y ago
    Only if you find an exploitable setuid program.
radarsat1 9y ago
Ok so if I have an application that makes a large stack allocation, it's safe as long as that memory is read/written at least once?
- lmm 9y ago
  Only if it's accessed at least once in each page (4K), AIUI.
  - radarsat1 9y ago
    Right. If I simply zero the memory with `memset` then I guess it should be ok.
    - mnarayan01 9y ago
      No: See http://en.cppreference.com/w/c/string/byte/memset#Notes http://en.cppreference.com/w/c/string/byte/memset#Notes -- if you don't read from it, the call may be optimized away.
    - clarry 9y ago
      Unless the compiler decides that zeroing the memory doesn't do anything useful and optimizes it out.
      - astrange 9y ago
        Initializing your stack buffer probably does count as something useful, but in case it doesn't, try memset_s(3).
    - dom0 9y ago
      Like my brethren say it's probably a good idea to use a "secure" memset that won't have an accident ^W ^W ^W be optimized out.
      - loeg 9y ago
        Or keep >4kB objects off stack.
marssaxman 9y ago
you may allocate some very large data on the stack and not write or read anything in that buffer We had to deal with something very similar to this when I was working on REALbasic. When targeting Windows, if the compiler happened to generate a function prolog which would allocate more than one page of stack space for local variables, we had to generate extra instructions which would touch each intermediate page, in order, or the kernel would trap the first access beyond the guard page as out-of-bounds. It was an interesting bit of semi-security.

qb45 9y ago

I too had to spend a few minutes to understand it. The problem is with stack growing into memory previously allocated with mmap, including but not limited to mmap being used to back up large malloc allocations. If this happens, writing to objects in the mmap-ed area can be used to overwrite stack frame of the current function, including its return address, and hence control code execution after returning. In 2005 it was discovered that when a process fills up all its address space with allocations, Linux will allow an mmap call to allocate memory directly near the top of the stack so that any stack expansion will run into this allocation. This was not fixed. In 2010, Rafal Wojtczuk developed a working exploit against Xorg using this principle. The problem was finally fixed by enforcing a one page gap at the top of the stack where mmap allocations were forbidden and preventing the stack from growing too close to the nearest mmap allocation. TFA author couldn't resist bitching about some technical issues with this patch which were promptly fixed. Unfortunately, one page gap is not enough because it can be "jumped over": a sufficiently vulnerable application can be tricked to mmap memory directly adjacent to the gap and then create a large stack allocation (alloca, variable length array or just a fixed-length array larger than 4kB) which covers the whole gap. As long as this allocation isn't used, the kernel has no way of knowing that it exists. If the application then is tricked into calling another function before using this allocation, a new stack frame is created behind the big allocation and the safety gap, in mmap area.

loeg 9y ago
Isn't this a fundamental problem with all small address space architectures? The mitigation of having user programs touch every stack page to ensure the guard page is trapped works, but at some performance penalty.