mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Will Dietz <w@wdtz.org>
To: musl@lists.openwall.com
Subject: Re: posix_spawnp stack overflow/corruption by child when PATH is large?
Date: Mon, 18 Sep 2017 14:31:25 -0500	[thread overview]
Message-ID: <CAKGWAO8PeOW1vpOFzQ5sE1ybXwWuBcieU_on3SD7rRPaHYqO6g@mail.gmail.com> (raw)
In-Reply-To: <20170915141742.GW1627@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]

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

[-- Attachment #2: 0001-posix_spawn-use-larger-stack-to-cover-worst-case-in-.patch --]
[-- Type: text/x-patch, Size: 1058 bytes --]

From 9b5ca541b2c97850b00a051ad21efc46792b91b2 Mon Sep 17 00:00:00 2001
From: Will Dietz <w@wdtz.org>
Date: Thu, 14 Sep 2017 16:32:59 -0500
Subject: [PATCH] posix_spawn: use larger stack to cover worst-case in execvpe

execvpe stack-allocates a buffer used to hold the full path
(combination of a PATH entry and the program name)
while searching through $PATH, so at least
NAME_MAX+PATH_MAX is needed.

The stack size can be made conditionally smaller
(the current 1024 appears appropriate)
should this larger size be burdensome in those situations.
---
 src/process/posix_spawn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/process/posix_spawn.c b/src/process/posix_spawn.c
index ea5d2998..0849c71f 100644
--- a/src/process/posix_spawn.c
+++ b/src/process/posix_spawn.c
@@ -152,7 +152,7 @@ int __posix_spawnx(pid_t *restrict res, const char *restrict path,
 	char *const argv[restrict], char *const envp[restrict])
 {
 	pid_t pid;
-	char stack[1024];
+	char stack[1024+PATH_MAX];
 	int ec=0, cs;
 	struct args args;
 
-- 
2.14.1


  reply	other threads:[~2017-09-18 19:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 20:39 Will Dietz
2017-09-15 14:17 ` Rich Felker
2017-09-18 19:31   ` Will Dietz [this message]
2017-10-19 21:05     ` Will Dietz
2017-10-19 21:10       ` Rich Felker
2017-10-21 15:54         ` Will Dietz

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=CAKGWAO8PeOW1vpOFzQ5sE1ybXwWuBcieU_on3SD7rRPaHYqO6g@mail.gmail.com \
    --to=w@wdtz.org \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).