[PATCH 2/2] ash: use alloca to get rid of setjmp

Rich Felker dalias at libc.org
Thu Jul 16 00:09:21 UTC 2015


On Mon, Jul 13, 2015 at 04:25:02AM +0200, Denys Vlasenko wrote:
> On Thu, Jul 2, 2015 at 10:01 AM, Ron Yorston <rmy at frippery.org> wrote:
> > Rich Felker wrote:
> >>In general alloca is unsafe. It's not obvious to me what the code here
> >>is doing, so I can't tell for sure if it's safe or not, but I think
> >>this needs a strong justification of safety before being acceptable.
> >
> > It's a parser for a POSIXy shell, I doubt that the code is obvious to
> > anyone.
> >
> > My understanding is that it's reading a token and has got to the point
> > where a command substitution has been detected.  It wants to save the
> > bit of the token it's already processed.  So if we have
> >
> >    echo "very long string"`date`
> >
> > the code would allocate space for the very long string.
> 
> In practice, it would be a problem if "very long string"
> is some hundreds of kbytes, even a few mbytes long.
> 
> > Is this safe?  In most cases it probably is, but not if the script is
> > malicious.  If the very long string is too big for your stack you get a
> > seg fault or worse.  With a suitably long string and small stack I can
> > reliably crash dash.
> 
> With a sufficiently small memory limits you can crash any shell.
> 
> Let's go with this change, unless someone sees a way to not just
> crash, but do something worse.

I suspect it can easily be made to do arbitrary code execution when
otherwise-safe (e.g. checked against whitelist for special chars)
strings from untrusted input are expanded inside eval commands.

Any new use of VLA/alloca should be completely banned. It's basically
always an exploitable bug.

Rich


More information about the busybox mailing list