December 2014 NTP Security Vulnerabilities

Updated -

Vulnerabilities under discussion

The vulnerabilities disclosed in December 2014 are:

Red Hat rates the combined impact of these vulnerabilities as Important. Some press reports have labelled them as critical, but due to the built-in mitigations in the default configuration shipped by Red Hat, the impact of these vulnerabilities on Red Hat Enterprise Linux is reduced.

Mitigations

In addition to handling time synchronization protocol packets, the ntpd daemon also processes special control packets that can be used to query information about the daemon status or change its configuration. This functionality is used by tools such as ntpq and ntpdc. Many of the reported problems only affect handling of these control packets, therefore it is recommended to only allow processing of those packets if they originate from a trusted source. Processing of these packets from NTP clients that only need to synchronize time with an NTP server is not necessary.

Restrictions based on IP addresses within ntpd

On Red Hat Enterprise Linux 5, 6 and 7, the default ntpd configuration only allows processing of control requests if they are sent from the local host. This restriction is defined by allowing control requests only from the 127.0.0.1 (IPv4) and ::1 (IPv6) addresses. The default configuration file, /etc/ntp.conf, shipped by the ntp package contains the following restrict configuration:

Raw
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1 
restrict -6 ::1

(On Red Hat Enterprise Linux 7, the restrict -6 default line is missing, as it is implied by the restrict default line.)

On Red Hat Enterprise Linux 4, it is recommended to replace the default restrict lines with the lines listed above, as the default configuration there does not restrict IPv6 access.

As NTP uses the UDP protocol, it may be possible to spoof the source IP address of packets in attempt to bypass above restrictions. See the following section for information on how to prevent packet spoofing.

Note: The configuration above still enables basic time service. If ntpd is required to perform services beyond that for specific hosts and networks (so that they can use the ntpq or ntpdc commands against the server running ntpd), they must be listed in the ntpd configuration with suitable restrict statements.

Filtering access with a packet filter

On Red Hat Enterprise Linux 4, 5, 6 and 7 the default firewall configuration blocks access to the NTP service using UDP port 123. Filtering of the NTP packets prevents exploitation of these issues.

If a system is configured to allow network traffic to the NTP service, and uses the configuration as described above to restrict control packets to the local host, an attacker might be able to forge (spoof) the source address IP of the UDP packets and bypass defined access restrictions. 127.0.0.1 (IPv4) or ::1 (IPv6) are particularly attractive choices as source addresses because they match the default restrict configuration mentioned above.

For IPv4, Red Hat Enterprise Linux 4 and 5 always drops incoming packets with the source address 127.0.0.1. Red Hat Enterprise Linux 6 and 7 does so by default, but spoofing of local addresses may be possible when using non-default route_localnet and rp_filter interface options settings.

For IPv6, Red Hat Enterprise Linux 7 prevents spoofing of the source address ::1 in its default configuration, as firewalld sets the following packet filter rule:

Raw
ip6tables -t raw -I PREROUTING -m rpfilter --invert -j DROP

The above rule can be used in configurations where packet filter rules are defined manually rather than by using the firewalld.

Red Hat Enterprise Linux 4, 5 and 6 do not prevent spoofing of the source address ::1 by default. They also do not support the rpfilter packet filter module. The following rule can be used to drop incoming packets with source address ::1 that are not received via the loopback interface:

Raw
ip6tables -t raw -I PREROUTING \! -i lo -s ::1 -j DROP

Note: With a permissive restrict configuration (unlike those described above), even with a packet filter, a configured IP-based time source will be able to access the ntpd configuration module and exploit the vulnerabilities because attack packets would have to be sent to the same UDP port as regular time information.

Flaw specific mitigations

CVE-2014-9295

This CVE refers to three separate buffer overflow flaws. Two of the issues affect handling of the control requests and hence can be mitigated by defining restrict and packet filter restrictions as described above. The third issue affects the Autokey public key authentication mechanism. Autokey authentication is not enabled in the default ntpd configuration in Red Hat Enterprise Linux. Ensuring that the ntp.conf includes no configuration directive starting with the crypto keyword can be used to verify that Autokey authentication is disabled.

CVE-2014-9293

This issue can be used to bypass authentication required for certain control requests and allow unauthenticated attacker to alter ntpd settings. It can also be used to make it possible to trigger one of the buffer overflows under CVE-2014-9295. ntpd automatically generates a key (required for its internal processing) on start if no requestkey is configured. The following commands can be used to ensure that a strong key is available to ntpd and prevent it from generating a new key:

Raw
echo trustedkey 65535 >> /etc/ntp.conf
printf "65535\tM\t%s\n" $(tr -cd a-zA-Z0-9 < /dev/urandom | head -c 16) >> /etc/ntp/keys

Note: The above steps are not needed when using updated ntp packages, as ntpd was fixed to generate strong keys.

CVE-2014-9294

Any MD5 keys (that is, those that have type M or MD5 in /etc/ntp/keys) that were generated using the vulnerable ntp-keygen version should be replaced. Either use ntp-keygen from the updated ntp packages to generate new keys, or use a similar approach as specified in the mitigation instructions for CVE-2014-9293 to generate one key:

Raw
tr -cd a-zA-Z0-9 < /dev/urandom | head -c 16

Note: MD5 keys should be regenerated even when updated ntp packages are installed. This is only needed if certain keys were explicitly generated before, as no keys are generated automatically when ntp is installed. The output of the ntp-keygen -M command may also include SHA-1 keys. These have always been generated by a different method, are not affected by the CVE-2014-9294 issue, and do not need to be regenerated.

CVE-2014-9297

The vulnerable code is a part of the NTP autokey protocol. The client sends a public RSA key to the server, which encrypts a 32 bit secret and sends it back to the client. The client then decrypts it and stores it in a 32 bit integer temp32, However, the decrypted cleartext can be up to (keysize/8)-42 in size (e.g. 214 bytes for a 2048 bit key), which can result in a stack based buffer overflow.

Mitigation involves disabling the autokey feature. Autokey authentication is not enabled in the default ntpd configuration in Red Hat Enterprise Linux. Ensuring that the ntp.conf includes no configuration directive starting with the crypto keyword can be used to verify that Autokey authentication is disabled.

CVE-2014-9298

NTP's access control is based on source address and localhost addresses generally have no restrictions, an attacker can send malicious control and configuration packets by spoofing ::1 addresses from the outside.

Mitigation involves following the above mitigation procedures, in restricting and controlling how IPv6 and ::1 is handled.

Impact on other implementations

These vulnerabilities are specific to the ntp implementation of the Network Time Protocol (from ntp.org). Other implementations, such as chrony, are not affected. The protocol as such is not affected.

Claims about ongoing exploitation

Red Hat is aware of press reports about active exploitation of these vulnerabilities. The initial ICS-CERT advisory for these vulnerabilities, ICSA-14-353-01, indicated that exploit code was publicly available. However, updated ICSA-14-353-01A states that “No known public exploits specifically target these vulnerabilities.”

In January 2015, instructions detailing how to combine these vulnerabilities to achieve remote code execution on Mac OS X were published.

Comments