From: Al Viro <viro@ZenIV.linux.org.uk>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Josh Triplett <josh@joshtriplett.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
linux-fsdevel@vger.kernel.org, halfdog <me@halfdog.net>
Subject: Re: [PATCH] exec: do not leave bprm->interp on stack
Date: Thu, 25 Oct 2012 05:16:21 +0100 [thread overview]
Message-ID: <20121025041620.GH2616@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20121024232032.GA31129@www.outflux.net>
On Wed, Oct 24, 2012 at 04:20:32PM -0700, Kees Cook wrote:
> If a series of scripts are executed, each triggering module loading via
> unprintable bytes in the script header, kernel stack contents can leak
> into the command line.
>
> Normally execution of binfmt_script and binfmt_misc happens
> recursively. However, when modules are enabled, and unprintable bytes
> exist in the bprm->buf, execution will restart after attempting to load
> matching binfmt modules. Unfortunately, the logic in binfmt_script and
> binfmt_misc does not expect to get restarted. They leave bprm->interp
> pointing to their local stack. This means on restart bprm->interp is
> left pointing into unused stack memory which can then be copied into
> the userspace argv areas.
>
> This changes the logic to require allocation for any changes to the
> bprm->interp. To avoid adding a new kmalloc to every exec, the default
> value is left as-is. Only when passing through binfmt_script or
> binfmt_misc does an allocation take place.
I really don't like that. It papers over the problem, but doesn't really
solve the underlying stupidity. We have no good reason to retry a binfmt
we'd already attempted on this level of recursion. And your patch doesn't
deal with that at all.
next prev parent reply other threads:[~2012-10-25 4:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 23:20 [PATCH] exec: do not leave bprm->interp on stack Kees Cook
2012-10-25 4:16 ` Al Viro [this message]
2012-10-25 6:21 ` Kees Cook
2012-10-25 11:46 ` P J P
2012-10-25 12:03 ` Tetsuo Handa
2012-10-25 12:57 ` P J P
2012-10-25 12:09 ` Al Viro
2012-10-25 12:38 ` Al Viro
2012-10-26 17:38 ` P J P
2012-10-26 18:36 ` Al Viro
2012-10-27 10:47 ` P J P
2012-10-27 17:05 ` Kees Cook
2012-10-27 20:16 ` P J P
2012-10-28 3:32 ` Kees Cook
2012-11-06 8:10 ` P J P
2012-11-12 22:10 ` Kees Cook
2012-11-13 6:50 ` halfdog
2012-11-13 6:50 ` halfdog
2012-11-16 12:50 ` P J P
2012-11-16 18:00 ` Kees Cook
2012-11-18 19:04 ` P J P
2012-11-18 19:34 ` Kees Cook
2012-11-19 6:57 ` P J P
2012-11-19 20:41 ` Kees Cook
2012-11-20 7:04 ` P J P
2012-11-22 14:17 ` P J P
2012-11-25 1:30 ` Kees Cook
2012-11-26 6:23 ` P J P
2012-11-26 7:09 ` P J P
2012-11-22 20:06 ` P J P
2012-11-23 18:43 ` P J P
2012-11-23 23:12 ` Tetsuo Handa
[not found] ` <CA+55aFx3LFH5Xj1OkNoy7vN5w8y5tH39MUDujKqF3BdnmYibLQ@mail.gmail.com>
2012-11-20 7:08 ` P J P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121025041620.GH2616@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@halfdog.net \
--cc=serge.hallyn@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.