CVE-2015-7547, glibc vulnerability; its impact on Cisco products and our mitigation solutions

The Vulnerability 

On Tuesday, February 16th, Google’s security team announced a significant vulnerability in glibc . The vulnerability relates to the handling of DNS packets, and many Cisco systems are vulnerable to it if an attacker can cause an affected device to perform a DNS lookup against an attacker-controlled DNS server. As many services (ssh, some web servers, mail servers) do perform these requests in an externally controllable fashion, the risk and exposure of this vulnerability are extremely significant.

Cisco released their advisory for this issue on the 18th. Because of the extensive use of Linux in newer switching and routing products, UC servers, and security and management appliances, the potential scope of the issue is vast. Cisco is presently still in the process of qualifying products to determine if and how they are affected.

Here is an example of how the most common attack vector works. The attacker connects to a service (Mail, Video Conferencing, SSH, Web) that performs a DNS lookup, this could be a reverse lookup of the connecting service, it could also be a forward lookup triggered by the details of the request and protocol. The attacker returns hostile DNS traffic that then impacts the client device:

Cisco Products Most at Risk 

The products most at risk to this vulnerability are those that are most exposed to potential attackers. In most enterprise environments this constitutes first external users, then internal users. In this blog post, we’ll first address edge devices, discuss general mitigation techniques and finally highlight some information on IPS solutions.

At the enterprise, with the edge devices in Cisco’s product suite, our expectation is to find firewalls and border routers, as well as Expressway. In most common configurations, we don’t expect the firewalls and border routers to be vulnerable. These devices are rarely configured to make use of DNS servers. As the risk is caused by DNS resolution, a product that does not have a DNS resolver configured should not be affected by the issue. DNS inspection does not, to our knowledge, make use of the affected glibc code. Most ASA devices and edge firewalls are not configured to resolve DNS. Traditional IOS is not affected. If you have a real need to use DNS services on these devices, there are still mitigation methods available to you, we are in the process of developing edge and DNS server based configurations to mitigate these issues, however, they presently have a significant impact on DNS functionality. We plan to continue update the Stack8 blog with more details on these techniques as well as their impact.

ASA
For an ASA to be vulnerable, the dns domain lookup command must specify an interface and a dns server group must be configured.  Here’s an example of a vulnerable configuration:

dns domain-lookup outside
dns server-group DefaultDNS
name-server 8.8.8.8 8.8.4.4

[Mitigation

We recommend first validating if the DNS server is actually used; look for objects referencing a fqdn on devices running ASA 8.3 and newer, if it isn’t, then the best course of action is to remove the dns domain lookup command. If this isn’t possible please see the subsequent sections on mitigation below.

IOS XE
Border routers running IOS XE (e.g. ASR 1k) may also be vulnerable to this issue. Look for references to the ip name-server command:

ip domain-lookup
ip name-server 8.8.8.8 8.8.4.4

Mitigation 
By default, a router will also perform broadcast DNS lookups if no DNS server is specified. This can be disabled using the “no ip domain lookup” command. If your device is actively making use of DNS and this functionality cannot be disabled then please see the subsequent sections on mitigation below.

IOS XR
Border routers running IOS XR (e.g. ASR 9k) may also be vulnerable to this issue. Again it is not common to configure these devices with a DNS server.  Look for the presence of the following command configuring a DNS server.

domain name-server 8.8.8.8 8.8.4.4

Mitigation
You can completely disable DNS resolution on IOS XR using the domain lookup disable command:

domain lookup disable

 If you can’t disable DNS then please see the subsequent sections on mitigation below. ≈

Expressway and other Products
Expressway is one of the most at-risk devices because it’s core functionality, unlike most other edge products, is highly dependent on DNS. At present, there is no clear statement on the level of risk for this product, however, we believe it to be vulnerable as it is definitely a Linux-based appliance. A large number of Cisco’s other products, particularly in the UC, Management (Prime) and Security space are also Linux based and likely to be affected to some degree.

Network Level Mitigation

Edge Mitigation
As the vulnerability can only be exploited by larger packets, the following configurations should block traffic that uses UDP packets larger than 512 bytes and TCP packets larger than 1024. It is possible to configure border devices to drop this traffic. Be aware that this could have an impact on DNS performance as well as CPU load on devices that are not presently configured for inspection. Extreme caution is required while making these configuration changes and assessing their impact. Unfortunately, this change can block substantial amounts of valid DNS traffic.  The following rules will need to be carefully tested before implementation to ensure that there is no operational impact in your environment. We leave it to the readers discretion to decide specifically how to balance level of risk and service impact in their environment.

Blocking Large DNS Packets

ASA
Based on the default policy map of:

policy-map type inspect dns preset_dns_map
parameters
   message-length maximum client auto
   message-length maximum 512
policy-map global_policy
class inspection_default
   inspect dns preset_dns_map

We will make the following changes:

policy-map type inspect dns preset_dns_map
parameters
   no message-length maximum client auto

Unfortunately, this change only impacts UDP and not TCP DNS traffic, as such it is not a complete solution to blocking potentially hostile traffic. Please let us know if you’re aware of another method in the comments and we’ll update the post.

IOS
This policy-map will drop DNS traffic exceeding 512 bytes of udp or 1024 bytes of tcp for specific hosts mentioned in the glibc-block-tcp-traffic-acl and glibc-block-udp-traffic-acl ACLs.

Name Server Reconfiguration
There are configuration changes that can be made to DNS servers that reduce the size of DNS requests. One change that has a very substantial impact on DNS query size is disabling DNSSEC. This does increase the potential security impact of a MITM attacker but it also allows you to complete most DNS queries with much smaller packets. Here are the configuration changes required to address this issue on BIND and Active Directory, similar changes should be possible on other platforms.

BIND:
Adding the following to your named.conf to disable DNSSEC and EDNS:

dnssec-validation no;
edns no;

https://linux.die.net/man/5/named.conf

AD
Run the following commands and restart the DNS service in order to disable DNSSEC and EDNS

dnscmd /enableednsprobes 0
dnscmd /enablednssec 0

 And restart the DNS service.

https://technet.microsoft.com/en-us/library/cc772069.aspx

IPS Mitigation 

If you’re interested in ongoing support or project-based support; we would love to talk to you about your environment and your specific needs.