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?
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
Kees Cook keesc...@chromium.org 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
On Fri, Oct 12, 2012 at 10:50 PM, halfdog m...@halfdog.net 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
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
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 searching
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
+ *
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:
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:
10 matches
Mail list logo