* posix_spawnp stack overflow/corruption by child when PATH is large?
@ 2017-09-14 20:39 Will Dietz
2017-09-15 14:17 ` Rich Felker
0 siblings, 1 reply; 6+ messages in thread
From: Will Dietz @ 2017-09-14 20:39 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large?
2017-09-14 20:39 posix_spawnp stack overflow/corruption by child when PATH is large? Will Dietz
@ 2017-09-15 14:17 ` Rich Felker
2017-09-18 19:31 ` Will Dietz
0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2017-09-15 14:17 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large?
2017-09-15 14:17 ` Rich Felker
@ 2017-09-18 19:31 ` Will Dietz
2017-10-19 21:05 ` Will Dietz
0 siblings, 1 reply; 6+ messages in thread
From: Will Dietz @ 2017-09-18 19:31 UTC (permalink / raw)
To: musl
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large?
2017-09-18 19:31 ` Will Dietz
@ 2017-10-19 21:05 ` Will Dietz
2017-10-19 21:10 ` Rich Felker
0 siblings, 1 reply; 6+ messages in thread
From: Will Dietz @ 2017-10-19 21:05 UTC (permalink / raw)
To: musl
(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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large?
2017-10-19 21:05 ` Will Dietz
@ 2017-10-19 21:10 ` Rich Felker
2017-10-21 15:54 ` Will Dietz
0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2017-10-19 21:10 UTC (permalink / raw)
To: musl
On Thu, Oct 19, 2017 at 04:05:19PM -0500, Will Dietz wrote:
> (soft ping)
Oops, I probably should have gotten this into the release. At least it
makes a good motivation to pick up the release pace and make another
release soon.
Rich
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: posix_spawnp stack overflow/corruption by child when PATH is large?
2017-10-19 21:10 ` Rich Felker
@ 2017-10-21 15:54 ` Will Dietz
0 siblings, 0 replies; 6+ messages in thread
From: Will Dietz @ 2017-10-21 15:54 UTC (permalink / raw)
To: musl
Sounds like a plan! Don't mean to bug, just want to make sure it's not
lost in the bustle of the release :).
~Will
On Thu, Oct 19, 2017 at 4:10 PM, Rich Felker <dalias@libc.org> wrote:
> On Thu, Oct 19, 2017 at 04:05:19PM -0500, Will Dietz wrote:
>> (soft ping)
>
> Oops, I probably should have gotten this into the release. At least it
> makes a good motivation to pick up the release pace and make another
> release soon.
>
> Rich
>
>
>
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-10-21 15:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-14 20:39 posix_spawnp stack overflow/corruption by child when PATH is large? Will Dietz
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
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).