This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 689832 - (CVE-2011-0997) CVE-2011-0997 dhclient: insufficient sanitization of certain DHCP response values
CVE-2011-0997 dhclient: insufficient sanitization of certain DHCP response va...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,source=suse,reported...
: Security
Depends On: 690574 690576 690577 690578 690579 694005 699892 700018
Blocks: 722974
  Show dependency treegraph
 
Reported: 2011-03-22 11:01 EDT by Tomas Hoger
Modified: 2012-07-10 15:16 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-17 11:18:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Proposed patch for ISC dhclient (5.21 KB, patch)
2011-03-22 11:04 EDT, Tomas Hoger
no flags Details | Diff
Proposed patch for dhclientv6 (2.70 KB, patch)
2011-03-22 11:05 EDT, Tomas Hoger
no flags Details | Diff
Proposed patch for dhcpcd (9.73 KB, patch)
2011-03-22 11:06 EDT, Tomas Hoger
no flags Details | Diff
Updated proposed patch for ISC dhclient (5.24 KB, patch)
2011-03-23 06:01 EDT, Tomas Hoger
no flags Details | Diff
Proposed ISC patch (6.83 KB, patch)
2011-03-25 12:09 EDT, Tomas Hoger
no flags Details | Diff
Updated ISC patch from Marius (6.82 KB, patch)
2011-03-25 12:13 EDT, Tomas Hoger
no flags Details | Diff
Patch againt EL6 dhcp (6.46 KB, patch)
2011-04-01 06:42 EDT, Tomas Hoger
no flags Details | Diff
Backport to EL5 dhcp (5.58 KB, patch)
2011-04-01 11:55 EDT, Tomas Hoger
no flags Details | Diff
Marius' patch making domain-name check more lenient (571 bytes, patch)
2011-04-06 11:46 EDT, Tomas Hoger
no flags Details | Diff

  None (edit)
Description Tomas Hoger 2011-03-22 11:01:48 EDT
Sebastian Krahmer of the SUSE security team noticed that DHCP clients fail to sanitize certain values supplied by DHCP servers during the DHCP communication.  The example of such value is hostname configured on the DHCP client.  Various scripts assume hostname is trusted and do not sufficiently escape or quote it.  Malicious DHCP server can use this to execute arbitrary code on the DHCP client by supplying a specially-crafted hostname.

Acknowledgement:

Red Hat would like to thank Sebastian Krahmer of the SuSE Security Team for reporting this issue.
Comment 1 Tomas Hoger 2011-03-22 11:04:41 EDT
Created attachment 486815 [details]
Proposed patch for ISC dhclient

Created by Marius Tomaschewski of SUSE.
Comment 2 Tomas Hoger 2011-03-22 11:05:19 EDT
Created attachment 486816 [details]
Proposed patch for dhclientv6

Created by Marius Tomaschewski of SUSE.
Comment 3 Tomas Hoger 2011-03-22 11:06:06 EDT
Created attachment 486817 [details]
Proposed patch for dhcpcd

