
An Ancient Kernel Hole Is Not Closed - CaliforniaKarl
https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php
======
AndyMcConachie
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-
cl...](https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash)

~~~
daveguy
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.

~~~
CaliforniaKarl
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
HN automatically removes certain punctuation from post titles. In a lot of
cases though, it creates more confusion. Definitely not your fault.

~~~
CaliforniaKarl
I did not know that! I'm tempted to experiment now 8-)

Thanks for the heads-up!

------
nullc
Too bad this comment never got a reply:
[https://lwn.net/Articles/401227/](https://lwn.net/Articles/401227/)

~~~
CaliforniaKarl
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.

~~~
jchw
Honestly, grsec has rightly earned a reputation for being hostile and even
irresponsible with their conduct, regardless of how good their patches are (of
course, the quality is known to be high- but there have been some blunders.
Don't run `script /dev/null </dev/zero` on an older grsec kernel ;)

------
mysterypie
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
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
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).

~~~
clarry
> 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
Then why is nobody trying to fix the vulnerability at the source ie. userland
process?

~~~
PeterisP
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.

~~~
loeg
It could be limited to only programs that are setuid.

~~~
stouset
This applies generally to any program running as root (or a user with other
privileges than yourself) if you can find a way to allocate a large enough
segment of memory.

~~~
loeg
So setuid programs and network servers, for example.

------
darawk
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
Link? It might be useful to see a simple example

~~~
darawk
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.

------
rob-olmos
Red Hat's vulnerability page:
[https://access.redhat.com/security/vulnerabilities/stackguar...](https://access.redhat.com/security/vulnerabilities/stackguard)

Implemented the 1MiB guard page and glibc hardening.

------
gaius
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".

