From owner-freebsd-security@FreeBSD.ORG Mon Dec 22 23:23:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFB98C1E for ; Mon, 22 Dec 2014 23:23:47 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 983EE64B33 for ; Mon, 22 Dec 2014 23:23:47 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id QAA01574; Mon, 22 Dec 2014 16:23:12 -0700 (MST) Message-Id: <201412222323.QAA01574@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Dec 2014 14:46:51 -0700 To: Chris Nehren , freebsd-security@freebsd.org From: Brett Glass Subject: Re: ntpd vulnerabilities In-Reply-To: <20141222185238.GA3308@behemoth.lan> References: <252350272.1812596.1419241828431.JavaMail.zimbra@cleverbridge.com> <201412221745.KAA28186@mail.lariat.net> <20141222185238.GA3308@behemoth.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 23:23:47 -0000 At 11:52 AM 12/22/2014, Chris Nehren wrote: >Heartbleed, more than any other vulnerability in recent memory, >showed us users on the outside of the Project just how much >effort is involved in patching the base system (thank you, again, >DES, for being patient and explaining all the details!). Because >of this, I am reticent to support more software going into the >base system. I understand your concern! Frankly, both ntpd and OpenNTPD have more functionality than ought to be in the base system. The daemon in the base system probably should only query trusted servers for the time, as securely as possible, rather than also being a server itself. Within my own network, I have used cron and ntpdate (even though it's officially deprecated) on most of the clients, querying a couple of trusted local time servers. I've then armored those servers -- which do query the outside world -- as much as possible against abuse, with very restrictive security settings and stateful firewall rules for good measure. This is a super-lightweight approach from the clients' point of view; it takes up as little CPU and memory as possible on them. But it obviously has some drawbacks; in particular, it doesn't continuously correct the clocks but makes them jump at particular times of day. Ultimately, I'd love to see the whole world go to PKI-based digital signatures on responses to time queries. With the crypto accelerators that are now being built into many CPUs, this will probably become practical... IF one can trust the hardware not to have security holes or backdoors. Which is, of course, a big "if." --Brett Glass