lkml.org 
[lkml]   [2012]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] exec: do not leave bprm->interp on stack
    From
    On Sun, Nov 18, 2012 at 11:04 AM, P J P <ppandit@redhat.com> wrote:
    > +-- On Fri, 16 Nov 2012, Kees Cook wrote --+
    > | Hrm? It should be showing only the live heap-allocated interp -- are
    > | you seeing uninitialized contents?
    >
    > I don't see uninitialised content; I see interpreter names from previous
    > iterations. Which was the case earlier as well. The - interp - array is
    > initialised with the interpreter name, before being assigned to bprm->interp.
    >
    > These - interp - bytes are *leaked* because after 4 recursions, when
    > load_script returns -ENOEXEC, - bprm->interp - becomes invalid for it starts
    > pointing to an invalid stack memory location.
    >
    > Crux of the problem is in the fact that the recursion limit -
    > BINPRM_MAX_RECURSION(4) - exceeds after ones been rightly adhered to.
    >
    > (bprm->recursion_depth > BINPRM_MAX_RECURSION))
    > return -ENOEXEC;
    >
    > This check fails due to specific condition, which still exists.
    >
    > Dynamically allocating memory fixes the leak by making the memory area live
    > and valid.

    Right. There are two problems. This fixes the first, which is the
    memory content leak.

    > It does not fix the problem which caused the leak in the first place by
    > exceeding the BINPRM_MAX_RECURSION, not by 1 or 2 but possible 2^6
    > recursions. Isn't that performance hit?

    This is the second problem. I view this as less critical because it's
    only 64 instead of 4, but it certainly should be solved as well.

    -Kees

    --
    Kees Cook
    Chrome OS Security


    \
     
     \ /
      Last update: 2012-11-18 21:01    [W:4.018 / U:1.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site