Date: Wed, 26 Mar 2014 02:33:15 -0400 From: Garrett Wollman <wollman@bimajority.org> To: Kimmo Paasiala <kpaasial@icloud.com> Cc: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? (Gary Palmer) Message-ID: <21298.29867.672397.320969@hergotha.csail.mit.edu> In-Reply-To: <FD8D10B1-9A78-4732-B379-718048D82FBF@icloud.com> References: <mailman.89.1395748802.54679.freebsd-security@freebsd.org> <EAD9B42E-3A77-4254-B9C6-4B0FAFE4F246@ogud.com> <FD8D10B1-9A78-4732-B379-718048D82FBF@icloud.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 26 Mar 2014 07:08:57 +0200, Kimmo Paasiala <kpaasial@icloud.com> said: > I believe Gary was talking about changing the control/status port > and not the actual service port (UDP 123). That should be doable > without breaking compatibility with existing NTP tools. NTP does not have a separate "control/status port"; all NTP operations that could be called "control" and "status" use the NTP protocol and the NTP port. If you configure your NTP server correctly (or start from a good default configuration), these operations will be restricted using NTP's built-in authentication and access-control mechanisms. In NTP-speak, the relevant packets are known as "mode 6" and "mode 7" messages. ntpq and ntpdc, since they run as non-root, will obviously use an ephemeral source port. Historically (not sure if it's still true), ntpd would generate a random key on startup and then fork a process to read the configuration file and handle DNS resolution; the child process would then use mode 7 messages to add associations in the main server process as each host name was resolved. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21298.29867.672397.320969>