Created by Marius Tomaschewski of SUSE.
Comment 4 Tomas Hoger 2011-03-22 11:10:50 EDT
There currently seem to be an ongoing discussion on whether this should be handled in the dhcp clients directly (as proposed by Marius), or rather in dhcp client scripts.
Comment 5 Tomas Hoger 2011-03-23 06:01:37 EDT
Created attachment 486993 [details]
Updated proposed patch for ISC dhclient
Comment 6 Tomas Hoger 2011-03-23 06:54:45 EDT
David, if we patch dhclient / dhcp6c using the proposed patch, will we need to do any more work for libdhcp*client and libdhcp we have in EL5?  Are you familiar with how anaconda uses dhclient?  I presume it's via libdhcp{,*client} on EL5, possibly directly on older and newer.
Comment 7 David Cantrell 2011-03-23 09:55:09 EDT
(In reply to comment #6)
> David, if we patch dhclient / dhcp6c using the proposed patch, will we need to
> do any more work for libdhcp*client and libdhcp we have in EL5?  Are you
> familiar with how anaconda uses dhclient?  I presume it's via libdhcp{,*client}
> on EL5, possibly directly on older and newer.

The only thing we would need to do is probably rebuild libdhcp because there is a static library provided that links with libdhcp4client and libdhcp6client.  libdhcp4client is a patch to the dhcp package that turns dhclient in a library.  libdhcp6client is in the dhcpv6 code that builds dhcp6c as a library.  Both of these are how libdhcp actually gains DHCP functionality, so there's not seperate patching that needs to happen for libdhcp.

We might also want to consider rebuilding anaconda because loader in RHEL-5 is statically linked with libdhcp.  It won't really matter to anyone except people rebuilding installation though.

In anaconda in RHEL-5, we call libdhcp directly for DHCP needs.  libdhcp in turn uses libdhcp4client and libdhcp6client (as described above).  In RHEL-6, libdhcp no longer exists (nor does the dhcpv6 package).  In RHEL-6 anaconda speaks to NetworkManager to handle all networking needs.  NetworkManager runs dhclient directly but provides its own replacement for /sbin/dhclient-script.
Comment 8 Tomas Hoger 2011-03-23 10:49:55 EDT
(In reply to comment #7)
> We might also want to consider rebuilding anaconda because loader in RHEL-5 is
> statically linked with libdhcp.  It won't really matter to anyone except people
> rebuilding installation though.

Statically linked loader is the one that can be found on stage1 images, such as boot.iso?  I see stage2 image does have dynamic libdhcp* libs.  Is the final host name set on the system the one obtained during the stage2?

I also see stage2 provides udhcpc -> busybox symlink.  Based on what you said, anaconda does not use busybox dhcp client.
Comment 9 David Cantrell 2011-03-23 11:59:21 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > We might also want to consider rebuilding anaconda because loader in RHEL-5 is
> > statically linked with libdhcp.  It won't really matter to anyone except people
> > rebuilding installation though.
> 
> Statically linked loader is the one that can be found on stage1 images, such as
> boot.iso?  I see stage2 image does have dynamic libdhcp* libs.  Is the final
> host name set on the system the one obtained during the stage2?

Not necessarily.  If the user is doing a network-based install, then loader from stage1 will set up the network.  If they enable the network in stage2 (e.g., doing a CD or DVD install and adding an additional remote repo during install), then the dynamic libdhcp in stage2 is in charge.

> I also see stage2 provides udhcpc -> busybox symlink.  Based on what you said,
> anaconda does not use busybox dhcp client.

That is correct.  Anaconda does not use the busybox dhcp client.
Comment 10 Tomas Hoger 2011-03-23 12:21:00 EDT
Thank you!

I've noticed that our dhclient-script only tries to set hostname to server provided value if it's unset or set to "localhost" or "localhost.localdomain".  Do you think we can make any assumptions on what the hostname is based on what anaconda does?
Comment 11 Tomas Hoger 2011-03-24 12:05:07 EDT
For DHCP(v4), there mitigations for specially-crafted hostname are:
- dhclient-script only sets server-supplied hostname if there is no hostname
  set already (see comment #10 for details)
- dhclient already escapes certain special characters (e.g. ` and $), which
  blocks the most straight forward attacks, but code execution may still be
  possible in certain less common cases

For DHCPv6, the lack of hostname option seems to reduce the risk significantly.  It may be possible to set DNS domain search list to invalid values.
Comment 14 Tomas Hoger 2011-03-25 12:09:15 EDT
Created attachment 487590 [details]
Proposed ISC patch

Based on previous patches from Marius Tomaschewski.
Comment 15 Tomas Hoger 2011-03-25 12:13:34 EDT
Created attachment 487591 [details]
Updated ISC patch from Marius

Based on patch in comment #14, with few additional changes proposed by Marius.  E.g. avoids logging values with special characters.
Comment 16 Tomas Hoger 2011-04-01 06:42:27 EDT
Created attachment 489356 [details]
Patch againt EL6 dhcp

Patch from comment #14 with the logging fix from the patch in comment #15, re-diffed against 4.1.1-P1 shipped with RHEL-6.

According to ISC, they are not going to take additional changes proposed by Marius now, as they do not want to respin candidate tarballs now and will be reviewing those changes for the next maintenance update.  Their future solution may differ significantly from the current quick fix.

The patch also has check_domain_name*() functions accept argument dots, which is not really used in this fix and the functions are always called with dots == 0.
Comment 18 Tomas Hoger 2011-04-01 11:55:20 EDT
Created attachment 489426 [details]
Backport to EL5 dhcp

Backport of the above patch to dhcp version 3.0.5 as shipped with RHEL-5.

It removes DHCPv6 related code (DHCPv6 not supported there), as well as check_domain_name_list(), which was only called to check domain-search option (DHO_DOMAIN_SEARCH, 119), which is not recognized by 3.0.5 dhclient either and only exported to dhclient as:

  new_unknown_119=4:64:6f:6d:31:...

Escaping list was adjusted to match 4.x version too.
Comment 20 Tomas Hoger 2011-04-05 15:46:50 EDT
Public now via:
http://www.isc.org/software/dhcp/advisories/cve-2011-0997
http://ftp.isc.org/isc/dhcp/dhcp-4.2.1-P1-RELNOTES
http://www.kb.cert.org/vuls/id/107886

Fixed upstream in versions: 3.1-ESV-R1, 4.1-ESV-R2 and 4.2.1-P1
Comment 21 Tomas Hoger 2011-04-06 05:03:09 EDT
Created dhcp tracking bugs for this issue

Affects: fedora-all [bug 694005]
Comment 22 Tomas Hoger 2011-04-06 11:32:10 EDT
SuSE folks reported that this fix may introduce a regressions in configurations that abuse domain-name option.  This option is documented to only contain single domain name that should be used by the client when resolving host names.  However, due to the way dhclient-script handles this option when generating resolv.conf, it was previously possible to define domain-name option in the dhcpd's configuration as:

  option domain-name "domain1.com domain2.com";

and have 'search domain1.com domain2.com' added to the resolv.conf on the client side.  This reportedly work well for Unix dhcp clients (but now Windows dhcp clients) and can be found being recommended in various internet discussions as a solution to the problem of distributing multiple search domains to the DHCP clients.

The patch enforces that the domain-name option value must be a valid domain name and hence does not allow a space in it.  A proposed workaround to preserve a compatibility with such configurations it to check the DHO_DOMAIN_NAME option in the same way as the DHO_DOMAIN_SEARCH, i.e. using check_domain_name_list() rather than check_domain_name().
Comment 23 Tomas Hoger 2011-04-06 11:46:38 EDT
Created attachment 490327 [details]
Marius' patch making domain-name check more lenient

See previous comment for details.
Comment 24 errata-xmlrpc 2011-04-08 10:39:22 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 4

Via RHSA-2011:0428 https://rhn.redhat.com/errata/RHSA-2011-0428.html
Comment 25 errata-xmlrpc 2011-05-31 10:52:27 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3 Extended Lifecycle Support

Via RHSA-2011:0840 https://rhn.redhat.com/errata/RHSA-2011-0840.html

Note You need to log in before you can comment on or make changes to this bug.