Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1684373

Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3

Show all headers | View raw

On Mon, Jul 10, 2017 at 6:13 AM, Michal Hocko <mhocko@kernel.org> wrote:
> I am not sure whether this is still actual because there are just too
> many pathes flying around these days. I am still trying to catch up...

Linus applied this one, yes.

>
> On Fri 07-07-17 11:57:29, Kees Cook wrote:
>> To avoid pathological stack usage or the need to special-case setuid
>> execs, just limit all arg stack usage to at most _STK_LIM / 4 * 3 (6MB).
>
> I am worried that we've grown  users which rely on a large argument
> lists and now we are pulling more magic constants into the game. This
> just calls for another breakage.

I think it would be best to only apply this to setuid processes, but
Linus asked that this change be universal. After my secureexec
refactoring, I think it should be possible to add a "how much stack
has already been used?" check in setup_new_exec() and abort the
privileged exec if it exceeds the secureexec stack limit.

> I think we should simply step back and think about what we want to fix
> here actually. If this is the pathological case when the attacker can
> grow the stack too large and too close to a regular mappings then we
> already have means to address that (stack gap).

I think Linus's intention is to back off from the stack gap, but maybe
I misunderstood.

> If we are worried that mmaps can get way too close to the stack then
> I would question why this is possible at all. Bottom-up layout will
> require consuming mmap space and top-down layout seems just broken
> because we do not try to offset the mmap_base relative to the stack and
> rather calculate both from TASK_SIZE. Or at least this is my current
> undestanding. Am I missing something? Aren't we just trying to fix a bug
> at a wrong place?

With a variable stack limit, we'll continue to run risks of
gap-jumping if the compiler isn't doing stack probing, so while we
might be able to further improve the layout logic, I think we still
need to impose limits on setuid programs.

-Kees

-- 
Kees Cook
Pixel Security

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-07 21:00 +0200
  Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-08 00:30 +0200
    Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-08 04:50 +0200
  Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Michal Hocko <mhocko@kernel.org> - 2017-07-10 15:20 +0200
    Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-10 17:50 +0200
      Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Michal Hocko <mhocko@kernel.org> - 2017-07-10 18:00 +0200
        Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-10 20:30 +0200
          Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Michal Hocko <mhocko@kernel.org> - 2017-07-10 20:40 +0200
  Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Ben Hutchings <ben@decadent.org.uk> - 2017-07-10 15:50 +0200
    Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 Kees Cook <keescook@chromium.org> - 2017-07-10 17:40 +0200

csiph-web