# CVE-2017-1000364 - The Stack Clash

## Shoaloak

What is the Stack Clash?

 *Quote:*   

> The Stack Clash is a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64.  It can be exploited by attackers to corrupt memory and execute arbitrary code.

 

I don't see Gentoo mentioned on this page, but I presume it's also affected.

Do i have to recompile all my userland software with -fstack-check now? Or is -fstack-check broken as mentioned here?

----------

## krinn

never seen a blog so badly written!

it starts the fear by aiming all OS, while the linux kernel is at fault, but it's more scarier to say everyone than kernel.

it also "forget" to provide any kernel versions affected, so you have no idea if you are affect or not

and it gently hint you to patch the hole, but no way you can find any ref to grab the patch...

what a bunch of suckers, it certainly not remove the fact they have find a security issue, but the way they are handling it is so dirty that it put more shame than shine on them.

i don't think the stack-check would protect anyone from this, this is a gcc option, and i suppose gcc is doing some stack range checking while building the code.

while the issue is that if you are allocating the stack close to another already in use region, you can bypass that and overlap the other memory region ; that's something you can check while asking the stack allocation, not while compiling.

so a runtime issue, not a compiling issue.

----------

## Shoaloak

 *krinn wrote:*   

> i don't think the stack-check would protect anyone from this, this is a gcc option, and i suppose gcc is doing some stack range checking while building the code. 
> 
> while the issue is that if you are allocating the stack close to another already in use region, you can bypass that and overlap the other memory region ;

 

In their advisory they do say that "-fstack-check" fixes the problem, unless a vulnerability is discovered in the implementation of the stack guard-page.

 *Quote:*   

> Based on our research, we recommend that the affected operating systems:
> 
> - Increase the size of the stack guard-page to at least 1MB, and allow
> 
>   system administrators to easily modify this value (for example,
> ...

 

 *krinn wrote:*   

> never seen a blog so badly written! 

 

I dunno, it looks kinda legit...

 *krinn wrote:*   

> that's something you can check while asking the stack allocation, not while compiling.  so a runtime issue, not a compiling issue.

 

So you are saying that all software should check stack allocation during runtime?

----------

## krinn

 *Shoaloak wrote:*   

>  *krinn wrote:*   that's something you can check while asking the stack allocation, not while compiling.  so a runtime issue, not a compiling issue. 
> 
> So you are saying that all software should check stack allocation during runtime?

 

Yes and no, i'm saying that's kernel task to handle memory allocation, and kernel task then to check stack allocation remain within "normal" constrains.

gcc is a compiler, it have some "safety" checks while building to prevent yourself from doing something bad by mistake.

but it's not gcc task to prevent someone that WANT do bad to do it.

if we follow your logic: to hack any linux, just compile something with a compiler that doesn't have this check and you're good  :Smile: 

----------

## krinn

 *Shoaloak wrote:*   

>  *krinn wrote:*   never seen a blog so badly written!  
> 
> I dunno, it looks kinda legit...

 

I'm not saying that, nor i don't grant them the fame for finding it.

But how this blog is written, how the information is given.

----------

## 1clue

First thing I do is NOT read blogs about a vulnerability until I've read the report from an officially recognized database.

https://nvd.nist.gov/vuln/detail/CVE-2017-1000364

Since there was a comment about the OP's link being terribly written, I won't bother looking at that.

Unfortunately I need to do something else right now so I can't read the CVE details yet, but my post here will hopefully help others as well as subscribe me to the thread for later.

----------

## eccerr0r

From my take:

- local exploit.  Remote exploit very hard, depends on program.

- ALL kernels are affected except possibly for grsec that can adjust stack guard page size, or at least there seems to be some implication they had a "fix" for it by simply adjusting guard page.

- There has to be a suid root program that you can manipulate the stack and heap with (and ld.so appears to be necessarily modifiable, so it's the death of virtually all SUID programs).

- ld.so is part of glibc

- Gentoo is not an "affected vendor" because we get no creds due to "small" following (are Gentoo users > OpenBSD users?  Honestly I think this is very possible yet they still ignore us.)

- Seems the easiest solution is to increase stack guard page size (kernel patch), else recompile all suid programs with -fstack-protector

Summary:

- We ARE affected and have no patch

- Easiest mitigating but not solving patch is for kernel to increase stack protection page size, they suggest 1MB which sounds reasonable  Not sure what this will mean to low memory systems but these pages should point to invalid memory anyway.

- glibc(ld.so) patch is needed to help existing programs.

- I think we can fix this with recompiling suid programs with -fstack-protector (if gcc honors this properly), and minimally also including glibc...  -fstack-protector will be a performance hit.

----------

## Ant P.

Are musl users safe?

----------

## eccerr0r

 *Ant P. wrote:*   

> Are musl users safe?

 

Unknown (and same goes to uclibc).  My guess is that likely musl and uclibc are also affected, as the dynamic link loader code is probably shared between each of the libraries (glibc, uclibc, musl, etc.) - Did BSD drop off of glibc?  If they're also affected...

----------

## Hu

I read the full analysis when it was mentioned on LWN.  I mostly agree with eccerr0r's analysis, although I disagree on a few points.  My take on the problem:-fstack-protector is not necessarily a fix here.  The writeup makes some strange claims about their techniques bypassing SSP due to exploiting a function which has no stack cookie.  This was not explained to my satisfaction, but I think the point they were trying to make is that the out-of-line implementation of memcpy in glibc is built without -fstack-protector (even on hardened systems that default -fstack-protector on!), so if the evil overwrite is done by a call to memcpy, then SSP is (locally) irrelevant.  You can check this locally using objdump -d /lib/libc.so.6 | sed -n -e '/<memcpy>:/,/^$/p' (caution: output may be long).That said, Gentoo Hardened seems to default on -fstack-check, which the analysis says is believed to be an effective defense.A kernel change slipped in to v4.12-rc6 is supposed to help with this by enlarging the stack guard page on non-grsecurity kernels.  The change drew attention in part because it is a fairly large change (by lines changed) for such a late stage -rc kernel.  This change is necessarily imperfect (much like ASLR: it makes the exploit harder, it cannot guarantee prevention).  A large enough displacement can still beat it.  The hope is that the size chosen is large enough to protect all programs while being small enough not to consume too much address space.As an incidental workaround, since this is a user-mode privilege escalation, it can only be performed if the attacker can run a privileged program with inputs that provoke this bug.  Attackers who are denied the opportunity to run any privileged programs (whether via aggressive use of nosuid mounts, applying PR_SET_NO_NEW_PRIVS to processes, etc.) will find that the target program is not privileged, so exploiting it gains them nothing.  This is not a full mitigation, since some users may be trusted to run some privileged programs if those programs are in turn trusted not to allow the user free reign of the system.

krinn: the change is mm: larger stack guard gap, between vmas by Hugh Dickins (@Google).  All kernel versions prior to v4.12-rc6 are affected, although as eccerr0r describes, there is a large gap between having an affected kernel and needing to immediately apply a patch.  I think you misunderstand -fstack-check.  It is an option, similar to -fstack-protector, -pie, and such that instruct gcc to build the code differently.  In this case, -fstack-check arranges that every function with an eligible stack allocation will perform a dummy write to specific addresses on the stack.  By itself, this write is pointless.  When combined with the kernel's guard page, this write ensures that the guard page is accessed (thus notifying the kernel of stack growth) before the stack pointer is used in a way that could be dangerous.  The kernel can then react to this growth by allocating more stack pages or, if necessary, killing the program.

Shoaloak: yes, in cooperation with the kernel, every program must check every stack allocation.  -fstack-check does this in an automated fashion.  It requires nothing more from the programmer than that they refrain from using clever tricks to allocate stack without the compiler's knowledge (such as inline assembly that changes the stack pointer).

krinn + Shoaloak: the kernel cannot, on its own, check stack allocations.  On most (maybe all) platforms, stack allocation in this context is merely changing the value of the stack pointer.  The kernel is not notified when this happens.  (Complain to your instruction set designers if you find this objectionable.  Then wait while we replace all CPUs everywhere.)  The kernel is notified if the program writes to a page that is marked as non-writable, such as the stack guard page.  This exploit is predicated on tricking the program into moving the stack pointer so far in a single bound that it skips from writing above the guard page to writing below it, without ever writing to it.  The kernel can only detect a write to the guard page.  If there is nothing below the guard page, that would be detected, but the exploit specifically arranges that there will be something below the guard page.

I expect that all C libraries are affected, although libraries that build their memcpy and similar with SSP would be more difficult to exploit.

----------

## eccerr0r

My attempt at backporting "big stack protector" to sys-kernel/gentoo-sources-4.9.16 - trying to build now on x86.

https://pastebin.com/Rp21UKjJ

Note: this paste expires in 1 month from today as I'm sure we'll have an authentic fix by then...

----------

## krinn

thank you eccerr0r, appreciate the sharing!!!

----------

## eccerr0r

My main x86 (shell) "box" is a VM and is no less critical than the host it runs on... though I suppose I'll need to reboot both again later.

I've been slacking and the VM has been running 4.4.38, so no better excuse for an upgrade.

```
doujima:/usr/src/linux-4.9.16-gentoo$ uname -a

Linux doujima 4.9.16-gentoo #1 SMP Wed Jun 21 13:59:08 MDT 2017 i686 Intel Core 2 Duo P9xxx (Penryn Class Core 2) GenuineIntel GNU/Linux

doujima:/usr/src/linux-4.9.16-gentoo$ nm vmlinux|grep stack_guard_gap

c14efc91 t cmdline_parse_stack_guard_gap

c1536f4c t __setup_cmdline_parse_stack_guard_gap

c152853d t __setup_str_cmdline_parse_stack_guard_gap

c14ae698 D stack_guard_gap

```

At least the symbols show up, and the kernel builds/runs...

Now I need the exploit to really know if it works....

NOTE:  The default for this patch is 256 pages, or 1MB (since x86 uses 4K pages) and you can change the size by a boot command line option stack_guard_gap=XXX where XXX is the number of pages.  Though the stack protector pages is not actually wasting physical memory for this, it is eating into the virtual address space (if you're using 3G/1G split you just lost ... 1/3072 of your address space...  Probably not a big deal unless you were running up against the address space limit.

----------

## eccerr0r

https://bugs.gentoo.org/show_bug.cgi?id=622230

----------

