Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-13 Thread Kees Cook
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?

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-13 Thread Andreas Schwab
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

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-13 Thread Andreas Schwab
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

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-13 Thread Kees Cook
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

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-12 Thread halfdog
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 >>

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-12 Thread Kees Cook
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

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-12 Thread Kees Cook
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

Re: [PATCH] binfmt_script: do not leave interp on stack

2012-10-12 Thread halfdog
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 + *

[PATCH] binfmt_script: do not leave interp on stack

2012-10-11 Thread Kees Cook
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:

[PATCH] binfmt_script: do not leave interp on stack

2012-10-11 Thread Kees Cook
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: