CVE-2011-2716 udhcpc insufficient checking of DHCP options

Debian Bug report logs - #635548
CVE-2011-2716 udhcpc insufficient checking of DHCP options

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Affected by variant of CVE-2011-0097

Date: Tue, 26 Jul 2011 22:52:00 +0200

Package: udhcpc
Severity: grave
Tags: security

Dear Busybox maintainers,
it was discovered that busybox's udhcpc is also affected by 
https://www.isc.org/software/dhcp/advisories/cve-2011-0997 

This has been assigned CVE-2011-2716.

Cheers,
        Moritz

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #10 received at 635548@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Moritz Muehlenhoff <jmm@debian.org>, 635548@bugs.debian.org

Subject: Re: Bug#635548: Affected by variant of CVE-2011-0097

Date: Wed, 27 Jul 2011 01:39:28 +0400

27.07.2011 00:52, Moritz Muehlenhoff wrote:
> Package: udhcpc
> Severity: grave
> Tags: security
> 
> Dear Busybox maintainers,
> it was discovered that busybox's udhcpc is also affected by 
> https://www.isc.org/software/dhcp/advisories/cve-2011-0997 

Interesting.

How about checking various IP addresses for 127.0.0.0/8 range?
I mean, a rogue DHCP server may assign some 127.1.2.3/24
address to the client, and try to bypass some "non-localhost"
restrictions on it.  Should we try to detect and filter these
too?

And what if we're a (small) LAN connected to an ISP which uses
DHCP, and assigns an address from our own LAN to their end?

Shouldn't this all be filtered/checked in the script that gets
called by the server?  But wait, there are many unsuspecting
scripts out there already... :(

I'll take a look what can be done with this.

Thanks!

/mjt

Message #23 received at 635548@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Nico Golde <nico@ngolde.de>

Cc: 635548@bugs.debian.org

Subject: Re: CVE-2011-2716

Date: Wed, 05 Oct 2011 22:44:50 +0400

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 <nico@ngolde.de> [2011-10-05 11:21]:
>> * Michael Tokarev <mjt@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

Message #28 received at 635548@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 635548@bugs.debian.org

Subject: Re: CVE-2011-2716

Date: Wed, 5 Oct 2011 21:31:15 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Michael Tokarev <mjt@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 <nico@ngolde.de> [2011-10-05 11:21]:
> >> * Michael Tokarev <mjt@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 - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #33 received at 635548@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: 635548@bugs.debian.org

Cc: "Nico Golde" <nico@ngolde.de>

Subject: Re: CVE-2011-2716

Date: Sun, 3 Jun 2012 11:43:33 +0200

Hi all,

Reading the bug about CVE-2011-2716, I think the only question left is this:

> > 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.

Does this still need to be fixed? If it is fixed then I think we can
consider this issue done.


Cheers,
Thijs

Message #38 received at 635548@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Thijs Kinkhorst <thijs@debian.org>, 635548@bugs.debian.org

Cc: Nico Golde <nico@ngolde.de>

Subject: Re: Bug#635548: CVE-2011-2716

Date: Sun, 03 Jun 2012 14:29:21 +0400

On 03.06.2012 13:43, Thijs Kinkhorst wrote:
> Hi all,
> 
> Reading the bug about CVE-2011-2716, I think the only question left is this:
> 
>>> 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.
> 
> Does this still need to be fixed? If it is fixed then I think we can
> consider this issue done.

The version of busybox currently in experimental verifies
all the strings returned by dhcpd and if any bad char is
found, it replaces the whole thing with literal string
"bad" when exporting the variable to the script.  So
there should be no need to quote anything anymore.

I haven't closed this bug becaue I merely forgot about it,
and because I also wanted to recheck all open bugs when
finally uploading busybox 1.20 to unstable.  My current
changelog contains mentions of closing of this bug, too.

Thank you for the reminder, this means these serious issues
weren't forgotten!  And indeed they weren't!.. :)

/mjt

Message #43 received at 635548@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: 635548@bugs.debian.org

Subject: Re: Bug#635548: CVE-2011-2716

