Messages in this thread | | | From | Kees Cook <> | Date | Mon, 10 Jul 2017 08:39:43 -0700 | Subject | Re: [PATCH] exec: Limit arg stack to at most _STK_LIM / 4 * 3 |
| |
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
| |