Hi, * Michael Tokarev <m...@tls.msk.ru> [2011-10-05 20:44]: > 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.
No, not at all.
> On 05.10.2011 16:04, Nico Golde wrote:
> > * 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.
Partly the same here, I also looked into the wrong one.
I looked into the one of the udeb.
> 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.
Yes this look secure. What about the udeb script?
/debian/tree/busybox-udeb/usr/share/udhcpc/default.script:
do_resolv_conf() {
local cfg=/etc/resolv.conf
if [ -n "$domain" ] || [ -n "$dns" ]; then
echo -n > $cfg
if [ -n "$domain" ]; then
echo search $domain >> $cfg
fi
for i in $dns ; do
echo nameserver $i >> $cfg
done
fi
}
Not quoted in thsi case.
> 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.
I think it's no big problem. Even if this could be a DoS scenario it would be a
rather obscure one.
> 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.
Ok makes sense, thanks for the explanation.
> > 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.
In this case even an unquoted $domain is probably no problem.
E.g.:
$ domain='`id`'
$ echo $domain
`id`
> 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.
I totally agree on this.
Thanks again for the update!
Cheers
Nico
--
Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.
pgpoY0NN0WOT2.pgp
Description: PGP signature
