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.
Created attachment 486815 [details] Proposed patch for ISC dhclient Created by Marius Tomaschewski of SUSE.
Created attachment 486816 [details] Proposed patch for dhclientv6 Created by Marius Tomaschewski of SUSE.
Created attachment 486817 [details] Proposed patch for dhcpcd Created by Marius Tomaschewski of SUSE.
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.
Created attachment 486993 [details] Updated proposed patch for ISC dhclient
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.
(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.
(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.
(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.
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?
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.
Created attachment 487590 [details] Proposed ISC patch Based on previous patches from Marius Tomaschewski.
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.
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.
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.
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
Created dhcp tracking bugs for this issue Affects: fedora-all [bug 694005]
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().
Created attachment 490327 [details] Marius' patch making domain-name check more lenient See previous comment for details.
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
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