From: Will Dietz <w@wdtz.org>
To: musl@lists.openwall.com
Subject: posix_spawnp stack overflow/corruption by child when PATH is large?
Date: Thu, 14 Sep 2017 15:39:35 -0500 [thread overview]
Message-ID: <CAKGWAO_8tuo52gy3CwH3VGE764RzjGOhObi=fsS84Y0nSqkfDQ@mail.gmail.com> (raw)
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.
Thanks!
~Will
next reply other threads:[~2017-09-14 20:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 20:39 Will Dietz [this message]
2017-09-15 14:17 ` Rich Felker
2017-09-18 19:31 ` Will Dietz
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='CAKGWAO_8tuo52gy3CwH3VGE764RzjGOhObi=fsS84Y0nSqkfDQ@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).