[ntp:security] [Bug 2941] New: NAK to the Future: Symmetric association authentication bypass via crypto-NAK

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Sun Oct 11 03:50:32 UTC 2015


             Bug #: 2941
           Summary: NAK to the Future: Symmetric association
                    authentication bypass via crypto-NAK
           Product: ntp
           Version: 4.2.8
          Platform: All
        OS/Version: All
            Status: CONFIRMED
          Severity: normal
          Priority: P3
         Component: Security Bugs
        AssignedTo: stenn at ntp.org
        ReportedBy: stenn at ntp.org
                CC: security at ntp.org
             Group: Security
    Classification: Unclassified

Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
              Flags|                            |blocking4.2.8+

Crypto-NAK packets can be used to cause ntpd to accept time from
unauthenticated ephemeral symmetric peers by bypassing the
authentication required to mobilize peer associations.

Ordinarily, successful mobilization of ephemeral symmetric
associations requires packets from the active peer to be
cryptographically authenticated.  This is controlled globally by the
`enable auth` option and on a per-peer basis with the `nopeer`

However, NTP versions 4.2.5p186-4.8.2p3 and the corresponding NTPsec
versions through a5fb34b9cc89b92a8fef2f459004865c93bb7f92 contain a
logic error that causes a symmetric passive peer association to be
mobilized upon receipt of a symmetric active (mode 1) crypto-NAK
packet.  After the association has been created, the crypto-NAK packet
will be discarded by the crypto-NAK test in the main packet processing
logic.  Crypto-NAK packets are not authenticated --- they contain only
a key id without a corresponding MAC.  As a result an unauthenticated
off-path attacker can force any ntpd daemon to mobilize a symmetric
passive peer association with addresses of their choosing by sending a
symmetric active crypto-NAK packets.

The resulting ephemeral association does not require cryptographically
authenticated packets.  When an association is mobilized, the keyid
used to authenticate the remote peer is derived from the packet that
caused mobilization.  In the case of a crypto-NAK packet, this is
typically keyid 0 which happens to be the keyid value indicating that
a peer need not authenticate its packets.  The packet processing logic
requires a packet to be authenticated if the association keyid != 0,
if the packet has a keyid or digest value, or if the peer is
restricted with a `notrust` restriction.  Therefore, in common
configurations, once the association has been mobilized, nothing
prevents an attacker from using the association as if it were a
legitimate peer.

We have successfully used this vulnerability to cause ntpd daemons
acting as either clients and servers to accept false time from an
attacker with ntp 4.8.2p3 and ntpsec
a5fb34b9cc89b92a8fef2f459004865c93bb7f92.  As long as the number of
attacking peers was greater than the number of legitimate peers, the
victim would eventually declare its legitimate peers to be false
tickers and accept time from the attacking peers.  This is trivial to
achieve as this vulnerability allows an attacker to create arbitrarily
many associations.

Most common ntpd configurations are exploitable using this
vulnerability.  Victim NTP daemons do not need to have any peer
associations configured to be susceptible.  As described in "Detection
& Mitigation" below, the only configuration directive that appears to
prevent exploitation is the `notrust` restriction, which is
incompatible with typical unauthenticated client-server configurations.

This defect was discovered by Matthew Van Gundy <mvangund at cisco.com>.

Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the security mailing list