From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 01:39:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3B4745E; Sat, 15 Mar 2014 01:39:20 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 996138FA; Sat, 15 Mar 2014 01:39:20 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id EF3501DE48; Fri, 14 Mar 2014 18:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394847560; bh=DNUQ3pXNQlHQwn3FQGEdcHyX4uOlbIDLrwPmgi8/KWg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=ZNTCTdbrFW7jbY8edeggDG7GzS3ISbet3ucJfuvzYMvYUP/ip/pk+l2jjY/g+ZgE4 CicgmvGIXeWTzcny/2P92HWv5x52ChaG2e+FN+obQ9sOrOouw/sCNWZkJmeaOtn9ZP EXNdWxj370Rzjjq4us5bnL83otJhn+IC3IgoiBnI= Message-ID: <5323AF47.9080107@delphij.net> Date: Fri, 14 Mar 2014 18:39:19 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Brett Glass , Fabian Wenk , freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> In-Reply-To: <201403141700.LAA21140@mail.lariat.net> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------070403090600020800020507" Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:39:20 -0000 This is a multi-part message in MIME format. --------------070403090600020800020507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/14/14 08:38, Brett Glass wrote: > We've tested this configuration on our servers and it successfully > prevents the latest patches of FreeBSD 9.x and 10.0 from > participating in a DDoS attack, either as a relay or as an > amplifier. FreeBSD 10.0-RELEASE ships with new default NTP settings, are you talking an earlier RC (before RC4 as r259975), or are you saying 10.0-RELEASE ships with a ntp.conf with wrong defaults? > Some of our own systems which were probed prior to the time we > secured them are still receiving a large stream of attack packets, > apparently from a botnet. > > I'd recommend that the lines above be included in the default > /etc/ntp.conf in all future releases, and that all systems that use > the This is done before the advisory as r259974 (2013-12-27 23:09:40Z). > default ntp.conf without modification be patched automatically via > freebsd-update. We sure can do this as a new advisory but it's not guaranteed to work because end user may have to do manual merge and may choose not to accept these. Note that like I stated before, for attackers it would be efficient to just deliver the packets themselves, plus, the suggested change does not remove their ability to do it because they can still deliver legitimate NTP inquiries with forged source IP to the NTP server which will still give response to the victim (or in your terms, "relay" which is technically inaccurate). An alternative would be to patch ntpd so that it blackholes the monlist request when monitor is disabled (see attachment). Note that while this would stop the response packet from attacker being sent to forged IP address if the packet is requesting for monlist, but not the case I have mentioned before. I'd like to request someone who is more familiar with NTP code to review that for me and see if we should do that as a necessary evil. (For hackers@lists.ntp.org: we have disabled 'monitor' in ntpd by default in [1] and this is an additional step for ntp prior to 4.2.7). [1] http://www.freebsd.org/security/advisories/FreeBSD-SA-14:02.ntpd.asc ; patch at http://security.freebsd.org/patches/SA-14:02/ntpd.patch Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTI69GAAoJEJW2GBstM+nswtIP/Rez/w+jB7bG7E2h+0H4JLfN /Vb0z1TDJ3IWhTee7cbuwAotNcyWv7zo91OWvJiBx8Idi/YCGlkSuSJve1JiwrN7 aFnkbega+JElYs2u9GJwgn0+eHHAWawLDa8NItu6v6G6TY5CZfHNaAXmUv6smak3 QH6MHB8E1h4Y0O525FkFErPxl8UvNpCD+RU7uDFeXof451b99R6CsZxlrfMlfxd3 D580k5NWNITJd/8jrYbd3dEIQyIEJDAGqYRf8vOgslIIi80UqmVJZmwYPZrDdD7L 4IoS7CsB5Zbhq9IT6ZEwRyPI7I1B5YmO3ynYvqZMgLb1mJ2aIT4CeqIflSHm/Cbb VJBJSX4LqUwp8W8mDfFf6ui5nDyNKXDNprZP6m7FquXDjM8E2UdeQMPXvLqwMBDT k7vZ9AELmIgBa+p6CK6cTGPhdUxWXQGkFob/3Fky4WpgZZZm9+vpVYK8IbpyWmNL MD5UukMUJtTE0XZUJb7VoAt3eW05N1spgPr1QGdzdR5OrokVV+XY9mQ7YcTyUMLJ AFieNlpS0rEQIifZeo8BbrUym2ds/hVAlGw8eMabPAVyQ+VLV8zTsmHU+vvaIvZR sDMA+5wr43lyuG5z7ysp84xg54KRu7ET2FlmiKHuaW6rJmBL/iHQlqn8+FAKuJJI EARE14TeLen2MjcXY8T4 =BmL2 -----END PGP SIGNATURE----- --------------070403090600020800020507 Content-Type: text/plain; charset=UTF-8; name="ntp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ntp.diff" Index: contrib/ntp/ntpd/ntp_request.c =================================================================== --- contrib/ntp/ntpd/ntp_request.c (revision 263196) +++ contrib/ntp/ntpd/ntp_request.c (working copy) @@ -1920,7 +1920,6 @@ mon_getlist_0( printf("wants monitor 0 list\n"); #endif if (!mon_enabled) { - req_ack(srcadr, inter, inpkt, INFO_ERR_NODATA); return; } im = (struct info_monitor *)prepare_pkt(srcadr, inter, inpkt, @@ -1965,7 +1964,6 @@ mon_getlist_1( extern int mon_enabled; if (!mon_enabled) { - req_ack(srcadr, inter, inpkt, INFO_ERR_NODATA); return; } im = (struct info_monitor_1 *)prepare_pkt(srcadr, inter, inpkt, --------------070403090600020800020507--