A missing DHCP option checking / sanitization flaw was reported for multiple DHCP clients. This flaw may allow DHCP server to trick DHCP clients to set e.g. system hostname to a specially crafted value containing shell special characters. Various scripts assume that hostname is trusted, which may lead to code execution when hostname is specially crafted.
This issue was tracked in bug #689832 for ISC dhclient (CVE-2011-0997), which also discussed few other affected clients. This bug is created to track dhcpv6 separately.
The impact for DHCPv6 clients is significantly lower than impact for DHCPv4 clients, as DHCPv6 does not allow passing hostname in the DHCP reply. DNS domain name search is provided in the DHCPv6 replies.
Proposed patch adding check for the domain-search option is attached in the previously mentioned bug #689832:
(In reply to comment #0)
> The impact for DHCPv6 clients is significantly lower than impact for DHCPv4
> clients, as DHCPv6 does not allow passing hostname in the DHCP reply. DNS
> domain name search is provided in the DHCPv6 replies.
There are currently no known good ways to take advantage of the specially-crafted domain name noted as "search" option value in /etc/resolv.conf. We have inspected various scripts that update resolv.conf file, none of them process existing search value insecurely.
The only problematic use that was identified was in shtool's sh.echo script. This script may possibly use search value as part of the replacement argument to the sed's substitution command. Special crafted value can result in the sed command execution, which may lead to file overwrite or direct code execution (GNU sed). This would require shtool's echo to be used with "%d" construct to request expansion to host's domain. Additionally, domain name extracted from hostname (only when '%h' is used too) or domain value from resolv.conf take precedence over the search value.