Sean Mathews 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.
We should keep in mind that this is a vulnerability in bash, not in
busybox. It is unlikely that a system with busybox uses bash as the
default shell, and it is unlikely that a system would update busybox,
but not bash, so it wouldn't make much sense to add bash protection to
busybox. I also assume that busybox bash compatibility doesn't extend to
importing shell functions.
In general, I wonder why someone would think importing shell functions
is a good idea, and if there is anyone who relies on this feature. I
looked at the bash man page, and only found this:
> INVOCATION
> ...
> If the shell is started with the effective user (group) id not
equal to the real user (group) id, ..., shell functions are not
inherited from the environment.
This would imply that they are imported otherwise, but it is likely that
people would read the start of the sentence and skip the rest because
the don't use setuid/setgid.
In http://seclists.org/oss-sec/2014/q3/771 (bug-bash-gnu) it has been
argued that importing shell functions is a feature that almost nobody
uses and that should be off by default. I agree with this.
Why should a non-interactiv shell import shell functions from the
environment? When the shell executes a script, that script can define
all the shell functions it needs.
Any why would an interactive shell import shell functions? The
interactive shell already reads several startup files, these files can
be used to define all the desired shell functions.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
