8 ms·

An Ancient Kernel Hole Is Not Closed

180 points by CaliforniaKarl 9y ago

AndyMcConachie 9y ago
After reading through the original Qualys discussion[1] of this new vuln I was definitely left with a feeling that this class of bugs has not yet exhausted its treasure trove of vulns. This article only confirms it. Very interesting discussion that will likely continue as more people wrap their heads around this tough problem. [1] https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...
- IshKebab 9y ago
  Is it that tough? Everything says Windows/MSVC isn't affected.
  - mnarayan01 9y ago
    Yes. I believe Windows requires you to specify a maximum reserved stack size in the program executable. That's...not going to happen for e.g. Linux.
    - smhenderson 9y ago
      That's correct and any of the various MS runtime libraries simply set it by default if you didn't. Thus this error[1] (in C) and this[2] (in VB). I remember these from pre-dotNet days but based on the second link it looks not much has changed in VB.net. [1]https://msdn.microsoft.com/en-us/library/aa264523(v=vs.60).aspx https://msdn.microsoft.com/en-us/library/aa264523(v=vs.60).a... [2]https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/error-messages/out-of-stack-space https://docs.microsoft.com/en-us/dotnet/visual-basic/languag...
    - clarry 9y ago
      The reservation is not particularly relevant though.
    - IshKebab 9y ago
      So how does it detect stack overflows past that limit? Edit: Looks like a fix for LLVM being proposed (https://reviews.llvm.org/D9653 https://reviews.llvm.org/D9653) is just to probe every page that a stack allocation covers, rather than just the final one. Doesn't sound tough at all.
- daveguy 9y ago
  So the title should read "is not closed"? The parenthesis are just annoying. It's one or the other, just state it! Readers shouldn't have to solve a puzzle to read a title.
  - sdrothrock 9y ago
    First read to me as someone who hadn't read the article was "someone found an ancient kernel hole and declared it closed, but in truth it's actually not," which actually seems to be what was intended... it's a fairly common use of "(not)."
  - nullc 9y ago
    The title is a play on a 2010 LWN headline. This is explained in the article. But reading the article has never been a barrier for HN editing a headline to make it less accurate in the past, so why start now? :)
  - CaliforniaKarl 9y ago
    I'm sorry, I'm really confused now. Here's the title of the article: An Ancient Kernel Hole is (Not) Closed I thought that I copy-pasted the article title to be the title of this submission. Did I omit the parenthesis? If so, it was unintentional, and I apologize.
    - enzanki_ars 9y ago
      HN automatically removes certain punctuation from post titles. In a lot of cases though, it creates more confusion. Definitely not your fault.
      - CaliforniaKarl 9y ago
        I did not know that! I'm tempted to experiment now 8-) Thanks for the heads-up!
nullc 9y ago
Too bad this comment never got a reply: https://lwn.net/Articles/401227/ https://lwn.net/Articles/401227/
- fidget 9y ago
  That's GRSecurity for you
- CaliforniaKarl 9y ago
  It seems to me that this is a clash of personalities. Linus has been as acerbic before. See https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75, for example. Open Source Security (the company behind grsecurity) is still existing, so it's got enough customers to support the grsecurity developers (both the ones we know, as well as (presumably) PaX Team). It seems to me like grsecurity aren't interested in upstreaming their patches. That's one reason (among others) why their patches are distributed as one big file, instead of (for example) a patch set or a Git branch. Why are they not interested? Well, it seems to me like Linux devs may not have placed as high a value on security, when compared to other metrics (such as performance). I understand what it's like to be advocating for a position, not finding acceptance after a long try; finally saying "screw it" and going their own (commercial) way. So any 'debate' related to grsecurity is going to include people (including LWN commenters) who feel very strongly against grsecurity's position, and how they should be more open, and free, and willing to compromise (if that's the right word) to get the grsecurity/PaX Team patches upstreamed. And then you have very strong personalities in the kernel dev community. That makes compromise very difficult. It my opinion, it's the same reason why having a conversation related to politics is nigh impossible: Your strong views affect what you say, how you say it, what you hear and how your perceive it.
  - pitaj 9y ago
    Linus is epic.
  - deleted 9y ago
    [deleted]
  - 9y ago
gaius 9y ago
That's a bit of a mouthful for a ever more commonplace occurence. I propose we refer to this class of vulnerability as "k-holes".
darawk 9y ago
Interesting. I independently dreamt up this class of vulnerability in 2007 or so. I didn't know there were any instances of it in the wild. When I realized it ought to be possible, I just wrote a PoC vulnerable app and an exploit for it, and then sort of forgot about it. Cool to see it's a real thing now.
- yjftsjthsd-h 9y ago
  Link? It might be useful to see a simple example
  - darawk 9y ago
    Unfortunately I don't think I have the code anymore. But the gist of it is that say you have two threads in a process. One of the threads contains a function like this: void recurse (int m, int n) { char arr[n] recurse(m--, n) } If 'm' and 'n' are user-controlled, 'recurse' is executing in thread A, and thread A's stack is above thread B's stack, then you can cause 'recurse' to recurse down to the point that it makes its way into thread B's stack region. Normally, this is prevented by 'guard pages' in between the two thread's stacks. However, if you have a variable length array, as in the example, it's possible to allocate enough memory to just skip right over the guard page. Once you've done this, you're now writing directly into the other thread's stack, with all the fun stuff that entails.
mysterypie 9y ago
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.
    - 9y ago
rob-olmos 9y ago
Red Hat's vulnerability page: https://access.redhat.com/security/vulnerabilities/stackguard https://access.redhat.com/security/vulnerabilities/stackguar... Implemented the 1MiB guard page and glibc hardening.