Date: Sun, 3 Jun 2012 13:29:49 +0200

On Sun, June 3, 2012 12:29, Michael Tokarev wrote:
> The version of busybox currently in experimental verifies
> all the strings returned by dhcpd and if any bad char is
> found, it replaces the whole thing with literal string
> "bad" when exporting the variable to the script.  So
> there should be no need to quote anything anymore.
>
> I haven't closed this bug becaue I merely forgot about it,
> and because I also wanted to recheck all open bugs when
> finally uploading busybox 1.20 to unstable.  My current
> changelog contains mentions of closing of this bug, too.
>
> Thank you for the reminder, this means these serious issues
> weren't forgotten!  And indeed they weren't!.. :)

Good! Will you ensure that 1.20 ends up in wheezy?
There's not much time I guess, because the wheezy freeze is scheduled for
this month.


Cheers,
Thijs

Message #48 received at 635548@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Thijs Kinkhorst <thijs@debian.org>, 635548@bugs.debian.org

Subject: Re: Bug#635548: CVE-2011-2716

Date: Sun, 03 Jun 2012 17:55:42 +0400

On 03.06.2012 15:29, Thijs Kinkhorst wrote:
[]
> Good! Will you ensure that 1.20 ends up in wheezy?

Yes I very much like to have at least this version
in wheezy.

Thanks,

/mjt

Message #53 received at 635548-close@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 635548-close@bugs.debian.org

Subject: Bug#635548: fixed in busybox 1:1.20.0-3

Date: Tue, 12 Jun 2012 11:02:26 +0000

Source: busybox
Source-Version: 1:1.20.0-3

We believe that the bug you reported is fixed in the latest version of
busybox, which is due to be installed in the Debian FTP archive:

busybox-static_1.20.0-3_i386.deb
  to main/b/busybox/busybox-static_1.20.0-3_i386.deb
busybox-syslogd_1.20.0-3_all.deb
  to main/b/busybox/busybox-syslogd_1.20.0-3_all.deb
busybox-udeb_1.20.0-3_i386.udeb
  to main/b/busybox/busybox-udeb_1.20.0-3_i386.udeb
busybox_1.20.0-3.debian.tar.gz
  to main/b/busybox/busybox_1.20.0-3.debian.tar.gz
busybox_1.20.0-3.dsc
  to main/b/busybox/busybox_1.20.0-3.dsc
busybox_1.20.0-3_i386.deb
  to main/b/busybox/busybox_1.20.0-3_i386.deb
udhcpc_1.20.0-3_i386.deb
  to main/b/busybox/udhcpc_1.20.0-3_i386.deb
udhcpd_1.20.0-3_i386.deb
  to main/b/busybox/udhcpd_1.20.0-3_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 635548@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated busybox package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 02 Jun 2012 14:54:04 +0400
Source: busybox
Binary: busybox busybox-static busybox-udeb busybox-syslogd udhcpc udhcpd
Architecture: source all i386
Version: 1:1.20.0-3
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Description: 
 busybox    - Tiny utilities for small and embedded systems
 busybox-static - Standalone rescue shell with tons of builtin utilities
 busybox-syslogd - Provides syslogd and klogd using busybox
 busybox-udeb - Tiny utilities for the debian-installer (udeb)
 udhcpc     - Provides the busybox DHCP client implementation
 udhcpd     - Provides the busybox DHCP server implementation
