On Mon, Jul 13, 2015 at 04:25:02AM +0200, Denys Vlasenko wrote: > On Thu, Jul 2, 2015 at 10:01 AM, Ron Yorston <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
