LWN: Comments on "Stable kernels 4.11.7 and 4.9.34"

Stable kernels 4.11.7 and 4.9.34

nix — Wed, 28 Jun 2017 22:48:26 +0000

The feasibility of different variants of this mean it all depends. If you can make an array on the stack of any size that you want, and you happen to know where a heap allocation is, or maybe the stack of a different thread, then you can make your stack pointer jump an arbitrary amount so it points to that other location.
If no stack extension happened because you missed the guard page and no code checks the SP register distance then your attack is good.

Yeah. However, this is still true now, with an updated glibc and kernel. With everything rebuilt with the new -fstack-check, an attempt to use a VLA to do this will fail because stack probes every 4KiB in that huge array will hit the guard page (I *think* alloca() will fail the same way but I'm not sure) -- but before that happens, giant stack allocations are risky. All the kernel changes do is make it harder to do this in jumps smaller than a megabyte: a single huge leap to a computed target will still work.

This is why glibc's been on a frenzy of removal of alloca() of late, with alloca()-removals that may allow exploitation across the setuid boundary being pushed back into the 2.25 stable tree.

Stable kernels 4.11.7 and 4.9.34

zlynx — Tue, 27 Jun 2017 20:01:43 +0000

The feasibility of different variants of this mean it all depends. If you can make an array on the stack of any size that you want, and you happen to know where a heap allocation is, or maybe the stack of a different thread, then you can make your stack pointer jump an arbitrary amount so it points to that other location.

If no stack extension happened because you missed the guard page and no code checks the SP register distance then your attack is good.

As far as I know the kernel only checks the stack limit when extending the stack from the stack guard page fault. I suppose that it could also check the stack register on kernel entry but that may be too late.

Stable kernels 4.11.7 and 4.9.34

nix — Mon, 26 Jun 2017 17:09:29 +0000

The Qualys advisory says as much, but it also follows from the nature of the attack: you have to blow out the stack until it runs into the heap, and if the kernel kills you as soon as you blow out the stack that far but before you can do anything with it, the attack cannot proceed.

Stable kernels 4.11.7 and 4.9.34

NightMonkey — Mon, 26 Jun 2017 02:28:26 +0000

Oh, that's great news (caveat accepted). Is there a page somewhere that describes how RLIMIT_STACK adjustment affects the chance of exploit? Or did you just figure it out because... you are a kernel developer? :D

Stable kernels 4.11.7 and 4.9.34

nix — Mon, 26 Jun 2017 00:00:41 +0000

I'm reasonably sure that people who can't upgrade can still use a sane not-too-huge RLIMIT_STACK to avoid this class of attack for the time being (64MiB, say, or even less -- I've been running with 32MiB for many years with no problems: very few programs need a stack larger than that!)

If that's so... take your time, not having the patch running is not disastrous.

Stable kernels 4.11.7 and 4.9.34

hmh — Sun, 25 Jun 2017 20:23:00 +0000

Just keep in mind that the Qualys exploits go public soon (this tuesday, if I am not wrong).

Stable kernels 4.11.7 and 4.9.34

sashal — Sun, 25 Jun 2017 18:03:46 +0000

4.1 will come soon. Backports indeed weren't trivial, and I'm waiting to see there are no obvious regressions with the other stable kernels.

Stable kernels 4.11.7 and 4.9.34

hmh — Sun, 25 Jun 2017 16:16:38 +0000

I am not sure about 4.1.x, but from posts to LKML, one can safely say that backporting all of the stack-clash to the older kernels was not trivial.

The work seems to be largely done now, so I'd expect 3.18 and earlier to get new releases soon. Maybe that also applies to 4.1.x...

Stable kernels 4.11.7 and 4.9.34

arekm — Sat, 24 Jun 2017 20:55:59 +0000

We miss 4.1 updates for the issue :/