Closes: 635370 635548
Changes: 
 busybox (1:1.20.0-3) unstable; urgency=low
 .
   * 1.20 had a few fixes which I forgot to mention:
     - integer overflow in expression on big endian (Closes: #635370)
       (I dislike the fix since it makes use of 64bit integers
       instead of using unsigned 32bit, but this is how upstream
       fixed it)
     - CVE-2011-2716 udhcpc insufficient checking of DHCP options (Closes: #635548)
       busybox dhcpd now replaces values of HOST_NAME, DOMAIN_NAME,
       NIS_DOMAIN, TFTP_SERVER_NAME with the literal string "bad"
       if these contains any bad characters.
   * applied stable patches from upstream (ash, man, ifupdown, tar)
Checksums-Sha1: 
 60eeeebaa9063717370174713a4409fdf4990933 1610 busybox_1.20.0-3.dsc
 20bd5adcbfb32bac41a7eb963cba80b1fcad3ae1 51184 busybox_1.20.0-3.debian.tar.gz
 31eb0e1882901dad5b50e6ad218c28aebfc93bda 19356 busybox-syslogd_1.20.0-3_all.deb
 488f5a0b1d0637eb6abfbc34de7a84bd6e0cefec 876936 busybox-static_1.20.0-3_i386.deb
 d06d577af0abc7c8bfbd01fd1c413c3fb45857da 439684 busybox_1.20.0-3_i386.deb
 81829b2a3d7e6fb47d46e5db9d06fd6feef2708e 17018 udhcpc_1.20.0-3_i386.deb
 10569b7d28e824c66d96a874a24e31198addda69 20324 udhcpd_1.20.0-3_i386.deb
 7a8555d042c945faa7e193e185f23932eaabf1fe 202436 busybox-udeb_1.20.0-3_i386.udeb
Checksums-Sha256: 
 fd70216c557d46c231d9d93c0dcb80d7ccf3275867031386a38d5298327101ee 1610 busybox_1.20.0-3.dsc
 435bb91ded64e074970496ba1da6cbe1bbaf7708780adbc43bcf378d31c5e843 51184 busybox_1.20.0-3.debian.tar.gz
 a2ad958a1fa02e8440a26319c06952ea3c08928a6f4e16174ef21c01dc1c2b04 19356 busybox-syslogd_1.20.0-3_all.deb
 e1cab2095e871c921c0d312985c280edb4b51b4a5f0b06a384f39d98434d223c 876936 busybox-static_1.20.0-3_i386.deb
 dfe0701e61071ee42a77f4683bfa13f8c04f2485198ec8ccadc4a01997e49c07 439684 busybox_1.20.0-3_i386.deb
 902815928b6158766d304673389003ef444c702cae4b1b73a101b1e6d5c05ae4 17018 udhcpc_1.20.0-3_i386.deb
 5407d304ab7d0605aa7390d72b9d77bf56e7b76c7a24b8786e70c917ba8a3fb9 20324 udhcpd_1.20.0-3_i386.deb
 d04c402a94477bd4d891c7ad28bf7f3ff303cc0770a0c93ba317f98e8f1dbc71 202436 busybox-udeb_1.20.0-3_i386.udeb
Files: 
 9512e17e0b1105f7a8c14a21ed30b1d6 1610 utils optional busybox_1.20.0-3.dsc
 e9640d24fc54a4bc8909bd6c228f3e6c 51184 utils optional busybox_1.20.0-3.debian.tar.gz
 300214c269a3dedc63e2d790b8a3ad9c 19356 utils optional busybox-syslogd_1.20.0-3_all.deb
 62dca991bfbf4b4a10e4b7bd19834684 876936 shells extra busybox-static_1.20.0-3_i386.deb
 7aaa4659813e6cde9123ed8d51981dc8 439684 utils optional busybox_1.20.0-3_i386.deb
 3fdec9a078bee1da61ac28ae6d543ece 17018 net optional udhcpc_1.20.0-3_i386.deb
 104d66badb26a1ecfd8b6f7614a1441a 20324 net optional udhcpd_1.20.0-3_i386.deb
 49722875a87faf8577c8bec8ea0a59e0 202436 debian-installer extra busybox-udeb_1.20.0-3_i386.udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iJwEAQECAAYFAk/XHqgACgkQUlPFrXTwyDhIdQP7BQLVktj88/Znt/8/Dm7Ab26l
Tg1WUM7BS8VpzpJTSL59xt5XWINdz9J/ubCLmULO+FEUpur4H4EwvONq+J6M4iLr
7XAhY4707rQuxvq+hn5m6qW+OvKqREVx+ThQG3mzZUC1Fl7ESuM3MOL3mr1H7aWG
xt6jbdKGCvIH7MXLV7g=
=e637
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.