I'm Cc'ing the relevant bug# so others may see this information.
Hopefully you wont object -- the bug is public for a long time.
On 05.10.2011 16:04, Nico Golde wrote:
> Hi,
> * Nico Golde <n...@ngolde.de> [2011-10-05 11:21]:
>> * Michael Tokarev <m...@tls.msk.ru> [2011-10-05 10:34]:
>>> On 05.10.2011 02:42, Nico Golde wrote:
>>>> Hi,
>>>> can you tell me if CVE-2011-2716 is a problem with a default
>>>> busybox or only in case there are additional shell scripts
>>>> that make use of the untrusted host name?
>>>
>>> Busybox itself does not really work in this case: an additional
>>> shell script is _required_ for DHCP functionality, since busybox
>>> executes a shell script to do the real work, and, in particular,
>>> to set up host name etc. The default script supplied with the
>>> package is not affected.
>
> (/debian/tree/busybox-udeb/usr/share/udhcpc/default.script) and was wondering
> if the domain name is safe to use. I see it is the only unquoted variable in
> this script. Can you comment on this? I have to admit that I don't know the
Actually it was me who looked into the wrong script - I looked into the
version installed on my system, which is modified by me long ago. That
version does not use any of the "bad" variables at all.
You're right, the actual script in the dhcpc package refers to $domain
variable - the only variable referenced in this script which may be
insecure.
But you're not correct that the variable is used unquoted. Here's the
actual code:
# Update resolver configuration file
R=""
[ -n "$domain" ] && R="domain $domain
"
for i in $dns; do
echo "$0: Adding DNS $i"
R="${R}nameserver $i
"
done
if [ -x /sbin/resolvconf ]; then
echo -n "$R" | resolvconf -a "${interface}.udhcpc"
else
echo -n "$R" > "$RESOLV_CONF"
fi
;;
So, in all cases the variable is enclosed in double quotes.
There's just one possible problem with this: it is possible to
inject bad - eg, syntactically incorrect - content into /etc/resolv.conf.
I'm not really sure if glibc's resolver will cope with any and all
garbage found in /etc/resolv.conf, but its parser is very simple and
just ignores everything that it does not understand.
It is definitely not possible to execute (shell) code "embedded" in
${domain} variable - at least not from the udhcpc script quoted above.
Also, the only place where content of a single "insecure" variable is
used is /etc/resolv.conf (which is already controlled by an rogue dhcp
server anyway, to a large extent) - eg, the default script does not set
system hostname to the string supplied by dhcp server.
> inner workings of the dhcpc in combination with the surrounded scripts very
> well so please bear with me :)
There's nothing to know about really: dhcpcd converts every known option
found in dhcp reply packet into an environment variable, without any
content checking/filtering whatsoever. There are 2 most common types
of options: it is either a (list of) IP address(es), which are passed as
4-byte binaries and hence cannot contain bad strings at all (they're
converted into 1.2.3.4 - octet - form by udhcpc) - these are $broadcast,
$subnet, $router, $dns. And the other common type is string - a sequence
of any characters. One of these is $domain, there are others like
$hostname.
And all this stuff gets passed to the script, which may deal with them
in any way.
Note that in theory it is possible to have some other script - e.g. a
script executed by resolvconf from /etc/resolv.d/* directories - which
uses the same variables without clearing their contents. But this is
a different story, and that'd be a definitive bug in these scripts,
with or without a rogue dhcp server.
So, the only problem is when the default script is replaced/modified
locally and in insecure way.
Note that current udhcpc script is in /usr/share, so it is not possible
to replace it locally in debian (well, without diverting it) - it's a
bug in dhcpcd, a file intended to be modified should be a conffile and
placed into /etc. But this is, again, a different story ;)
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
