On Wed, 2017-07-05 at 10:23 -0700, Andy Lutomirski wrote: [...] > Looking at it that way, I think a new inherited-on-exec flag is nucking futs. > > I'm starting to think that the right approach is to mostly revert all > this stuff (the execve fixes are fine). Then start over and think > about it as hardening. I would suggest the following approach: > > - The stack gap is one page, just like it's been for years.
Given that in the following points you say that something sounding like a stack gap would be "64k or whatever", what does "the stack gap" mean in this first point? > - As a hardening feature, if the stack would expand within 64k or > whatever of a non-MAP_FIXED mapping, refuse to expand it. (This might > have to be a non-hinted mapping, not just a non-MAP_FIXED mapping.) > The idea being that, if you deliberately place a mapping under the > stack, you know what you're doing. If you're like LibreOffice and do > something daft and are thus exploitable, you're on your own. > - As a hardening measure, don't let mmap without MAP_FIXED position > something within 64k or whatever of the bottom of the stack unless a > MAP_FIXED mapping is between them. Having tested patches along these lines, I think the above would avoid the reported regressions. Ben. > And that's all. It's not like a 64k gap actually fixes these bugs for > real -- it just makes them harder to exploit. > > [1] The code that GCC generates for char buf[bug number] and alloca() > is flat-out wrong. Everyone who's ever thought about it all all knows > it and has known about it for years, but no one cared to fix it. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer.
signature.asc
Description: This is a digitally signed message part
