On Fri, Oct 12, 2012 at 10:50 PM, halfdog wrote:
> Kees Cook wrote:
>> More importantly, I also wonder if interp handling to just be
>> changed to be an allocation that needs to be cleaned up, as done with
>> argv?
>
> You mean like an allocation on the stack of the new process' growing
> stack? T
Kees Cook writes:
> + /*
> + * Since bprm is already modified, we cannot continue if the the
s/the the/the/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To u
Kees Cook wrote:
> On Thu, Oct 11, 2012 at 07:32:40PM -0700, Kees Cook wrote:
>> +/*
>> + * Since bprm is already modified, we cannot continue if the the
>> + * handlers for starting the new interpreter have failed.
>> + * Make sure that we do not return -ENOEXEC, as that would
>> +
On Thu, Oct 11, 2012 at 07:32:40PM -0700, Kees Cook wrote:
> + /*
> + * Since bprm is already modified, we cannot continue if the the
> + * handlers for starting the new interpreter have failed.
> + * Make sure that we do not return -ENOEXEC, as that would
> + * allow search
When binfmt_script's load_script ran, it would manipulate bprm->buf and
leave bprm->interp pointing to the local stack. If a series of scripts
are executed, the final one will have leaked kernel stack contents into
the cmdline. For a proof of concept, see DoTest.sh from:
http://www.halfdog.net/Secu
5 matches
Mail list logo
