Re: posix_spawnp stack overflow/corruption by child when PATH is large?

[Will Dietz <w@wdtz.org>]

(soft ping)

~Will

On Mon, Sep 18, 2017 at 2:31 PM, Will Dietz <w@wdtz.org> wrote:
> Thanks for taking a look and for the confirmation!
>
> I agree that 1024+PATH_MAX would be a reasonable value here, good call.
>
> I had similar thought about making the extra stack usage conditional,
> but would rather keep it simple and clear-- as weighed against my possibly
> wrong "expectation" that the difference won't be significant for folks.
> I don't feel strongly about it and of course defer to your judgement :).
>
> Patch making the discussed change is attached.
>
> ~Will
>
>
> On Fri, Sep 15, 2017 at 9:17 AM, Rich Felker <dalias@libc.org> wrote:
>> On Thu, Sep 14, 2017 at 03:39:35PM -0500, Will Dietz wrote:
>>> Hi,
>>>
>>> I believe there is a bug in posix_spawn/execvpe, please take a look and confirm
>>> or kindly let me know if I'm mistaken and accept my apologies :).
>>>
>>> It looks like __posix_spawnx calls clone() with a 1024-byte stack buffer
>>> (allocated from its own stack), which is insufficient to handle stack
>>> allocations performed
>>> in execvpe which are something around a few bytes more than NAME_MAX+PATH_MAX.
>>>
>>> This path is taken when using posix_spawnp, and the problem exists on
>>> 1.1.16 and latest git.
>>>
>>> For what it's worth I tracked this down from a crash in 'bison' when
>>> invoking m4,
>>> but I've had success reproducing it with the following demo program
>>> and driver script:
>>>
>>> -------------------------------------------
>>> #include <spawn.h>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <sys/types.h>
>>> #include <sys/wait.h>
>>>
>>> extern char **environ;
>>>
>>> int main() {
>>>
>>>   pid_t p;
>>>   char *argv[] = {"sh", "-c", "echo Hello", NULL};
>>>   int s, status;
>>>   s = posix_spawnp(&p, "sh", NULL, NULL, argv, environ);
>>>   if (s) {
>>>     perror("posix_spawn");
>>>     exit(1);
>>>   }
>>>
>>>   s = waitpid(p, &status, 0);
>>>
>>>   printf("pid: %d, s: %d, status: %d\n", p, s, status);
>>>
>>>   return 0;
>>> }
>>> --------------
>>>
>>> And little shell script to create a suitably large PATH (mostly to
>>> demonstrate what I mean, not for unmodified use):
>>> ---------------
>>> #!/bin/sh
>>>
>>> SLASH_100_As="/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
>>> SUFFIX="/123456789012345678901234567" #1234567890" #1234567890"
>>>
>>> VAR="/bin:$SUFFIX"
>>> for x in `seq 10`; do
>>>   VAR="${SLASH_100_As}:$VAR"
>>> done
>>>
>>> echo $VAR
>>> echo $VAR|wc -c
>>>
>>> # Works fine with normal PATH
>>> ~/cur/musl-spawn/test
>>> ~/cur/musl-spawn/test
>>>
>>> # Crashes when PATH is ~1050 characters
>>> PATH=$VAR \
>>> ~/cur/musl-spawn/test
>>> --------------
>>>
>>> Where "~/cur/musl-spawn/test" is the test program compiled against musl.
>>>
>>> I cannot speak regarding any security implications, but since this may
>>> grant some measure of stack-scribbling-powers it seems to warrant
>>> being given brief attention in this context.
>>>
>>> An easy fix is to bump the size of the 'char stack[1024]' in
>>> src/process/posix_spawn.c to a suitable value-- 8096 is overkill but
>>> does the trick, for example.
>>>
>>> Please let me know if I'm missing something or if details are not clear.
>>
>> It's very clear, and this seems pretty serious. 1024+PATH_MAX would
>> probably be a safe limit. If we care about minimal stack usage when
>> plain posix_spawn (not spawnp) is called, it could be something like
>> "exec==execve ? 1024 : 1024+PATH_MAX", perhaps.
>>
>> Rich