CVE-2017-1000364 - The Stack Clash

[Shoaloak]

What is the Stack Clash?

[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]

[krinn]

[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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Ant P.]

Are musl users safe?

[eccerr0r]

[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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[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.

[eccerr0r]

https://bugs.gentoo.org/show_bug.cgi?id=622230
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?