|Summary:||CVE-2015-1853 chrony: authentication doesn't protect symmetric associations against DoS attacks|
|Product:||[Other] Security Response||Reporter:||Kurt Seifried <kseifried>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||carnil, jrusnack, mlichvar|
|Fixed In Version:||Doc Type:||Bug Fix|
A denial of service flaw was found in the way chrony hosts that were peering with each other authenticated themselves before updating their internal state variables. An attacker could send packets to one peer host, which could cascade to other peers, and stop the synchronization process among the reached peers.
|Last Closed:||2015-11-20 05:27:19 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||1209579, 1209580, 1221579|
|Bug Blocks:||1200382, 1210268|
Description Kurt Seifried 2015-04-07 16:44:59 UTC
Miroslav Lichvar of Red Hat reports: An attacker knowing that NTP hosts A and B are peering with each other (symmetric association) can send a packet to host A with source address of B which will set the NTP state variables on A to the values sent by the attacker. Host A will then send on its next poll to B a packet with originate timestamp that doesn't match the transmit timestamp of B and the packet will be dropped. If the attacker does this periodically for both hosts, they won't be able to synchronize to each other. This is a known denial-of-service attack, described at . According to the document the NTP authentication is supposed to protect symmetric associations against this attack, but that doesn't seem to be the case. The state variables are updated even when authentication fails and the peers are sending packets with originate timestamps that don't match the transmit timestamps on the receiving side. This seems to be a very old problem, it's in the oldest ntp version I could find (xntp3.3wy). It's also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications, so other NTP implementations with support for symmetric associations and authentication may be vulnerable too. For authentication using symmetric keys it should be sufficient to move the code updating the state variables after the MAC is validated (TEST5). For autokey that's not enough, it seems the attacker can still reset the protocol with crypto-NAK or CRYPTO_ASSOC messages and possibly other ways. I'm not sure if this can be fixed for autokey in general.  https://www.eecis.udel.edu/~mills/onwire.html
Comment 1 Kurt Seifried 2015-04-07 16:57:21 UTC
Created chrony tracking bugs for this issue: Affects: epel-all [bug 1209579]
Comment 2 Kurt Seifried 2015-04-07 16:57:39 UTC
Created chrony tracking bugs for this issue: Affects: fedora-all [bug 1209580]
Comment 3 Kurt Seifried 2015-04-07 20:47:13 UTC
Acknowledgements: This issue was discovered by Miroslav Lichvár of Red Hat.
Comment 4 Kurt Seifried 2015-04-08 15:59:18 UTC
This issue was fixed upstream: http://chrony.tuxfamily.org/News.html The updated version is available at: http://download.tuxfamily.org/chrony/chrony-1.31.1.tar.gz
Comment 5 Fedora Update System 2015-04-22 22:42:58 UTC
chrony-2.0-0.3.pre2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 6 Fedora Update System 2015-04-22 22:53:47 UTC
chrony-1.31.1-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2015-04-23 19:00:44 UTC
chrony-1.31.1-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2015-04-23 19:02:45 UTC
chrony-1.31.1-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2015-04-24 22:50:01 UTC
chrony-1.31.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.