Many of the programs that inject environment variables could rightly
sanitise their data.
It may provide relief for system builders that provide updated busybox but
not updated bash.
Or safety where stupid use of eval is made in scripts, or careless use of
system/popen is made in programs.
To my mind system/popen are the worst culprits as data is rarely shell
quoted.
For running system commands i always recommend using fork/exec not
system/popen but this is harder if a pipeline is to be invoked or
environment variables to be directly used, in such cases I recommend this
type of construction:
("sh", "-c", "cd \"$HOME\" && \"$0\" \"$@\" ", script, user, key)
any meta characters in script, user, key will not be interpolated by the
shell. The $0 and $@ can of course be broken out to $2 $3 etc.
A wrapper for putenv to ensure that the data is of the intended format
seems a curious solution, it would lead to unexpected code paths where
either putenv fails (which should arguably be dealt with) or the data
placed is unexpectedly wrong when the error should have been dealt with
earlier... and yet it has aspects of graceful degradation which are
important when genuine but unexpected data in the wild is presented.
So the argument to sanitise putenv to me has more weight when considering
general shell injection than this particular bash error.
and yet, I'm not quite convinced yet.
Sam
On 26 Sep 2014 20:53, "Sean Mathews" <mathe...@nutech.com> wrote:
> In regard to CVE-2014-7169 CVE-2014-6271 looking at
> busybox-1.22.1/networking/udhcp/dhcpc.c line 403 fill_envp() it seems as if
> it would be trivial to mess with bootfile and inject a packet that has
> garbage in the bootfile and exploit this vulnerability. Something as
> trivial as removing some characters would likely be sufficient to protect
> from an exploit.
>
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_277
>
> In any case at any point in the code where the outside is allowed to
> inject directly into the shell environment data needs to be sanitized the
> same as one would sanitize a form post on a website application.
>
> here are other files that have the same issue
> networking/httpd.c <- Yep seems easy to exploit.
> networking/ntpd.c <- seems ok but needs more digging. Mostly sanitized by
> numerics.
> networking/tcpudp.c <- potential via dns poisoning injecting an invalid
> hostname containing a payload.
> mailutils/reformime.c <- uses data from mail header and places into env.
>
> I see others but they look less likely.
>
> A wrapper fix for all set/putenv seems reasonable if it can be crafted to
> identify the use of (). I don't see how we can sanitize to a specific
> character set such as 3.278 for all environment vars and not cause problems
> with some use cases. Looking for just () has issues in that other vectors
> may be discovered down the road so maybe pushing this to fixes in bash is
> the best solution.
>
> I would like to see generalized sanitization at every point where
> put/setenv is used to conform at minimum to the expected data that would be
> placed in the environment. Unfortunately for things like httpd.c most
> browsers do not conform to RFC2616 and quote special characters like ( in
> headers. So it would be trivial to inject a forged user agent header with
> the exploit in it.
>
> Does anyone here want to chime in on this issue and potential fixes?
>
>
> Best Regards
> Sean Mathews
> CTO / Director of R&D @ NuTech.com
>
>
>
> _______________________________________________
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
