From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12026 Path: news.gmane.org!.POSTED!not-for-mail From: Will Dietz Newsgroups: gmane.linux.lib.musl.general Subject: Re: posix_spawnp stack overflow/corruption by child when PATH is large? Date: Sat, 21 Oct 2017 10:54:52 -0500 Message-ID: References: <20170915141742.GW1627@brightrain.aerifal.cx> <20171019211013.GR1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1508601319 3947 195.159.176.226 (21 Oct 2017 15:55:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 21 Oct 2017 15:55:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12039-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 21 17:55:13 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1e5w75-0007b8-GH for gllmg-musl@m.gmane.org; Sat, 21 Oct 2017 17:55:03 +0200 Original-Received: (qmail 9410 invoked by uid 550); 21 Oct 2017 15:55:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9380 invoked from network); 21 Oct 2017 15:55:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wdtz.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=SvLTC5uyzZGwkP3dT9KSyPgy+eAHkpkbWzicLkAok4M=; b=MlpjrSKr/mTAO2tuq6MKTq4w1ekQ/q5P94PHWKib3WBBwCkQlom5h/CTSLd/znslLf blVNeXYSeVuWYRnalAcXDe1StCgCtlYNdxvzvPrq8W4sPp/jcMxHxj8OKBrCucxJDrkj 7SdYSAneIz/uF0JmjqN6I6nqsTuFwDcWUnoZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=SvLTC5uyzZGwkP3dT9KSyPgy+eAHkpkbWzicLkAok4M=; b=N8J1qeFQSanK1yhaiiFVdwbhmElb1dreeT7nL6HTOCNJthclKxRF2hHQtgqK9BY5D0 7GYOws5PM5Xw+4xkPGHekxGmljylTEltNNbKn/c6ExXKCjY0xNlC+PS4UWZRcZj6iEun ZV31XDDf9+BEeWUP7iHKHlBUAYwx23rCp8DScbvpb+GkRjRPPz7I98qRmz3mRcmAJsuD L1xuLzJs2kNrks3MKQu26whoj4BMromGjw4R3cWRvPb02Yrww9zEdpShrrd4gB/nXQpA JxjNtlhKg+N2sc7W5sFY5qv8DomvutliYCW+SaxScakaTYzMgHBbCL2X5KaaDOdR9wsx ZKag== X-Gm-Message-State: AMCzsaX1MohnhSEpyO7pwcqbCV1CNpoGbxH6NrTGptUU3WujAtoR1H5I lpB4eCalz3eI+OyhFunyEp2KzKfeUN+VrrRRu0ovLKA= X-Google-Smtp-Source: ABhQp+SOTWBVHD4Ym7ssgxHUA4f1lu5Hhg2Q+jJqmfGRPKgQ8JJIsmf0harsmDLFn0bL58ZFsU2mT1nZOumzIegMa+Y= X-Received: by 10.202.83.8 with SMTP id h8mr4135009oib.91.1508601293351; Sat, 21 Oct 2017 08:54:53 -0700 (PDT) X-Originating-IP: [2602:306:304a:61cd::d68] In-Reply-To: <20171019211013.GR1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12026 Archived-At: 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 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 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 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 >> >>> #include >> >>> #include >> >>> #include >> >>> #include >> >>> >> >>> 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