[ntp:security] [Bug 2936] New: Skeleton Key: Missing key check allows impersonation between authenticated peers

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Sun Oct 11 01:24:06 UTC 2015


http://bugs.ntp.org/show_bug.cgi?id=2936

             Bug #: 2936
           Summary: Skeleton Key: Missing key check allows impersonation
                    between authenticated peers
           Product: ntp
           Version: 4.2.8
          Platform: All
        OS/Version: All
            Status: CONFIRMED
          Severity: normal
          Priority: P5
         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+

Symmetric key encryption requires a single trusted key to be specified for each
server configuration. A key specified only for one server should only work to
authenticate that server, other trusted keys should be refused.

Instead we observe that when symmetric key authentication is verified, there is
no check that the key used is the key specified for the address, any trusted
key can be used as long as the keyid references another key the systems share
and that key is used to compute the MAC.

This has three implications for the client server model. A client that has
multiple servers configured each with different keys could be attacked by one
of its servers spoofing every other server using its own key. Even worse a
server can be attacked by any of its authenticated clients in a similar manner.

Finally, being able to use any key to authenticate a packet for a client or
server means that if any key in the trustedkeys list uses a  weak digest
algorithim (MD5), then an attacker can abuse that method instead of being
restricted by the stronger keys configured.

There is no clear location in the code where this defect occurs, since it
exists due to an omission. Verifying the key used matches the proper server's
key could be done in ntp_proto.c around line 803 (in 4.8.2p3) where authdecrypt
is called, or it might make sense to build it into the libntp code such as the
authdecrypt function itself.

Be aware that this issue could affect other ntpd modes of operation such as
broadcast or active/passive peering.

This defect was discovered by Matt Street <mastreet 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