After reading through the original Qualys discussion[1] of this new vuln I was definitely left with a feeling that this class of bugs has not yet exhausted its treasure trove of vulns. This article only confirms it. Very interesting discussion that will likely continue as more people wrap their heads around this tough problem. [1] https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash https://blog.qualys.com/securitylabs/2017/06/19/the-stack-cl...

IshKebab 9y ago
Is it that tough? Everything says Windows/MSVC isn't affected.
- mnarayan01 9y ago
  Yes. I believe Windows requires you to specify a maximum reserved stack size in the program executable. That's...not going to happen for e.g. Linux.
  - smhenderson 9y ago
    That's correct and any of the various MS runtime libraries simply set it by default if you didn't. Thus this error[1] (in C) and this[2] (in VB). I remember these from pre-dotNet days but based on the second link it looks not much has changed in VB.net. [1]https://msdn.microsoft.com/en-us/library/aa264523(v=vs.60).aspx https://msdn.microsoft.com/en-us/library/aa264523(v=vs.60).a... [2]https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/error-messages/out-of-stack-space https://docs.microsoft.com/en-us/dotnet/visual-basic/languag...
  - clarry 9y ago
    The reservation is not particularly relevant though.
  - IshKebab 9y ago
    So how does it detect stack overflows past that limit? Edit: Looks like a fix for LLVM being proposed (https://reviews.llvm.org/D9653 https://reviews.llvm.org/D9653) is just to probe every page that a stack allocation covers, rather than just the final one. Doesn't sound tough at all.
daveguy 9y ago
So the title should read "is not closed"? The parenthesis are just annoying. It's one or the other, just state it! Readers shouldn't have to solve a puzzle to read a title.
- sdrothrock 9y ago
  First read to me as someone who hadn't read the article was "someone found an ancient kernel hole and declared it closed, but in truth it's actually not," which actually seems to be what was intended... it's a fairly common use of "(not)."
- nullc 9y ago
  The title is a play on a 2010 LWN headline. This is explained in the article. But reading the article has never been a barrier for HN editing a headline to make it less accurate in the past, so why start now? :)
- CaliforniaKarl 9y ago
  I'm sorry, I'm really confused now. Here's the title of the article: An Ancient Kernel Hole is (Not) Closed I thought that I copy-pasted the article title to be the title of this submission. Did I omit the parenthesis? If so, it was unintentional, and I apologize.
  - enzanki_ars 9y ago
    HN automatically removes certain punctuation from post titles. In a lot of cases though, it creates more confusion. Definitely not your fault.
    - CaliforniaKarl 9y ago
      I did not know that! I'm tempted to experiment now 8-) Thanks for the heads-up!

nullc 9y ago

Too bad this comment never got a reply: https://lwn.net/Articles/401227/ https://lwn.net/Articles/401227/

fidget 9y ago
That's GRSecurity for you
CaliforniaKarl 9y ago
It seems to me that this is a clash of personalities. Linus has been as acerbic before. See https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75, for example. Open Source Security (the company behind grsecurity) is still existing, so it's got enough customers to support the grsecurity developers (both the ones we know, as well as (presumably) PaX Team). It seems to me like grsecurity aren't interested in upstreaming their patches. That's one reason (among others) why their patches are distributed as one big file, instead of (for example) a patch set or a Git branch. Why are they not interested? Well, it seems to me like Linux devs may not have placed as high a value on security, when compared to other metrics (such as performance). I understand what it's like to be advocating for a position, not finding acceptance after a long try; finally saying "screw it" and going their own (commercial) way. So any 'debate' related to grsecurity is going to include people (including LWN commenters) who feel very strongly against grsecurity's position, and how they should be more open, and free, and willing to compromise (if that's the right word) to get the grsecurity/PaX Team patches upstreamed. And then you have very strong personalities in the kernel dev community. That makes compromise very difficult. It my opinion, it's the same reason why having a conversation related to politics is nigh impossible: Your strong views affect what you say, how you say it, what you hear and how your perceive it.
- pitaj 9y ago
  Linus is epic.
- deleted 9y ago
  [deleted]
- 9y ago

gaius 9y ago

That's a bit of a mouthful for a ever more commonplace occurence. I propose we refer to this class of vulnerability as "k-holes".

darawk 9y ago

Interesting. I independently dreamt up this class of vulnerability in 2007 or so. I didn't know there were any instances of it in the wild. When I realized it ought to be possible, I just wrote a PoC vulnerable app and an exploit for it, and then sort of forgot about it. Cool to see it's a real thing now.

yjftsjthsd-h 9y ago
Link? It might be useful to see a simple example
- darawk 9y ago
  Unfortunately I don't think I have the code anymore. But the gist of it is that say you have two threads in a process. One of the threads contains a function like this: void recurse (int m, int n) { char arr[n] recurse(m--, n) } If 'm' and 'n' are user-controlled, 'recurse' is executing in thread A, and thread A's stack is above thread B's stack, then you can cause 'recurse' to recurse down to the point that it makes its way into thread B's stack region. Normally, this is prevented by 'guard pages' in between the two thread's stacks. However, if you have a variable length array, as in the example, it's possible to allocate enough memory to just skip right over the guard page. Once you've done this, you're now writing directly into the other thread's stack, with all the fun stuff that entails.

mysterypie 9y ago

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

rob-olmos 9y ago

Red Hat's vulnerability page: https://access.redhat.com/security/vulnerabilities/stackguard https://access.redhat.com/security/vulnerabilities/stackguar... Implemented the 1MiB guard page and glibc hardening.