From owner-freebsd-security@FreeBSD.ORG Mon Sep 9 04:44:27 2013 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 ESMTP id 22913ADB for ; Mon, 9 Sep 2013 04:44:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BA852459 for ; Mon, 9 Sep 2013 04:44:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r894iMQ1079195 for ; Mon, 9 Sep 2013 14:44:23 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 9 Sep 2013 14:44:22 +1000 (EST) From: Ian Smith To: freebsd-security@freebsd.org Subject: Anything in this story of concern? Message-ID: <20130909144142.J99094@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 04:44:27 -0000 Ian From owner-freebsd-security@FreeBSD.ORG Mon Sep 9 05:42:07 2013 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 ESMTP id 9F4E02AB for ; Mon, 9 Sep 2013 05:42:07 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [174.136.100.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A5CC26CE for ; Mon, 9 Sep 2013 05:42:07 +0000 (UTC) Received: from chombo.houseloki.net (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id D1BC2E6040; Sun, 8 Sep 2013 22:42:00 -0700 (PDT) Received: from [127.0.0.1] (ivy.houseloki.net [10.9.70.20]) by chombo.houseloki.net (Postfix) with ESMTPSA id 6D878260; Sun, 8 Sep 2013 22:41:59 -0700 (PDT) Message-ID: <522D5FA3.7020701@bluerosetech.com> Date: Sun, 08 Sep 2013 22:41:55 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ian Smith Subject: Re: Anything in this story of concern? References: <20130909144142.J99094@sola.nimnet.asn.au> In-Reply-To: <20130909144142.J99094@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 05:42:07 -0000 On 9/8/2013 9:44 PM, Ian Smith wrote: > Have a look at estimates on the number of internet servers and desktops still vulnerable to BEAST, CRIME, et al. That's for the population of devices where updating the SSL library is about as easy as it gets. Now consider all those network devices and embedded systems with outdated firmware or where updating the embedded https/ssh server is impossible or the vendor won't bother. It's known the NSA prefers taps in central locations (like switches and routers) for better coverage efficiency. Combine these and the question of whether or not they're listening is one of capacity, not capability. This isn't really news, though. If you're worried about it, make sure your stuff uses TLS v1.2 with strong ciphers and large keys. From owner-freebsd-security@FreeBSD.ORG Mon Sep 9 06:09:11 2013 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 ESMTP id F31177E9 for ; Mon, 9 Sep 2013 06:09:11 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B96CD27FA for ; Mon, 9 Sep 2013 06:09:11 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 76FE73EB35; Mon, 9 Sep 2013 06:09:04 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r896935S094944; Mon, 9 Sep 2013 06:09:04 GMT (envelope-from phk@phk.freebsd.dk) To: Ian Smith Subject: Re: Anything in this story of concern? In-reply-to: <20130909144142.J99094@sola.nimnet.asn.au> From: "Poul-Henning Kamp" References: <20130909144142.J99094@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 09 Sep 2013 06:09:03 +0000 Message-ID: <94943.1378706943@critter.freebsd.dk> Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:09:12 -0000 In message <20130909144142.J99094@sola.nimnet.asn.au>, Ian Smith writes: > > That most likely just mean that everybody is using OpenSSL and that OpenSSL is a pile of crap. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Mon Sep 9 07:34:19 2013 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 ESMTP id 37AD68F8 for ; Mon, 9 Sep 2013 07:34:19 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id F00422C71 for ; Mon, 9 Sep 2013 07:34:18 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BDA263EB44; Mon, 9 Sep 2013 07:34:17 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r897YHAF095934; Mon, 9 Sep 2013 07:34:17 GMT (envelope-from phk@phk.freebsd.dk) To: "Koornstra, Reinoud" Subject: Re: Anything in this story of concern? In-reply-to: <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> From: "Poul-Henning Kamp" References: <20130909144142.J99094@sola.nimnet.asn.au> <94943.1378706943@critter.freebsd.dk> <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 09 Sep 2013 07:34:17 +0000 Message-ID: <95933.1378712057@critter.freebsd.dk> Cc: "freebsd-security@freebsd.org" , Ian Smith X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 07:34:19 -0000 In message <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.n et>, "Koornstra, Reinoud" writes: >Well, OpenSSL isn't the most beautiful code ever written for sure, but to >say it's a pile a crap would be a little too far to the negative end. >[...] >Most vulnerabilities in encryption are due to implementation issues. >Having not audited the OpenSSL code on this I cannot say whether there are >implementation issues there. You are of course entitled to have your own opinion, but I think you should go look at the bloody code before you voice an opinion. I call it a piece of crap, because the code clearly is not designed as much as thrown together from random phd-projects, and the most positive thing I can say about the API is that it is "opaque". Using OpenSSL correctly takes a LOT of skill and a fair bit of knowing "it only works if you do it this way", and most people lack that, so they copy & paste, which probably made the job much easier for NSA. I wrote a blog entry (In Danish: http://www.version2.dk/blog/nsas-gennembrud-eller-noget-53787) and I wanted to show an example. I opened an openssl source file at random and the first thing I see is: ASN1_OBJECT *OBJ_dup(const ASN1_OBJECT *o) { ASN1_OBJECT *r; int i; char *ln=NULL,*sn=NULL; unsigned char *data=NULL; if (o == NULL) return(NULL); if (!(o->flags & ASN1_OBJECT_FLAG_DYNAMIC)) return((ASN1_OBJECT *)o); /* XXX: ugh! Why? What kind of duplication is this??? */ [...] An "Obj_dup()" function which silently doesn't ? I am not going to enumerate how many ways that is wrong, it should not be necessary to do so in present company. And BTW: That XXX comment is 10 years old. No, I say with conviction, based on personal inspection and experience, that OpenSSL is crap. And as Garrett Wollman correctly pointed out on twitter: It remains yet to be seen if any implementation of SSL/TLS can be non-crap, given that they are stuck with X.509. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Mon Sep 9 12:35:05 2013 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 ESMTP id 85343B11 for ; Mon, 9 Sep 2013 12:35:05 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) 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 7033720F3; Mon, 9 Sep 2013 12:35:05 +0000 (UTC) Received: from [::100:0:0:0] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r89CZ2e8005950; Mon, 9 Sep 2013 12:35:03 GMT (envelope-from jonathan@FreeBSD.org) Date: Mon, 9 Sep 2013 13:35:09 +0100 From: Jonathan Anderson To: Poul-Henning Kamp Message-ID: <818FF794501044729A8936F009CF1B5F@FreeBSD.org> In-Reply-To: <95933.1378712057@critter.freebsd.dk> References: <20130909144142.J99094@sola.nimnet.asn.au> <94943.1378706943@critter.freebsd.dk> <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> <95933.1378712057@critter.freebsd.dk> Subject: Re: Anything in this story of concern? X-Mailer: sparrow 1.6.4 (build 1176) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "=?utf-8?Q?freebsd-security=40freebsd.org?=" , =?utf-8?Q?Koornstra=2C_Reinoud?= , Ian Smith X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:35:05 -0000 On Monday, 9 September 2013 at 08:34, Poul-Henning Kamp wrote: > And BTW: That XXX comment is 10 years old. > > No, I say with conviction, based on personal inspection and experience, > that OpenSSL is crap. > > And as Garrett Wollman correctly pointed out on twitter: It remains > yet to be seen if any implementation of SSL/TLS can be non-crap, > given that they are stuck with X.509. And you're stuck with the old, vulnerable OpenSSL in your BMC, that old router you've never gotten around to replacing, etc. I'm no fan of the OpenSSL API either, but it is possible to fix vulnerabilities when they arise; the much bigger problem is the set of vulnerabilities that you can't patch. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Mon Sep 9 12:51:32 2013 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 ESMTP id 30BA92A4 for ; Mon, 9 Sep 2013 12:51:32 +0000 (UTC) (envelope-from feld@FreeBSD.org) 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 E23D02222 for ; Mon, 9 Sep 2013 12:51:31 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CECD021D7A for ; Mon, 9 Sep 2013 08:51:19 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Mon, 09 Sep 2013 08:51:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=reNXOmU5c8IrpbfltyWHH3/w0EU=; b=o/c mANzsiS7Bj+u3hGRg8sbD022ujA2yWG355iWRolE3E0csLcTujruj9+IidsscVSU I2U8QgW9HpHKjS2e3yEa+IG5oGr0tjiZM+4snGCisZX0JqxdP5PzEQpNmPBHJSXo 0vBJRjHwfSCOb8UmA+bg7RhuVYvodVzyqsEZsdZE= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 97D03B000AE; Mon, 9 Sep 2013 08:51:19 -0400 (EDT) Message-Id: <1378731079.24879.19687157.0DBE99D1@webmail.messagingengine.com> X-Sasl-Enc: BM6+NRW8qRF7lhbJM9z70Ai8Vg7sSXt49+B23+5yXdWm 1378731079 From: Mark Felder To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15090c31 In-Reply-To: <20130909144142.J99094@sola.nimnet.asn.au> References: <20130909144142.J99094@sola.nimnet.asn.au> Subject: Re: Anything in this story of concern? Date: Mon, 09 Sep 2013 07:51:19 -0500 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:51:32 -0000 I'm still waiting for someone to thoroughly analyze this question What's worse: the possibility that NSA has cracked RC4 or being vulnerable to BEAST/CRIME? Set your crypto to a minimum of TLS 1.1 and let everyone who can't connect complain. At least their data wasn't compromised. This entire situation is maddening. From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 02:14:21 2013 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 ESMTP id 3DD32C20 for ; Tue, 10 Sep 2013 02:14:21 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D16CA2249 for ; Tue, 10 Sep 2013 02:14:20 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r8A2EHgD055240; Mon, 9 Sep 2013 22:14:17 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r8A2EHeR055237; Mon, 9 Sep 2013 22:14:17 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21038.32889.46054.73649@hergotha.csail.mit.edu> Date: Mon, 9 Sep 2013 22:14:17 -0400 From: Garrett Wollman To: "Poul-Henning Kamp" Subject: Re: Anything in this story of concern? In-Reply-To: <95933.1378712057@critter.freebsd.dk> References: <20130909144142.J99094@sola.nimnet.asn.au> <94943.1378706943@critter.freebsd.dk> <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> <95933.1378712057@critter.freebsd.dk> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Mon, 09 Sep 2013 22:14:17 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Tue, 10 Sep 2013 03:28:16 +0000 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 02:14:21 -0000 < said: > And as Garrett Wollman correctly pointed out on twitter: It remains > yet to be seen if any implementation of SSL/TLS can be non-crap, > given that they are stuck with X.509. I should say, by the way, that X.509 is not an inherent requirement of SSL/TLS, *but* it's what the clients implement. You can do GSSAPI authentication for the TLS key exchange, but there's little benefit in doing that versus just doing straight GSSAPI sign/seal and leaving TLS out of it completely. (Plus, there are only two options for GSSAPI; one of them doesn't work at Internet scale and the other is back to X.509 again.) You can also do OpenPGP-style Web of Trust authentication for the TLS key exchange, but that doesn't work at Internet scale either. GnuTLS supports both, however. What would work, would be better than the X.509 CA infrastructure we have now, and has been demonstrated experimentally, is using DNSsec to publish server public keys -- but that's hardly reducing the size of the TCB, and it would significantly worsen the impact of bugs in validating DNSsec implementations. The likely result, if browsers and servers began to support this as a legitimate option, would be that the existing rents collected by X.509 CAs would instead by paid to domain registries and registrars instead. (On the other hand, it seems unlikely that registries could get away with charging the same premium for a secure delegation as CAs now do for a wildcard certificate -- and the latter is a horrible idea anyway.) -GAWollman From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 11:20:49 2013 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 ESMTP id 1F36885F; Tue, 10 Sep 2013 11:20:49 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA0A2E3F; Tue, 10 Sep 2013 11:20:48 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D021149CA; Tue, 10 Sep 2013 11:20:47 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 5EDE536370; Tue, 10 Sep 2013 13:20:48 +0200 (CEST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:11.sendfile Precedence: bulk Message-Id: <20130910112048.5EDE536370@nine.des.no> Date: Tue, 10 Sep 2013 13:20:48 +0200 (CEST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 11:20:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:11.sendfile Security Advisory The FreeBSD Project Topic: Kernel memory disclosure in sendfile(2) Category: core Module: sendfile Announced: 2013-09-10 Credits: Ed Maste Affects: FreeBSD 9.2-RC1 and 9.2-RC2 Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2) CVE Name: CVE-2013-5666 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The sendfile(2) system call allows a server application (such as an HTTP or FTP server) to transmit the contents of a file over a network connection without first copying it to application memory. High performance servers such as Apache and ftpd use sendfile. II. Problem Description On affected systems, if the length passed to sendfile(2) is non-zero and greater than the length of the file being transmitted, sendfile(2) will pad the transmission up to the requested length or the next pagesize boundary, whichever is smaller. The content of the additional bytes transmitted in this manner depends on the underlying filesystem, but may potentially include information useful to an attacker. III. Impact An unprivileged user with the ability to run arbitrary code may be able to obtain arbitrary kernel memory contents. 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. [FreeBSD 9.2-STABLE] # fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-stable.patch # fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-stable.patch.asc # gpg --verify sendfile-9.2-stable.patch.asc [FreeBSD 9.2-RC1 and 9.2-RC2] # fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-rc.patch # fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-rc.patch.asc # gpg --verify sendfile-9.2-rc.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and 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/9/ r255443 releng/9.2/ r255444 - ------------------------------------------------------------------------- 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----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlIu8rIACgkQFdaIBMps37K01ACgmwaW3PZhjDqWSlTHusjIPNVy A/YAn3DFUAvlX8sH89taM+sedjbD5In8 =gZwu -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 11:20:50 2013 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 ESMTP id 32D28867; Tue, 10 Sep 2013 11:20:50 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C7A192E47; Tue, 10 Sep 2013 11:20:49 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id AE80449D3; Tue, 10 Sep 2013 11:20:48 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id C8EC936385; Tue, 10 Sep 2013 13:20:48 +0200 (CEST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:13.nullfs Precedence: bulk Message-Id: <20130910112048.C8EC936385@nine.des.no> Date: Tue, 10 Sep 2013 13:20:48 +0200 (CEST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 11:20:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:13.nullfs Security Advisory The FreeBSD Project Topic: Cross-mount links between nullfs(5) mounts Category: core Module: nullfs Announced: 2013-09-10 Credits: Konstantin Belousov Affects: All supported versions of FreeBSD. Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1) 2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7) 2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE) 2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4) 2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11) CVE Name: CVE-2013-5710 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The nullfs(5) filesystem allows all or a part of an already mounted filesystem to be made available in a different part of the global filesystem namespace. It is commonly used to make a set of files available to multiple chroot(2) or jail(2) environments without replicating the files in each environment. A common idiom, described in the FreeBSD Handbook, is to mount one subtree of a filesystem read-only within a jail's filesystem namespace, and mount a different subtree of the same filesystem read-write. II. Problem Description The nullfs(5) implementation of the VOP_LINK(9) VFS operation does not check whether the source and target of the link are both in the same nullfs instance. It is therefore possible to create a hardlink from a location in one nullfs instance to a file in another, as long as the underlying (source) filesystem is the same. III. Impact If multiple nullfs views into the same filesystem are mounted in different locations, a user with read access to one of these views and write access to another will be able to create a hard link from the latter to a file in the former, even though they are, from the user's perspective, different filesystems. The user may thereby gain write access to files which are nominally on a read-only filesystem. IV. Workaround No workaround is available, but systems which do not use the nullfs(5) filesystem, or do not null-mount different subtrees of the same source filesystem with different permissions, 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-13:13/nullfs.patch # fetch http://security.FreeBSD.org/patches/SA-13:13/nullfs.patch.asc # gpg --verify nullfs.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and 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/ r255445 releng/8.3/ r255446 releng/8.4/ r255447 stable/9/ r255443 releng/9.1/ r255448 releng/9.2/ r255444 - ------------------------------------------------------------------------- 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----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlIu+7EACgkQFdaIBMps37K+7gCfVrmhwyE+k5QU3Z4wsdJFoeyL BqEAn23QlLQ7o4HlDSiJuPoX622IsFbk =/7Zz -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 11:20:50 2013 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 ESMTP id 2918C864; Tue, 10 Sep 2013 11:20:50 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C22EF2E44; Tue, 10 Sep 2013 11:20:49 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id AAA7649D1; Tue, 10 Sep 2013 11:20:48 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id BCA9D36383; Tue, 10 Sep 2013 13:20:48 +0200 (CEST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:12.ifioctl Precedence: bulk Message-Id: <20130910112048.BCA9D36383@nine.des.no> Date: Tue, 10 Sep 2013 13:20:48 +0200 (CEST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 11:20:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:12.ifioctl Security Advisory The FreeBSD Project Topic: Insufficient credential checks in network ioctl(2) Category: core Module: sys_netinet6 sys_netatm Announced: 2013-09-10 Credits: Loganaden Velvindron Gleb Smirnoff Affects: All supported versions of FreeBSD. Corrected: 2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2) 2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1) 2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7) 2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE) 2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4) 2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11) CVE Name: CVE-2013-5691 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ioctl(2) system call allows an application to perform device- or protocol-specific operations through a file or socket descriptor associated with a specific device or protocol. The SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK ioctl requests are used to associate a network address, broadcast address, destination address (for point-to-point interfaces) or netmask with an interface. They operate on the assumption that each interface only has one address per protocol, and are therefore of limited use for IPv4, where interfaces may have more than one address. They were never implemented for IPv6, where interfaces nearly always have at least two, and in many cases three, addresses; nor were they ever implemented for ATM. II. Problem Description As is commonly the case, the IPv6 and ATM network layer ioctl request handlers are written in such a way that an unrecognized request is passed on unmodified to the link layer, which will either handle it or return an error code. Network interface drivers, however, assume that the SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK requests have been handled at the network layer, and therefore do not perform input validation or verify the caller's credentials. Typical link-layer actions for these requests may include marking the interface as "up" and resetting the underlying hardware. III. Impact An unprivileged user with the ability to run arbitrary code can cause any network interface in the system to perform the link layer actions associated with a SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR or SIOCSIFNETMASK ioctl request; or trigger a kernel panic by passing a specially crafted address structure which causes a network interface driver to dereference an invalid pointer. Although this has not been confirmed, the possibility that an attacker may be able to execute arbitrary code in kernel context can not be ruled out. 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-13:12/ifioctl.patch # fetch http://security.FreeBSD.org/patches/SA-13:12/ifioctl.patch.asc # gpg --verify ifioctl.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and 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/ r255445 releng/8.3/ r255446 releng/8.4/ r255447 stable/9/ r255443 releng/9.1/ r255448 releng/9.2/ r255444 - ------------------------------------------------------------------------- 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----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlIu8rUACgkQFdaIBMps37ImRQCdGUcSBvK6+kAN69aGChHT6fVb YI4AoJNveN9PSowTG0NnUkPJR9oJimZT =xb3g -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 11:21:18 2013 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 ESMTP id 9A9B46A3; Tue, 10 Sep 2013 11:21:18 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1F92E7F; Tue, 10 Sep 2013 11:21:18 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 9B67449DD; Tue, 10 Sep 2013 11:21:17 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 1FF3A36366; Tue, 10 Sep 2013 13:20:48 +0200 (CEST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:10.sctp [REVISED] Precedence: bulk Message-Id: <20130910112048.1FF3A36366@nine.des.no> Date: Tue, 10 Sep 2013 13:20:48 +0200 (CEST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 11:21:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:10.sctp Security Advisory The FreeBSD Project Topic: Kernel memory disclosure in sctp(4) Category: core Module: sctp Announced: 2013-08-22 Credits: Julian Seward, Michael Tuexen Affects: All supported versions of FreeBSD. Corrected: 2013-08-15 04:25:16 UTC (stable/9, 9.2-PRERELEASE) 2013-08-15 05:14:20 UTC (releng/9.2, 9.2-RC1-p1) 2013-08-15 05:14:20 UTC (releng/9.2, 9.2-RC2) 2013-08-22 00:51:48 UTC (releng/9.1, 9.1-RELEASE-p6) 2013-08-15 04:35:25 UTC (stable/8, 8.4-STABLE) 2013-08-22 00:51:56 UTC (releng/8.4, 8.4-RELEASE-p3) 2013-08-22 00:51:56 UTC (releng/8.3, 8.3-RELEASE-p10) CVE Name: CVE-2013-5209 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2013-08-22 Initial release. v1.1 2013-09-07 Binary patch released for 9.2-RC1. I. Background The SCTP protocol provides reliable, flow-controlled, two-way transmission of data. It is a message oriented protocol and can support the SOCK_STREAM and SOCK_SEQPACKET abstractions. The SCTP protocol checks the integrity of messages by validating the state cookie information that is returned from the peer. II. Problem Description When initializing the SCTP state cookie being sent in INIT-ACK chunks, a buffer allocated from the kernel stack is not completely initialized. III. Impact Fragments of kernel memory may be included in SCTP packets and transmitted over the network. For each SCTP session, there are two separate instances in which a 4-byte fragment may be transmitted. This memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way. For example, a terminal buffer might include a user-entered password. IV. Workaround No workaround is available, but systems not using the SCTP protocol 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-13:10/sctp.patch # fetch http://security.FreeBSD.org/patches/SA-13:10/sctp.patch.asc # gpg --verify sctp.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and 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/ r254354 releng/8.3/ r254632 releng/8.4/ r254632 stable/9/ r254352 releng/9.1/ r254631 releng/9.2/ r254355 - ------------------------------------------------------------------------- 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----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlIu+g8ACgkQFdaIBMps37JBjgCgkRdb24STra3EjItZymFqU0S8 6rQAn0EQeP1D8BUCIbzR5uNYrrNv9Eo6 =2Ot5 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 11:21:18 2013 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 ESMTP id 7F5216A2; Tue, 10 Sep 2013 11:21:18 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5182E7E; Tue, 10 Sep 2013 11:21:18 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 514E349DC; Tue, 10 Sep 2013 11:21:17 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id DD2983635F; Tue, 10 Sep 2013 13:20:47 +0200 (CEST) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:09.ip_multicast [REVISED] Precedence: bulk Message-Id: <20130910112047.DD2983635F@nine.des.no> Date: Tue, 10 Sep 2013 13:20:47 +0200 (CEST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Sep 2013 11:21:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:09.ip_multicast Security Advisory The FreeBSD Project Topic: integer overflow in IP_MSFILTER Category: core Module: kernel Announced: 2013-08-22 Credits: Clement Lecigne (Google Security Team) Affects: All supported versions of FreeBSD. Corrected: 2013-08-22 00:51:37 UTC (stable/9, 9.2-PRERELEASE) 2013-08-22 00:51:43 UTC (releng/9.1, 9.2-RC1-p1) 2013-08-22 00:51:43 UTC (releng/9.2, 9.2-RC2-p1) 2013-08-22 00:51:48 UTC (releng/9.1, 9.1-RELEASE-p6) 2013-08-22 00:51:37 UTC (stable/8, 8.4-STABLE) 2013-08-22 00:51:56 UTC (releng/8.4, 8.4-RELEASE-p3) 2013-08-22 00:51:56 UTC (releng/8.3, 8.3-RELEASE-p10) CVE Name: CVE-2013-3077 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2013-08-22 Initial release. v1.1 2013-09-07 Binary patch released for 9.2-RC1. I. Background IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission. II. Problem Description An integer overflow in computing the size of a temporary buffer can result in a buffer which is too small for the requested operation. III. Impact An unprivileged process can read or write pages of memory which belong to the kernel. These may lead to exposure of sensitive information or allow privilege escalation. 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-13:09/ip_multicast.patch # fetch http://security.FreeBSD.org/patches/SA-13:09/ip_multicast.patch.asc # gpg --verify ip_multicast.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and 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/ r254629 releng/8.3/ r254632 releng/8.4/ r254632 stable/9/ r254629 releng/9.1/ r254631 releng/9.2/ r254630 - ------------------------------------------------------------------------- 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----- Version: GnuPG v1.4.14 (FreeBSD) iEYEARECAAYFAlIu+gwACgkQFdaIBMps37L2+QCePwycOYKrh9VJi7Pc2AS+DfsQ UcUAnimJz9bKgDUOEIwefkPbF85yH3aw =tnWM -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 19:05:40 2013 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 ESMTP id 82E8B7D9; Tue, 10 Sep 2013 19:05:40 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 585492360; Tue, 10 Sep 2013 19:05:40 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2001:558:6025:2d:68f0:67e3:f35d:f840]) by rush.bluerosetech.com (Postfix) with ESMTPSA id 30F401141D; Tue, 10 Sep 2013 12:05:39 -0700 (PDT) Received: from [IPv6:2601:7:1680:365:70be:f335:56cc:10bc] (unknown [IPv6:2601:7:1680:365:70be:f335:56cc:10bc]) by chombo.houseloki.net (Postfix) with ESMTPSA id B84C77CA; Tue, 10 Sep 2013 12:05:34 -0700 (PDT) Message-ID: <522F6D79.9070208@bluerosetech.com> Date: Tue, 10 Sep 2013 12:05:29 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Felder Subject: Re: Anything in this story of concern? References: <20130909144142.J99094@sola.nimnet.asn.au> <1378731079.24879.19687157.0DBE99D1@webmail.messagingengine.com> In-Reply-To: <1378731079.24879.19687157.0DBE99D1@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:05:40 -0000 On 9/9/2013 5:51 AM, Mark Felder wrote: > I'm still waiting for someone to thoroughly analyze this question > > What's worse: the possibility that NSA has cracked RC4 or being > vulnerable to BEAST/CRIME? They're both equally bad, IMO. BEAST/CRIME are known, usable exploits. RC4 isn't proven broken, but it has been shown as weaker than expected, so 128-bit RC4 << 128-bit AES in terms of strength. That does mean if you're subject to certain privacy constraints, you must disable RC4. AFAIK there aren't yet any usable exploits against RC4's weaker status and it's still much stronger than 64-bit crypto--the point at which it's currently accepted as brute-force vulnerable. Currently, BEAST has been effectively mitigated client-side and most major applications now support 1.1 or later. Current Firefox and Thunderbird use NSS 3.14, which supports 1.1, but the apps have it disabled by default (set security.tls.version.max=2 in each to enable). Firefox 24 should have NSS 3.15.1 and thus support 1.2. IE on Windows 7/8 supports TLS 1.1 and 1.2, but have them disabled by default. IE 11 is supposed to have them enabled by default; but this is Microsoft, so we can't know until bits are out the door. Chrome, Opera and Safari support both and have them enabled by default. At the OS level, Windows and OS X both have 1.1 and 1.2 support. If your *nix of choice has OpenSSL 1.0.1, it has 1.1 and 1.2 support. OpenSSL is tricky because most apps only give you cipherspec control. Via cipherspec, !SSLv3 also turns off TLS 1.1 because it leaves only the 1.2-only AES-GCM ciphers. Some OpenSSL-based apps, like Postfix and nginx, have the ability to also specify a protocol filter. tl;dr: - Disable RC4, it's weak. - Upgrade your user apps. - Upgrade OpenSSL to 1.0.1 (via ports, it's easy). - Deploy TLS 1.1 and 1.2 on your servers today. - Leave SSLv3/TLSv1.0 enabled only for cases where you can't control the remote end's SSL capabilities. - Recommended OpenSSL 1.0.1 cipherspec: ALL:HIGH:!SSLv2:!MEDIUM:!LOW:!EXP:!RC4:!MD5:!aNULL:@STRENGTH From owner-freebsd-security@FreeBSD.ORG Tue Sep 10 19:09:52 2013 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 ESMTP id B0F50A78 for ; Tue, 10 Sep 2013 19:09:52 +0000 (UTC) (envelope-from feld@FreeBSD.org) 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 85DB723B1 for ; Tue, 10 Sep 2013 19:09:52 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 58E9E21119; Tue, 10 Sep 2013 15:09:51 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Tue, 10 Sep 2013 15:09:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=LrdWaIXJwCGwZel45hxnKK04kms=; b=my+Wk C+BixT7R3XFrw1VLMOJ0Req3VtgKuxcvQkxdBw5pALWPW7Nx4wKxoQdKY1KVSPPL gQOHo4Tc/iBKq8bwhp54EfXLXebeHoG/fzlLSABkbHRKQ+hxVC6+zUr+pFetTph/ j0CAkeB1opl2Ar+yLNt6VXCkQ8F2dIGXjhEDhg= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 23B37B000AE; Tue, 10 Sep 2013 15:09:51 -0400 (EDT) Message-Id: <1378840191.3555.20332769.2FCAFF2D@webmail.messagingengine.com> X-Sasl-Enc: WzKG9VEs7rXRDNiQyfgfx4M6tWa+ejDe9cm0Icp0NYZS 1378840191 From: Mark Felder To: Darren Pilgrim MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15090c31 Subject: Re: Anything in this story of concern? Date: Tue, 10 Sep 2013 14:09:51 -0500 In-Reply-To: <522F6D79.9070208@bluerosetech.com> References: <20130909144142.J99094@sola.nimnet.asn.au> <1378731079.24879.19687157.0DBE99D1@webmail.messagingengine.com> <522F6D79.9070208@bluerosetech.com> Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:09:52 -0000 On Tue, Sep 10, 2013, at 14:05, Darren Pilgrim wrote: > - Leave SSLv3/TLSv1.0 enabled only for cases where you can't control the > remote end's SSL capabilities. Which is what I routinely run into: public webhosting services. Customers will scream if their website doesn't work on every moderately reasonable device/browser. *sigh* you can't win in this game From owner-freebsd-security@FreeBSD.ORG Wed Sep 11 02:57:36 2013 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 ESMTP id 06C6A149 for ; Wed, 11 Sep 2013 02:57:36 +0000 (UTC) (envelope-from code@apotheon.net) Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by mx1.freebsd.org (Postfix) with SMTP id C8CC22F32 for ; Wed, 11 Sep 2013 02:57:35 +0000 (UTC) Received: (qmail 2935 invoked by uid 0); 11 Sep 2013 02:57:06 -0000 Received: from unknown (HELO box543.bluehost.com) (74.220.219.143) by oproxy1.mail.unifiedlayer.com with SMTP; 11 Sep 2013 02:57:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=apotheon.net; s=default; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=rlgz2JQhRh7dvux/cGny7fg2Tnz/+PzifzJ+hr9+MVQ=; b=Roqjb7nmYyAumR67aWSuhARxE3/FhV8nmr/Bb+bq+USGYlRKquForPicEJxLTVn6Ch49K3xXKTHfmFTXoiz8PblHMWqQE0BhC/w5Uv0uywWfJP41UmOQbaULO1yjIOPf; Received: from [24.9.112.144] (port=61085 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VJac6-0000yY-Ht for freebsd-security@freebsd.org; Tue, 10 Sep 2013 20:57:06 -0600 Date: Tue, 10 Sep 2013 20:56:39 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: Anything in this story of concern? Message-ID: <20130911025639.GD1902@glaze.hydra> References: <20130909144142.J99094@sola.nimnet.asn.au> <94943.1378706943@critter.freebsd.dk> <0EEF6678B3EEC94B9AE44705DF224D023D48BF92@G9W0725.americas.hpqcorp.net> <95933.1378712057@critter.freebsd.dk> <21038.32889.46054.73649@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21038.32889.46054.73649@hergotha.csail.mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 24.9.112.144 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 02:57:36 -0000 On Mon, Sep 09, 2013 at 10:14:17PM -0400, Garrett Wollman wrote: > < said: > > > And as Garrett Wollman correctly pointed out on twitter: It remains > > yet to be seen if any implementation of SSL/TLS can be non-crap, > > given that they are stuck with X.509. > > I should say, by the way, that X.509 is not an inherent requirement of > SSL/TLS, *but* it's what the clients implement. You can do GSSAPI > authentication for the TLS key exchange, but there's little benefit in > doing that versus just doing straight GSSAPI sign/seal and leaving TLS > out of it completely. (Plus, there are only two options for GSSAPI; > one of them doesn't work at Internet scale and the other is back to > X.509 again.) You can also do OpenPGP-style Web of Trust > authentication for the TLS key exchange, but that doesn't work > at Internet scale either. GnuTLS supports both, however. It seems that you're saying something like Monkeysphere or Perspectives would somehow not work "at Internet scale", but it seems to me that the real weakness of these things would be a case of *small* scale, in that if either is not widely-enough used it will not suffice for many sites that are not popular enough to attract a sufficient percentage of the clients who actually use Monkeysphere or Perspectives. Granted, neither Monkeysphere nor Perspectives is *exactly* like PGP web of trust in how it works (both are more about merely achieving broad client agreements in practice, and not actual cryptographic trust relationships), so an actual direct port of PGP web of trust infrastructure to TLS key authentication might suffer other problems for scale, but I am not sure exactly what about the web of trust model you meant to indicate would not scale. > > What would work, would be better than the X.509 CA infrastructure we > have now, and has been demonstrated experimentally, is using DNSsec to > publish server public keys -- but that's hardly reducing the size of > the TCB, and it would significantly worsen the impact of bugs in > validating DNSsec implementations. The likely result, if browsers and > servers began to support this as a legitimate option, would be that > the existing rents collected by X.509 CAs would instead by paid to > domain registries and registrars instead. (On the other hand, it > seems unlikely that registries could get away with charging the same > premium for a secure delegation as CAs now do for a wildcard > certificate -- and the latter is a horrible idea anyway.) The real problem with CAs, honestly, is the fact that you have to *trust* the CAs . . . and I do not. They are simply not trustworthy. This seems like a problem that would make the transition to domain registries quite intact, based on what I know of the situation. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Wed Sep 11 15:00:45 2013 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 ESMTP id 0B15C3AA; Wed, 11 Sep 2013 15:00:45 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C414F2171; Wed, 11 Sep 2013 15:00:44 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 0E8E44862; Wed, 11 Sep 2013 15:00:44 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2EEDC3703A; Wed, 11 Sep 2013 17:00:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org Subject: HEADS UP: OpenSSH with DNSSEC support in 10 Date: Wed, 11 Sep 2013 17:00:15 +0200 Message-ID: <86hadre740.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 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:00:45 -0000 OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you disable LDNS in src.conf. If DNSSEC is enabled, the default setting for VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" (aka "train the user to type 'yes' and hit enter") and "no" (aka "train the user to type 'yes' and hit enter without even the benefit of a second opinion"). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Sep 11 15:25:57 2013 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 ESMTP id 2F88617A; Wed, 11 Sep 2013 15:25:57 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 049F4234E; Wed, 11 Sep 2013 15:25:56 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VJmIl-0006Ct-MC; Wed, 11 Sep 2013 15:25:55 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r8BFPp2N007288; Wed, 11 Sep 2013 09:25:51 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX187S8EOtombVK278KHwUr7i Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86hadre740.fsf@nine.des.no> References: <86hadre740.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 11 Sep 2013 09:25:51 -0600 Message-ID: <1378913151.1111.613.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r8BFPp2N007288 X-Mailman-Approved-At: Wed, 11 Sep 2013 15:40:51 +0000 Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:25:57 -0000 On Wed, 2013-09-11 at 17:00 +0200, Dag-Erling Sm=F8rgrav wrote: > OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you > disable LDNS in src.conf. If DNSSEC is enabled, the default setting fo= r > VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust > DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" > (aka "train the user to type 'yes' and hit enter") and "no" (aka "train > the user to type 'yes' and hit enter without even the benefit of a > second opinion"). >=20 > DES So what happens when there is no dns server to consult? Will every ssh connection have to wait for a long dns query timeout? What if the machine is configured to use only /etc/hosts? What if a DNS server is configured but doesn't respond? For that matter, I just realized I'm a bit unclear on who is querying DNS for this info, the ssh client or the sshd? -- Ian From owner-freebsd-security@FreeBSD.ORG Wed Sep 11 15:42:45 2013 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 ESMTP id 4050577E; Wed, 11 Sep 2013 15:42:45 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 028992470; Wed, 11 Sep 2013 15:42:44 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id EA9B74945; Wed, 11 Sep 2013 15:42:43 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 15EC3370B3; Wed, 11 Sep 2013 17:42:45 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 References: <86hadre740.fsf@nine.des.no> <1378913151.1111.613.camel@revolution.hippie.lan> Date: Wed, 11 Sep 2013 17:42:45 +0200 In-Reply-To: <1378913151.1111.613.camel@revolution.hippie.lan> (Ian Lepore's message of "Wed, 11 Sep 2013 09:25:51 -0600") Message-ID: <86d2ofe556.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, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:42:45 -0000 Ian Lepore writes: > So what happens when there is no dns server to consult? Will every > ssh connection have to wait for a long dns query timeout? What if the > machine is configured to use only /etc/hosts? If there is no DNS server, no query will be sent. > What if a DNS server is configured but doesn't respond? The DNS request will time out. In the vast majority of cases, you will either have no DNS at all (so no query will be sent), or you will have a functioning DNS server. In a slightly less vast majority of cases, you will not be able to resolve the server's IP address without DNS anyway. > For that matter, I just realized I'm a bit unclear on who is querying > DNS for this info, the ssh client or the sshd? The client - and you can override this in your ~/.ssh/config or on the command line (-oVerifyHostKeyDNS=3Dno). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 00:15:11 2013 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 ESMTP id E5452D54 for ; Thu, 12 Sep 2013 00:15:11 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c: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 A8DB8222D for ; Thu, 12 Sep 2013 00:15:11 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so6615513vcb.26 for ; Wed, 11 Sep 2013 17:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ub2s43Vo7fl04jpnThi1erBJO1Ae4lcEIQz+NhsGUbE=; b=NYKymiMBoYewGNWch43m17to0+t5qrqwOHdW39StsIasYIZttzaMuROBVuIPhiU1Sz e4GdcURZ/LzC0v4ApQZa9X/iV7hwVJVhjlhcisk70Cm60+CoX+2dXZ+zEru60p/qH/s2 dNDUKTQ75MjK8VNj5rjoSAuGLKgx6Zyp9+SZjpF4RWmvDvn+v8Mrqx4fiibj4iol0HNh gwQi4Ipvthb7a1ei81Nd90qwvllK2bB/TZh2JHy3puX1lPTOR6NwBJd7AkdEqdT7kJW5 qo0GI7NkNsPl3LB8FfuHR/6FdWvcvxxXlZ9dX3zYL0hYUMbwHmnSq7KbfnrwhMeu+Bjb bajQ== MIME-Version: 1.0 X-Received: by 10.52.114.231 with SMTP id jj7mr3257350vdb.2.1378944910757; Wed, 11 Sep 2013 17:15:10 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Wed, 11 Sep 2013 17:15:10 -0700 (PDT) Date: Wed, 11 Sep 2013 14:15:10 -1000 Message-ID: Subject: FreeBSD Transient Memory problem? From: Jonathon Wright To: freebsd-security@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 00:15:12 -0000 All, I have posted this question (username-scryptkiddy) in the forums: http://forums.freebsd.org/showthread.php?t=41875 but was suggested to bring it here to the mailing list for discussion. Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were inspected by a security team and they had issues with FreeBSD's memory management. Namely the transient memory and object reuse areas of FreeBSD. They claimed that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed, and therefore was vulnerable to the Transient memory problem. Our higher ups need some sort of documentation / testing that can be used to counter this, since changing Operating Systems is not something we have time / manpower to do, but might have too based on this supposed 'finding'. The post has all the details. Let me know I need to repost in this as well. JW From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 03:18:18 2013 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 ESMTP id CEAFCB75; Thu, 12 Sep 2013 03:18:18 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCD92A77; Thu, 12 Sep 2013 03:18:17 +0000 (UTC) X-AuditID: 12074422-b7ef78e000000935-35-523132729b94 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 96.FA.02357.27231325; Wed, 11 Sep 2013 23:18:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r8C3IAV8000969; Wed, 11 Sep 2013 23:18:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8C3I7vR009134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Sep 2013 23:18:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r8C3I5vi010679; Wed, 11 Sep 2013 23:18:05 -0400 (EDT) Date: Wed, 11 Sep 2013 23:18:05 -0400 (EDT) From: Benjamin Kaduk To: Ian Lepore Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 In-Reply-To: <1378913151.1111.613.camel@revolution.hippie.lan> Message-ID: References: <86hadre740.fsf@nine.des.no> <1378913151.1111.613.camel@revolution.hippie.lan> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1512555890-1378955885=:16692" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1i02MgwyeMlnMeHKDyaLnk1P2Cye HH/D7MDsMePTfJYAxigum5TUnMyy1CJ9uwSujAO9a5gK9nFXnPjwmKmBcSVnFyMnh4SAicTC czfYIGwxiQv31gPZXBxCAvsYJa73z2eEcDYySuy50Q/lHGKSuLakF8ppYJTYvXM/K0g/i4C2 xOnzSxlBbDYBFYmZbzaCzRURUJDYMm81cxcjBwezgKnE1GOFIKawgIVEw/wSkApOATuJR8s+ MIPYvAKOEidXLAebKCQQJfFwQRvYRFEBHYnV+6ewQNQISpyc+QTMZhYIlDjT/4tpAqPgLCSp WUhSELa1xIa3U6FsbYn7N9vYFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11cvNLNFLTSnd xAgKa3YXpR2MPw8qHWIU4GBU4uHtmGUQJMSaWFZcmXuIUZKDSUmUt1zbMEiILyk/pTIjsTgj vqg0J7X4EKMEB7OSCO+tf0DlvCmJlVWpRfkwKWkOFiVx3vVO+kFCAumJJanZqakFqUUwWRkO DiUJ3kxDoKGCRanpqRVpmTklCGkmDk6Q4TxAw+eD1PAWFyTmFmemQ+RPMSpKifNWgSQEQBIZ pXlwvbC084pRHOgVYd5ikCoeYMqC634FNJgJaPB3X32QwSWJCCmpBkY50T6FK1esu053PXA6 +2RxOPd+lrjljueWfj/1d8VLnS0/ZWe/nehdamhXOv1w8b3Ha+wtOy7xTy1Y/q5T5PSU319n TRPU+HIl2eN0c+Ht6b3mav1Wc0KfVR3wmNE48WthdKtmfFCT5gZxlxDHQqOMC1GJMVc5Vij6 OrNs2/65N1T627P8hAYlluKMREMt5qLiRAC2dNgkFgMAAA== Cc: freebsd-security@freebsd.org, current@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 03:18:19 -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. ---559023410-1512555890-1378955885=:16692 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 11 Sep 2013, Ian Lepore wrote: > On Wed, 2013-09-11 at 17:00 +0200, Dag-Erling Sm=F8rgrav wrote: >> OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you >> disable LDNS in src.conf. If DNSSEC is enabled, the default setting for >> VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust >> DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" >> (aka "train the user to type 'yes' and hit enter") and "no" (aka "train >> the user to type 'yes' and hit enter without even the benefit of a >> second opinion"). >> >> DES > > So what happens when there is no dns server to consult? Will every ssh > connection have to wait for a long dns query timeout? There is a long precent for ssh waiting on DNS timeouts, with the GSSAPI*= =20 options. At least in some cases, ssh could end up waiting for 3 retries=20 against each KDC for each of some six GSSAPI mechanisms, at (IIRC) a=20 3-second timeout each. This was so bad that corrective action was taken,= =20 but there are still some delays if DNS is not functioning properly. -Ben Kaduk ---559023410-1512555890-1378955885=:16692-- From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 05:36:00 2013 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 ESMTP id D61DA299 for ; Thu, 12 Sep 2013 05:36:00 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B7882121 for ; Thu, 12 Sep 2013 05:36:00 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r8C5ZxrI090799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 22:35:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8C5ZxxH090798; Wed, 11 Sep 2013 22:35:59 -0700 (PDT) (envelope-from jmg) Date: Wed, 11 Sep 2013 22:35:59 -0700 From: John-Mark Gurney To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? Message-ID: <20130912053559.GF68682@funkthat.com> Mail-Followup-To: Jonathon Wright , freebsd-security@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 11 Sep 2013 22:35:59 -0700 (PDT) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 05:36:00 -0000 Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: > I have posted this question (username-scryptkiddy) in the forums: > http://forums.freebsd.org/showthread.php?t=41875 > but was suggested to bring it here to the mailing list for discussion. > > Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were > inspected by a security team and they had issues with FreeBSD's memory > management. > > Namely the transient memory and object reuse areas of FreeBSD. They claimed > that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed, > and therefore was vulnerable to the Transient memory problem. Any system that uses malloc will have difficulties with this as most versions of free will not zero out the memory... You could make modifications to kernel malloc to always zero memory on free, and turn on the junk feature of jemalloc and that could possibly close this issue for them... > Our higher ups need some sort of documentation / testing that can be used > to counter this, since changing Operating Systems is not something we have > time / manpower to do, but might have too based on this supposed 'finding'. > > The post has all the details. Let me know I need to repost in this as well. I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for nCircle a number of years ago, and they got their products EAL3 cerified. Link: http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf It is possible someone else has received certification on a newer version, but I'm not aware of any at this time... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 14:49:23 2013 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 ESMTP id 66040197 for ; Thu, 12 Sep 2013 14:49:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 1E0ED2831 for ; Thu, 12 Sep 2013 14:49:22 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r8CEnA7n083466 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 07:49:14 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5231D461.5050504@freebsd.org> Date: Thu, 12 Sep 2013 22:49:05 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:49:23 -0000 On 9/12/13 8:15 AM, Jonathon Wright wrote: > All, > > I have posted this question (username-scryptkiddy) in the forums: > http://forums.freebsd.org/showthread.php?t=41875 > but was suggested to bring it here to the mailing list for discussion. > > Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were > inspected by a security team and they had issues with FreeBSD's memory > management. > > Namely the transient memory and object reuse areas of FreeBSD. They claimed > that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed, > and therefore was vulnerable to the Transient memory problem. > > Our higher ups need some sort of documentation / testing that can be used > to counter this, since changing Operating Systems is not something we have > time / manpower to do, but might have too based on this supposed 'finding'. > > The post has all the details. Let me know I need to repost in this as well. Pretty much all they've proved to me is that they have no idea of what they are talking about. You need to ask them for a better description of the problem as so far all you've seen is about a hundred computer science professionals rolling around on the floor laughing when you showed them the paragraph from the report.. and you can quote me on that one. > > JW > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 15:46:06 2013 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 ESMTP id 00FED70 for ; Thu, 12 Sep 2013 15:46:05 +0000 (UTC) (envelope-from brett@lariat.org) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 99D8C2B99 for ; Thu, 12 Sep 2013 15:46:05 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA21486; Thu, 12 Sep 2013 09:46:02 -0600 (MDT) Message-Id: <201309121546.JAA21486@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Sep 2013 09:45:54 -0600 To: Jonathon Wright , freebsd-security@freebsd.org From: Brett Glass Subject: Re: FreeBSD Transient Memory problem? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:46:06 -0000 FreeBSD has a "transient memory problem?" Not so far as I remember. But maybe I have a transient memory problem. ;-) --Brett Glass From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 15:50:55 2013 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 ESMTP id 98D0A2AE for ; Thu, 12 Sep 2013 15:50:55 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 382062C1B for ; Thu, 12 Sep 2013 15:50:54 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA21437; Thu, 12 Sep 2013 09:43:31 -0600 (MDT) Message-Id: <201309121543.JAA21437@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Sep 2013 09:43:15 -0600 To: Jonathon Wright , freebsd-security@freebsd.org From: Brett Glass Subject: Re: FreeBSD Transient Memory problem? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 12 Sep 2013 15:52:43 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:50:55 -0000 FreeBSD has a "transient memory problem?" Not so far as I remember. But maybe I have a transient memory problem. ;-) --Brett Glass From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 17:40:21 2013 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 ESMTP id F3DB4A67; Thu, 12 Sep 2013 17:40:20 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C6154239B; Thu, 12 Sep 2013 17:40:20 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id kq13so1406936pab.11 for ; Thu, 12 Sep 2013 10:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=JeHgFw8aO2XeCSNbzPKUtOjCuH2BE5Y0+7Xz5qZZmQg=; b=MKe6GDGstIxJxHH7sdNIodeHcjQuyDA80V4ebLiKJrjFeC+8zrTVwkLq1m1RVLX4Y7 /HiepFPk/shkS2N7GcRpr/UNJCzutbD0p6YDEFyY/ImqpZgFsTmTKgW4KW4wVHI4Nk1k agNfseISVDtIya3JGDpipExfFsk12t3EJTTwOZDEbglvN3JEp37t2ZEvIm0pBHQHgZlz 2VEcoOpLmSzPZdCR3Xg3+2SVFw50mWVqlCxiMqSOfYmg+WbLoz/El9DasJpQO59um/7y T7vd3h62RLhMcfJjKizDWfENmRz9pGBwD5W7B/BYmG2t/CgPMzppVAvVDW4oiwrpt+U7 nYug== X-Received: by 10.67.4.197 with SMTP id cg5mr10716852pad.10.1379007620391; Thu, 12 Sep 2013 10:40:20 -0700 (PDT) Received: from [192.168.1.102] (cpe-98-150-133-16.hawaii.res.rr.com. [98.150.133.16]) by mx.google.com with ESMTPSA id ve9sm6168828pbc.19.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 10:40:19 -0700 (PDT) References: <5231D461.5050504@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <5231D461.5050504@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <26028E42-5FB6-43EF-A70E-7A531711BC65@gmail.com> X-Mailer: iPhone Mail (10B329) From: My Email Subject: Re: FreeBSD Transient Memory problem? Date: Thu, 12 Sep 2013 07:40:17 -1000 To: Julian Elischer Cc: "freebsd-security@FreeBSD.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:40:21 -0000 I hear ya, except they (the team) has successfully played the fallacy of 'sh= ifting the burden of proof' to our management. I've argued that to them alre= ady but they refuse to put the burden of proof back on the inspection team. ...So now its up to me to prove FreeBSD does not have this issue when it sho= uld be up to them to prove FreeBSD does. I kinda figured it was not a battle that I'm supposed to win, since the prob= lem they've presented cannot be proven true or false without more info. The o= nly info I have is what was posted in the forums though. Will update if new details unfold. JW On Sep 12, 2013, at 4:49 AM, Julian Elischer wrote: > On 9/12/13 8:15 AM, Jonathon Wright wrote: >> All, >>=20 >> I have posted this question (username-scryptkiddy) in the forums: >> http://forums.freebsd.org/showthread.php?t=3D41875 >> but was suggested to bring it here to the mailing list for discussion. >>=20 >> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were >> inspected by a security team and they had issues with FreeBSD's memory >> management. >>=20 >> Namely the transient memory and object reuse areas of FreeBSD. They claim= ed >> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed= , >> and therefore was vulnerable to the Transient memory problem. >>=20 >> Our higher ups need some sort of documentation / testing that can be use= d >> to counter this, since changing Operating Systems is not something we hav= e >> time / manpower to do, but might have too based on this supposed 'finding= '. >>=20 >> The post has all the details. Let me know I need to repost in this as wel= l. >=20 > Pretty much all they've proved to me is that they have no idea of what the= y are talking about. > You need to ask them for a better description of the problem as so far all= you've > seen is about a hundred computer science professionals rolling around on t= he floor > laughing when you showed them the paragraph from the report.. >=20 > and you can quote me on that one. >=20 >>=20 >> JW >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >>=20 >=20 From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 17:49:46 2013 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 ESMTP id 3F4A8D0C for ; Thu, 12 Sep 2013 17:49:46 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 162E1241F for ; Thu, 12 Sep 2013 17:49:46 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz10so1416697pad.16 for ; Thu, 12 Sep 2013 10:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=eDafvGqLqdC9uXfYW0jUImfEDnB1Mul2+7a88MAUaiY=; b=W9SuD/RiSnPFO0W+cuSNi2kFYV6NhTjQWkyYUsVSW+Id9bcKPN5Zw2mUaPoK3+Zsgc HMN3ab1p10RVwzNrNkXiFFhmdRW0eS7DcJS9OsbuPDakNrvQty22DBXNCCvB1dIN+0ga 2JVR+IsXkHO33+AfxVAsnNLUIdKC/qlhT8nv79xbNM4bs4Hlk3JGEmMFfrKLQriPJYyk HEFaP+4nFHQP+SrggxGHDP8o4XmqcFnXUyQgz7aykD5UGbsOUN7lB3twr0nFAdob0AuP eg5tmVONqhgJSjsSQKOuULe9QTNoEZHN/9gKPZgQyBgoTuqEpU5Qwhweq0FFjJn/2bDS V6/g== X-Received: by 10.66.141.144 with SMTP id ro16mr3256778pab.173.1379008185744; Thu, 12 Sep 2013 10:49:45 -0700 (PDT) Received: from [192.168.1.102] (cpe-98-150-133-16.hawaii.res.rr.com. [98.150.133.16]) by mx.google.com with ESMTPSA id dw3sm6211069pbc.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 10:49:44 -0700 (PDT) References: <20130912053559.GF68682@funkthat.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20130912053559.GF68682@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> X-Mailer: iPhone Mail (10B329) From: My Email Subject: Re: FreeBSD Transient Memory problem? Date: Thu, 12 Sep 2013 07:49:43 -1000 To: John-Mark Gurney Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:49:46 -0000 My apologies, I have been replying too all, I hope that is the correct metho= d. Anyway, that is very interesting information. I'd be extremely interested in= information on customizing malloc and jemalloc. Let me know where to start.= Thanks! JW On Sep 11, 2013, at 7:35 PM, John-Mark Gurney wrote: > Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: >> I have posted this question (username-scryptkiddy) in the forums: >> http://forums.freebsd.org/showthread.php?t=3D41875 >> but was suggested to bring it here to the mailing list for discussion. >>=20 >> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were >> inspected by a security team and they had issues with FreeBSD's memory >> management. >>=20 >> Namely the transient memory and object reuse areas of FreeBSD. They claim= ed >> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed= , >> and therefore was vulnerable to the Transient memory problem. >=20 > Any system that uses malloc will have difficulties with this as most > versions of free will not zero out the memory... You could make > modifications to kernel malloc to always zero memory on free, and turn on > the junk feature of jemalloc and that could possibly close this issue > for them... >=20 >> Our higher ups need some sort of documentation / testing that can be use= d >> to counter this, since changing Operating Systems is not something we hav= e >> time / manpower to do, but might have too based on this supposed 'finding= '. >>=20 >> The post has all the details. Let me know I need to repost in this as wel= l. >=20 > I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for > nCircle a number of years ago, and they got their products EAL3 > cerified. >=20 > Link: > http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.p= df >=20 > It is possible someone else has received certification on a newer version,= > but I'm not aware of any at this time... >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 18:12:30 2013 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 ESMTP id 98ACFB68 for ; Thu, 12 Sep 2013 18:12:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 EF3D82632 for ; Thu, 12 Sep 2013 18:12:29 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r8CI0gHD083926 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 11:00:45 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52320144.2090807@freebsd.org> Date: Fri, 13 Sep 2013 02:00:36 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: My Email Subject: Re: FreeBSD Transient Memory problem? References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> In-Reply-To: <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" , John-Mark Gurney X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 18:12:30 -0000 On 9/13/13 1:49 AM, My Email wrote: > My apologies, I have been replying too all, I hope that is the correct method. > > Anyway, that is very interesting information. I'd be extremely interested in information on customizing malloc and jemalloc. Let me know where to start. Thanks! it's hard to know how to refute it because they don't explain WHAT memory they are talking about. there is NO OS in the world that can survive that test if they are talking about protection from a malware kernel module. On the other hand if they are just talking about user memory allocation then of course we NEVER hand uncleared memory to anyone. (even root). Ask them to tell you what memory they are talking about.. and if they want free memory in the pool to be clear then it wouldn't take much to add a module that zeros non vnode memory when it's handed back to the kernel. But for all we know they are talking about people stealing punch cards and photographing them.. > JW > > On Sep 11, 2013, at 7:35 PM, John-Mark Gurney wrote: > >> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: >>> I have posted this question (username-scryptkiddy) in the forums: >>> http://forums.freebsd.org/showthread.php?t=41875 >>> but was suggested to bring it here to the mailing list for discussion. >>> >>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were >>> inspected by a security team and they had issues with FreeBSD's memory >>> management. >>> >>> Namely the transient memory and object reuse areas of FreeBSD. They claimed >>> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed, >>> and therefore was vulnerable to the Transient memory problem. >> Any system that uses malloc will have difficulties with this as most >> versions of free will not zero out the memory... You could make >> modifications to kernel malloc to always zero memory on free, and turn on >> the junk feature of jemalloc and that could possibly close this issue >> for them... >> >>> Our higher ups need some sort of documentation / testing that can be used >>> to counter this, since changing Operating Systems is not something we have >>> time / manpower to do, but might have too based on this supposed 'finding'. >>> >>> The post has all the details. Let me know I need to repost in this as well. >> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for >> nCircle a number of years ago, and they got their products EAL3 >> cerified. >> >> Link: >> http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf >> >> It is possible someone else has received certification on a newer version, >> but I'm not aware of any at this time... >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 18:32:08 2013 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 ESMTP id 81D984C8 for ; Thu, 12 Sep 2013 18:32:08 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5AC60285B for ; Thu, 12 Sep 2013 18:32:07 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r8CIW7Pn001214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 11:32:07 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8CIW7S2001212; Thu, 12 Sep 2013 11:32:07 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Sep 2013 11:32:07 -0700 From: John-Mark Gurney To: My Email Subject: Re: FreeBSD Transient Memory problem? Message-ID: <20130912183206.GK68682@funkthat.com> Mail-Followup-To: My Email , "freebsd-security@freebsd.org" References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 12 Sep 2013 11:32:07 -0700 (PDT) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 18:32:08 -0000 My Email wrote this message on Thu, Sep 12, 2013 at 07:49 -1000: > My apologies, I have been replying too all, I hope that is the correct method. > > Anyway, that is very interesting information. I'd be extremely interested in information on customizing malloc and jemalloc. Let me know where to start. Thanks! For jemalloc, look at man malloc: opt.junk for kernel malloc, look at sys/kern_malloc.c.. It doesn't look like there is a knob to turn on kernel malloc filling, but it wouldn't be hard... Though the performance impact of junk filling is very significant... > On Sep 11, 2013, at 7:35 PM, John-Mark Gurney wrote: > > > Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: > >> I have posted this question (username-scryptkiddy) in the forums: > >> http://forums.freebsd.org/showthread.php?t=41875 > >> but was suggested to bring it here to the mailing list for discussion. > >> > >> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were > >> inspected by a security team and they had issues with FreeBSD's memory > >> management. > >> > >> Namely the transient memory and object reuse areas of FreeBSD. They claimed > >> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation completed, > >> and therefore was vulnerable to the Transient memory problem. > > > > Any system that uses malloc will have difficulties with this as most > > versions of free will not zero out the memory... You could make > > modifications to kernel malloc to always zero memory on free, and turn on > > the junk feature of jemalloc and that could possibly close this issue > > for them... > > > >> Our higher ups need some sort of documentation / testing that can be used > >> to counter this, since changing Operating Systems is not something we have > >> time / manpower to do, but might have too based on this supposed 'finding'. > >> > >> The post has all the details. Let me know I need to repost in this as well. > > > > I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for > > nCircle a number of years ago, and they got their products EAL3 > > cerified. > > > > Link: > > http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf > > > > It is possible someone else has received certification on a newer version, > > but I'm not aware of any at this time... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 19:33:35 2013 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 ESMTP id AA828318; Thu, 12 Sep 2013 19:33:35 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c: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 558C9207C; Thu, 12 Sep 2013 19:33:35 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so206775vcb.12 for ; Thu, 12 Sep 2013 12:33:34 -0700 (PDT) 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=MPDEspAd95gvCUyx6syp6IQgn9qAzkOLApDtoDM6br4=; b=euA/sradHsliiw5mMI7b0u2Xn0EUEpG5ufwjThwFf3UJ+fEF6t8q+isMuux80zKVD2 bn0pF9j2V0ryuqJs1zcsfi4Yd5o3G1tQsYjF3Y2+SK3949g/vfIrgVgPJZOmUWVrQfi/ +GiIzeqTGYBgvbKQ9xZulWeq4mY3wJeZmy0mcS9yNiUp1uFIgqS5vGtq2El9YGqTuenO olLrWKM/uJrssKtN+1WPdZYEGiSEDO4RJnQSLprI/E2j8ZhTvAQGbFmokhAlM1zIyp9B DZv+kUCyCfaAhAjS3ZiLL4OfJqhdqcdf5Rj8eFq+8pl9NO9BVJJ8soeahIWq77LoSUBp XRkQ== MIME-Version: 1.0 X-Received: by 10.220.10.194 with SMTP id q2mr7932411vcq.2.1379014414328; Thu, 12 Sep 2013 12:33:34 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Thu, 12 Sep 2013 12:33:34 -0700 (PDT) In-Reply-To: <52320144.2090807@freebsd.org> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> Date: Thu, 12 Sep 2013 09:33:34 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:33:35 -0000 I agree, really, I do. This is very frustrating to me. Unfortunately, the team has left and gone to another project. They indicated to our management that we had 90 days to address the issue with our plan. Its a bit harder to contact them now since they are gone, but I can probably get some questions to them. They did leave a copy of the report, here is the entire verbiage: ---BEGIN *Description of Finding:* Object reuse cannot be verified. The FreeBSD servers used have not been evaluated or certified by NIAP. As such, it cannot be verified that the operating system ensures transient memory cleansing (object reuse) features are in place. *Rationale for Severity Code Determination:* The Validation team has determined this to be a Category II finding. By using unapproved Operating Systems (OS) which do not ensure that no residual data from a former object exists, a malicious user could gain access to memory and OS objects that contain sensitive information. *Recommended Countermeasure(s):* Transition servers to an NIAP approved OS. Decommission the FreeBSD servers. ---END What I think they are looking for is a verification that every malloc has a call to free afterwords that zeros out the memory used. I could be wrong, but just a guess. JW On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer wrote: > On 9/13/13 1:49 AM, My Email wrote: > >> My apologies, I have been replying too all, I hope that is the correct >> method. >> >> Anyway, that is very interesting information. I'd be extremely interested >> in information on customizing malloc and jemalloc. Let me know where to >> start. Thanks! >> > > it's hard to know how to refute it because they don't explain WHAT memory > they are talking about. > there is NO OS in the world that can survive that test if they are talking > about protection from a malware kernel module. > On the other hand if they are just talking about user memory allocation > then of course we NEVER hand uncleared memory to anyone. (even root). Ask > them to tell you what memory they are talking about.. > and if they want free memory in the pool to be clear then it wouldn't take > much to > add a module that zeros non vnode memory when it's handed back to the > kernel. > > But for all we know they are talking about people stealing punch cards and > photographing them.. > > JW >> >> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney wrote: >> >> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: >>> >>>> I have posted this question (username-scryptkiddy) in the forums: >>>> http://forums.freebsd.org/**showthread.php?t=41875 >>>> but was suggested to bring it here to the mailing list for discussion. >>>> >>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were >>>> inspected by a security team and they had issues with FreeBSD's memory >>>> management. >>>> >>>> Namely the transient memory and object reuse areas of FreeBSD. They >>>> claimed >>>> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation >>>> completed, >>>> and therefore was vulnerable to the Transient memory problem. >>>> >>> Any system that uses malloc will have difficulties with this as most >>> versions of free will not zero out the memory... You could make >>> modifications to kernel malloc to always zero memory on free, and turn on >>> the junk feature of jemalloc and that could possibly close this issue >>> for them... >>> >>> Our higher ups need some sort of documentation / testing that can be >>>> used >>>> to counter this, since changing Operating Systems is not something we >>>> have >>>> time / manpower to do, but might have too based on this supposed >>>> 'finding'. >>>> >>>> The post has all the details. Let me know I need to repost in this as >>>> well. >>>> >>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for >>> nCircle a number of years ago, and they got their products EAL3 >>> cerified. >>> >>> Link: >>> http://www.**commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** >>> 20v1.0.pdf >>> >>> It is possible someone else has received certification on a newer >>> version, >>> but I'm not aware of any at this time... >>> >>> -- >>> John-Mark Gurney Voice: +1 415 225 5579 >>> >>> "All that I will do, has been done, All that I have, has not." >>> >> ______________________________**_________________ >> >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@** >> freebsd.org " >> >> > From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 19:35:23 2013 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 ESMTP id 40F04440 for ; Thu, 12 Sep 2013 19:35:23 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF2C920C2 for ; Thu, 12 Sep 2013 19:35:22 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz11so224010veb.3 for ; Thu, 12 Sep 2013 12:35:22 -0700 (PDT) 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 :content-type; bh=BMuVPR+ZuC4L7IOT4x7r6hel2901JXJfT6wT4a8b678=; b=A+F5WjcTQrNngl106uMswnud0T/a5kd1oqNFVIz214+MkBgPzJaMlvI+6OHxAJqzFR tTBHEuEAk3NW+Q0RbJUW3huLWGcUEgZHGT4KUsWnKtVpVhiJBsFqlogXBrJyJ5bYy6G9 +VEKiSiNQZtZpNXkAzRicDAb8oSNbVDUf9qAlSLmaTupHmUFszWqP1miwDvsUTpKYF82 lmAx04LBMvpoyf/XKA9WgTXhshd9ssoDgoPwoSmAKRnsX75nVfhqgVFvFlxhFakyfnF/ Gy6ozL1BX/c36nVLeKRXdJ7reZ6GxIXrsD/5ToMA/aHkIyqX9k+f7Q/c9Kb/ccuIyKJ4 7n7A== MIME-Version: 1.0 X-Received: by 10.52.119.139 with SMTP id ku11mr1246168vdb.42.1379014522041; Thu, 12 Sep 2013 12:35:22 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Thu, 12 Sep 2013 12:35:21 -0700 (PDT) In-Reply-To: <20130912183206.GK68682@funkthat.com> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <20130912183206.GK68682@funkthat.com> Date: Thu, 12 Sep 2013 09:35:21 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: My Email , "freebsd-security@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:35:23 -0000 I'm looking into it now, I'm sure I'll have more questions, thanks for the starting point though! On Thu, Sep 12, 2013 at 8:32 AM, John-Mark Gurney wrote: > My Email wrote this message on Thu, Sep 12, 2013 at 07:49 -1000: > > My apologies, I have been replying too all, I hope that is the correct > method. > > > > Anyway, that is very interesting information. I'd be extremely > interested in information on customizing malloc and jemalloc. Let me know > where to start. Thanks! > > For jemalloc, look at man malloc: opt.junk > > for kernel malloc, look at sys/kern_malloc.c.. It doesn't look like > there is a knob to turn on kernel malloc filling, but it wouldn't be > hard... > > Though the performance impact of junk filling is very significant... > > > On Sep 11, 2013, at 7:35 PM, John-Mark Gurney wrote: > > > > > Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: > > >> I have posted this question (username-scryptkiddy) in the forums: > > >> http://forums.freebsd.org/showthread.php?t=41875 > > >> but was suggested to bring it here to the mailing list for discussion. > > >> > > >> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were > > >> inspected by a security team and they had issues with FreeBSD's memory > > >> management. > > >> > > >> Namely the transient memory and object reuse areas of FreeBSD. They > claimed > > >> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation > completed, > > >> and therefore was vulnerable to the Transient memory problem. > > > > > > Any system that uses malloc will have difficulties with this as most > > > versions of free will not zero out the memory... You could make > > > modifications to kernel malloc to always zero memory on free, and turn > on > > > the junk feature of jemalloc and that could possibly close this issue > > > for them... > > > > > >> Our higher ups need some sort of documentation / testing that can be > used > > >> to counter this, since changing Operating Systems is not something we > have > > >> time / manpower to do, but might have too based on this supposed > 'finding'. > > >> > > >> The post has all the details. Let me know I need to repost in this as > well. > > > > > > I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for > > > nCircle a number of years ago, and they got their products EAL3 > > > cerified. > > > > > > Link: > > > > http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf > > > > > > It is possible someone else has received certification on a newer > version, > > > but I'm not aware of any at this time... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 19:54:03 2013 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 ESMTP id 29D7EF7; Thu, 12 Sep 2013 19:54:03 +0000 (UTC) (envelope-from brett@lariat.org) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C48E322BF; Thu, 12 Sep 2013 19:54:02 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id NAA24598; Thu, 12 Sep 2013 13:53:57 -0600 (MDT) Message-Id: <201309121953.NAA24598@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Sep 2013 13:53:52 -0600 To: Jonathon Wright , Julian Elischer From: Brett Glass Subject: Re: FreeBSD Transient Memory problem? In-Reply-To: References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "freebsd-security@freebsd.org" , John-Mark Gurney X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:54:03 -0000 At 01:33 PM 9/12/2013, Jonathon Wright wrote: >*Description of Finding:* Object reuse cannot be verified. The FreeBSD >servers used have not been evaluated or certified by NIAP. As such, it >cannot be verified that the operating system ensures transient memory >cleansing (object reuse) features are in place. Translation: The FreeBSD Project doesn't participate in, and hasn't paid money to be certified by, a program run by the NSA... a shadowy government agency which has been known to actively compromise security and spy on citizens. We recommend that our clients move to a less secure OS so that their systems can be spied upon and their security compromised. --Brett Glass P.S. -- For more on NIAP, see www.niap-ccevs.org. Note that this site will deposit multiple tracking cookies in your browser which you may want to delete after visiting it. From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 20:03:14 2013 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 ESMTP id 434D566D; Thu, 12 Sep 2013 20:03:14 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E293C236E; Thu, 12 Sep 2013 20:03:13 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id ib11so239822vcb.14 for ; Thu, 12 Sep 2013 13:03:13 -0700 (PDT) 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=JqWoKXXvKvywZtEK1OzKnxAoObxHzDLX+svxLxp5kbQ=; b=S9lJMwaomIWsa8xy3FEj/p+QzSpfGAslJydkhNypFTNj1pF+F8/Nv6NJCCJI6YWWx5 7BGLq6OXQjDvZZaz3IbeiiwuO7RS9O/+8wkSdS//ku8PLsdWhOQbVkOOG0W29wjXdcyU A/DuNyMLRPa4h22GtdJOH9phZVGpYaFcqg2tPd/ZufQxEnV0OU1Zk5QQLtZWsvW6cxRe Gq7iW6w7BTzVH47Fsg61z0YHJ6Lq2xb3VjXyAnSPbKDBLJRsry17n/K21Eh6A7fWJgGV BxsZOtHb0jhrpERJ+00w/MvWjKyBQDp5Ly71k8Mma/AD8OLoTMpWsmpP4KvmCkJxDeFZ RnAQ== MIME-Version: 1.0 X-Received: by 10.52.230.74 with SMTP id sw10mr6601341vdc.6.1379016192983; Thu, 12 Sep 2013 13:03:12 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Thu, 12 Sep 2013 13:03:12 -0700 (PDT) In-Reply-To: <201309121953.NAA24598@mail.lariat.net> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309121953.NAA24598@mail.lariat.net> Date: Thu, 12 Sep 2013 10:03:12 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:03:14 -0000 Great translation Brett, the whole team is rolling! Unfortunately, its probably true. Yeah, I went to the site, interesting, but I'm not sure how shady they are or not. In either case, my problem still remains. I'm looking into what John-Mark Gurney posted to me, it looks a bit promising as far as being able to "demonstrate" the zeroing of the memory allocated prior to use. For example, when I did a man malloc, the Z option states exactly that: The problem though is it also states that "this is intended for debugging and will impact performance negatively". That means I'm in between a rock and hard spot: 1. If I turn it on, I'll have horrible performance. (I suppose I need a /etc/malloc.conf example if I did if you have one) 2. if I don't turn it on, I am not able to address their so called 'issue'. On Thu, Sep 12, 2013 at 9:53 AM, Brett Glass wrote: > At 01:33 PM 9/12/2013, Jonathon Wright wrote: > > *Description of Finding:* Object reuse cannot be verified. The FreeBSD >> >> servers used have not been evaluated or certified by NIAP. As such, it >> cannot be verified that the operating system ensures transient memory >> cleansing (object reuse) features are in place. >> > > Translation: The FreeBSD Project doesn't participate in, and hasn't paid > money to be certified by, a program run by the NSA... a shadowy government > agency which has been known to actively compromise security and spy on > citizens. We recommend that our clients move to a less secure OS so that > their > systems can be spied upon and their security compromised. > > --Brett Glass > > P.S. -- For more on NIAP, see www.niap-ccevs.org. Note that this site will > deposit multiple tracking cookies in your browser which you may want to > delete after visiting it. > > From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 20:33:56 2013 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 ESMTP id 95E3FEA2; Thu, 12 Sep 2013 20:33:56 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9202552; Thu, 12 Sep 2013 20:33:56 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id e15so259765vbg.18 for ; Thu, 12 Sep 2013 13:33:55 -0700 (PDT) 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=hdXrW4n+3lWwdaD/ORy9+pirdNBJ4t53KxbqRz4XXZA=; b=l5+9pHWtfJBxQ3YeWUbEA+piTS5LrB0zqkHTuiZuatp3gBU4Xh6MkwPHCNvFPSueYm wmiaHYlMYMNBEG/PkjfZjm96mr83jRbR5pZ/Lj0ChuyZ5Dwp8NXjX4CT0z2rIzbWXKFd lmjo5ByMZwoM8WYCvBbr9eD827tOV62OfB+4Ytkcs5BRfEt4ssvSm8ZAcxKaISHw8cSI 7bPJgJNkHCQSztKkhrG74H6kZcib8kNn4Liay1AA58Yho51wQl7RIXzQoOMxXEwoj2Gv Qybmbf2YZrOd2hzfgiejJfGrNQMKj8t+uJPPhT9yxkRGvhK+2CqnAlO2ew2lqZ4S5d+r e4og== MIME-Version: 1.0 X-Received: by 10.58.161.116 with SMTP id xr20mr8272032veb.2.1379018034963; Thu, 12 Sep 2013 13:33:54 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Thu, 12 Sep 2013 13:33:54 -0700 (PDT) In-Reply-To: References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> Date: Thu, 12 Sep 2013 10:33:54 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: Guy Helmer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:33:56 -0000 Thanks for those insights Guy. Makes sense that they are referring to security boundaries (inter-process related) only. I didn't get the reference (witness the sendmail() security advisory earlier this week). Was there a reference to this issue in the one earlier this week, and / or how do I view the security advisories? As far as the book, I am trying to find an online version that I can copy / paste out the section that would talk about this. I did go back to the teams local rep who is simply "tracking" the item. He stated that the "proof" would preferrably be an EAL cert, but verbiage in that book or other "formal" documenation would be considered. So few questions: Do you know where I can get the book in an online copy? Do you have a link to nCircle or site (my GoogleFu is not very strong, I only got tripwire hits) Thanks On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer wrote: > On Sep 12, 2013, at 2:33 PM, Jonathon Wright > wrote: > > > I agree, really, I do. This is very frustrating to me. Unfortunately, the > > team has left and gone to another project. They indicated to our > management > > that we had 90 days to address the issue with our plan. Its a bit harder > to > > contact them now since they are gone, but I can probably get some > questions > > to them. They did leave a copy of the report, here is the entire > verbiage: > > > > ---BEGIN > > > > *Description of Finding:* Object reuse cannot be verified. The FreeBSD > > servers used have not been evaluated or certified by NIAP. As such, it > > cannot be verified that the operating system ensures transient memory > > cleansing (object reuse) features are in place. > > > > *Rationale for Severity Code Determination:* The Validation team has > > determined this to be a Category II finding. By using unapproved > Operating > > Systems (OS) which do not ensure that no residual data from a former > object > > exists, a malicious user could gain access to memory and OS objects that > > contain sensitive information. > > > > *Recommended Countermeasure(s):* Transition servers to an NIAP approved > OS. > > Decommission the FreeBSD servers. > > ---END > > > > What I think they are looking for is a verification that every malloc > has a > > call to free afterwords that zeros out the memory used. I could be wrong, > > but just a guess. > > > > JW > > Two common forms of object reuse are in memory allocation to a process and > in blocks allocated to a file. As far as I understand the issue, > malloc/free within a single process would not be a relevant concern > (generally, only inter-process activity crosses security boundaries). A > malloc that causes VM pages to be assigned to the process by the kernel, or > file writes that cause blocks to be allocated to a file, would be the among > the relevant issues. Unfortunately, as I'm not a VM or FS guru, I can't > point to particular points in the kernel source that show that memory is > zeroed when allocated to a new process, or blocks are zeroed when allocated > to a file. However, this is fundamental to secure operation of any modern > system, and if there is *any* evidence that FreeBSD operates to the > contrary, it would be worthy of a security advisory (witness the sendfile() > security advisory from earlier this week). > > I don't have a copy of "Design and Implementation of FreeBSD" handy, but I > would imagine it points out the relevant code paths. However, it seems your > management wants evidence of EAL certification, not evidence from code. > Perhaps you can borrow such certification from nCircle or others. > > Guy > > > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer > wrote: > > > >> On 9/13/13 1:49 AM, My Email wrote: > >> > >>> My apologies, I have been replying too all, I hope that is the correct > >>> method. > >>> > >>> Anyway, that is very interesting information. I'd be extremely > interested > >>> in information on customizing malloc and jemalloc. Let me know where to > >>> start. Thanks! > >>> > >> > >> it's hard to know how to refute it because they don't explain WHAT > memory > >> they are talking about. > >> there is NO OS in the world that can survive that test if they are > talking > >> about protection from a malware kernel module. > >> On the other hand if they are just talking about user memory allocation > >> then of course we NEVER hand uncleared memory to anyone. (even root). > Ask > >> them to tell you what memory they are talking about.. > >> and if they want free memory in the pool to be clear then it wouldn't > take > >> much to > >> add a module that zeros non vnode memory when it's handed back to the > >> kernel. > >> > >> But for all we know they are talking about people stealing punch cards > and > >> photographing them.. > >> > >> JW > >>> > >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney > wrote: > >>> > >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: > >>>> > >>>>> I have posted this question (username-scryptkiddy) in the forums: > >>>>> http://forums.freebsd.org/**showthread.php?t=41875< > http://forums.freebsd.org/showthread.php?t=41875> > >>>>> but was suggested to bring it here to the mailing list for > discussion. > >>>>> > >>>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were > >>>>> inspected by a security team and they had issues with FreeBSD's > memory > >>>>> management. > >>>>> > >>>>> Namely the transient memory and object reuse areas of FreeBSD. They > >>>>> claimed > >>>>> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation > >>>>> completed, > >>>>> and therefore was vulnerable to the Transient memory problem. > >>>>> > >>>> Any system that uses malloc will have difficulties with this as most > >>>> versions of free will not zero out the memory... You could make > >>>> modifications to kernel malloc to always zero memory on free, and > turn on > >>>> the junk feature of jemalloc and that could possibly close this issue > >>>> for them... > >>>> > >>>> Our higher ups need some sort of documentation / testing that can be > >>>>> used > >>>>> to counter this, since changing Operating Systems is not something we > >>>>> have > >>>>> time / manpower to do, but might have too based on this supposed > >>>>> 'finding'. > >>>>> > >>>>> The post has all the details. Let me know I need to repost in this as > >>>>> well. > >>>>> > >>>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for > >>>> nCircle a number of years ago, and they got their products EAL3 > >>>> cerified. > >>>> > >>>> Link: > >>>> http://www.** > commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** > >>>> 20v1.0.pdf< > http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf > > > >>>> > >>>> It is possible someone else has received certification on a newer > >>>> version, > >>>> but I'm not aware of any at this time... > >>>> > >>>> -- > >>>> John-Mark Gurney Voice: +1 415 225 5579 > >>>> > >>>> "All that I will do, has been done, All that I have, has not." > >>>> > >>> > >>> > >> > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to " > freebsd-security-unsubscribe@freebsd.org" > > From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 20:05:43 2013 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 ESMTP id 23C23778; Thu, 12 Sep 2013 20:05:43 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D18EA2399; Thu, 12 Sep 2013 20:05:42 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id f4so317431oah.39 for ; Thu, 12 Sep 2013 13:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xvSzGh8lGcWeYQzbVBtno4A9EbkXwCLbwLvcsegyThM=; b=x8JYMh1sWVm6RyXrRy8fGNww2df8QC2L3Bx1oarYm+hQHB1Uf2w4TbGzDkKs7d9IRs dYO93sB5BMxAS+ZwpFxmgCcPjRhPgWLE5bjUvs7m0bQJHBJq6Ys3MCOV6wxOoOxYufVm MoK2Se2j5NCop/gD7DoNRnqySgnSub+77CwXbFJ3/QzeD0vrZNpjX6AzL8hLbVrHeGja pZVC/YkqVoaBON/jJBpk0Iy4fXXrQco9uU44599YYrTKLHWV82p9ikAgBW7z1KXccesE FgROCFYekwgE5ymSF5oBaqdHywesRANyaTNneSSc8XtlpxW1fewmzRO6ry3TvLTvt0Gx FKng== X-Received: by 10.182.22.226 with SMTP id h2mr8593488obf.8.1379016342190; Thu, 12 Sep 2013 13:05:42 -0700 (PDT) Received: from [172.22.132.60] ([192.119.231.58]) by mx.google.com with ESMTPSA id d3sm8258513oek.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 13:05:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: FreeBSD Transient Memory problem? From: Guy Helmer In-Reply-To: Date: Thu, 12 Sep 2013 15:05:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> To: Jonathon Wright X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 12 Sep 2013 21:36:44 +0000 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:05:43 -0000 On Sep 12, 2013, at 2:33 PM, Jonathon Wright = wrote: > I agree, really, I do. This is very frustrating to me. Unfortunately, = the > team has left and gone to another project. They indicated to our = management > that we had 90 days to address the issue with our plan. Its a bit = harder to > contact them now since they are gone, but I can probably get some = questions > to them. They did leave a copy of the report, here is the entire = verbiage: >=20 > ---BEGIN >=20 > *Description of Finding:* Object reuse cannot be verified. The FreeBSD > servers used have not been evaluated or certified by NIAP. As such, it > cannot be verified that the operating system ensures transient memory > cleansing (object reuse) features are in place. >=20 > *Rationale for Severity Code Determination:* The Validation team has > determined this to be a Category II finding. By using unapproved = Operating > Systems (OS) which do not ensure that no residual data from a former = object > exists, a malicious user could gain access to memory and OS objects = that > contain sensitive information. >=20 > *Recommended Countermeasure(s):* Transition servers to an NIAP = approved OS. > Decommission the FreeBSD servers. > ---END >=20 > What I think they are looking for is a verification that every malloc = has a > call to free afterwords that zeros out the memory used. I could be = wrong, > but just a guess. >=20 > JW Two common forms of object reuse are in memory allocation to a process = and in blocks allocated to a file. As far as I understand the issue, = malloc/free within a single process would not be a relevant concern = (generally, only inter-process activity crosses security boundaries). A = malloc that causes VM pages to be assigned to the process by the kernel, = or file writes that cause blocks to be allocated to a file, would be the = among the relevant issues. Unfortunately, as I'm not a VM or FS guru, I = can't point to particular points in the kernel source that show that = memory is zeroed when allocated to a new process, or blocks are zeroed = when allocated to a file. However, this is fundamental to secure = operation of any modern system, and if there is *any* evidence that = FreeBSD operates to the contrary, it would be worthy of a security = advisory (witness the sendfile() security advisory from earlier this = week). I don't have a copy of "Design and Implementation of FreeBSD" handy, but = I would imagine it points out the relevant code paths. However, it seems = your management wants evidence of EAL certification, not evidence from = code. Perhaps you can borrow such certification from nCircle or others. Guy > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer = wrote: >=20 >> On 9/13/13 1:49 AM, My Email wrote: >>=20 >>> My apologies, I have been replying too all, I hope that is the = correct >>> method. >>>=20 >>> Anyway, that is very interesting information. I'd be extremely = interested >>> in information on customizing malloc and jemalloc. Let me know where = to >>> start. Thanks! >>>=20 >>=20 >> it's hard to know how to refute it because they don't explain WHAT = memory >> they are talking about. >> there is NO OS in the world that can survive that test if they are = talking >> about protection from a malware kernel module. >> On the other hand if they are just talking about user memory = allocation >> then of course we NEVER hand uncleared memory to anyone. (even root). = Ask >> them to tell you what memory they are talking about.. >> and if they want free memory in the pool to be clear then it wouldn't = take >> much to >> add a module that zeros non vnode memory when it's handed back to the >> kernel. >>=20 >> But for all we know they are talking about people stealing punch = cards and >> photographing them.. >>=20 >> JW >>>=20 >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney = wrote: >>>=20 >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 = -1000: >>>>=20 >>>>> I have posted this question (username-scryptkiddy) in the forums: >>>>> = http://forums.freebsd.org/**showthread.php?t=3D41875 >>>>> but was suggested to bring it here to the mailing list for = discussion. >>>>>=20 >>>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were >>>>> inspected by a security team and they had issues with FreeBSD's = memory >>>>> management. >>>>>=20 >>>>> Namely the transient memory and object reuse areas of FreeBSD. = They >>>>> claimed >>>>> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation >>>>> completed, >>>>> and therefore was vulnerable to the Transient memory problem. >>>>>=20 >>>> Any system that uses malloc will have difficulties with this as = most >>>> versions of free will not zero out the memory... You could make >>>> modifications to kernel malloc to always zero memory on free, and = turn on >>>> the junk feature of jemalloc and that could possibly close this = issue >>>> for them... >>>>=20 >>>> Our higher ups need some sort of documentation / testing that can = be >>>>> used >>>>> to counter this, since changing Operating Systems is not something = we >>>>> have >>>>> time / manpower to do, but might have too based on this supposed >>>>> 'finding'. >>>>>=20 >>>>> The post has all the details. Let me know I need to repost in this = as >>>>> well. >>>>>=20 >>>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked = for >>>> nCircle a number of years ago, and they got their products EAL3 >>>> cerified. >>>>=20 >>>> Link: >>>> = http://www.**commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** >>>> = 20v1.0.pdf >>>>=20 >>>> It is possible someone else has received certification on a newer >>>> version, >>>> but I'm not aware of any at this time... >>>>=20 >>>> -- >>>> John-Mark Gurney Voice: +1 415 225 5579 >>>>=20 >>>> "All that I will do, has been done, All that I have, has not." >>>>=20 >>>=20 >>>=20 >>=20 > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 22:22:50 2013 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 ESMTP id 0939B42C; Thu, 12 Sep 2013 22:22:50 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D27022C8A; Thu, 12 Sep 2013 22:22:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r8CMMmkt004439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 15:22:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8CMMmgf004438; Thu, 12 Sep 2013 15:22:48 -0700 (PDT) (envelope-from jmg) Date: Thu, 12 Sep 2013 15:22:48 -0700 From: John-Mark Gurney To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? Message-ID: <20130912222248.GO68682@funkthat.com> Mail-Followup-To: Jonathon Wright , Guy Helmer , Julian Elischer , "freebsd-security@freebsd.org" References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 12 Sep 2013 15:22:49 -0700 (PDT) Cc: "freebsd-security@freebsd.org" , Guy Helmer , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:22:50 -0000 Jonathon Wright wrote this message on Thu, Sep 12, 2013 at 10:33 -1000: > Do you have a link to nCircle or site (my GoogleFu is not very strong, I > only got tripwire hits) nCircle was purchased earlier this year by Tripwire, hence why you only get tripwire hits now. Link: http://www.tripwire.com/company/news/press-release/tripwire-inc-acquires-ncircle/ > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer wrote: > > > On Sep 12, 2013, at 2:33 PM, Jonathon Wright > > wrote: > > > > > I agree, really, I do. This is very frustrating to me. Unfortunately, the > > > team has left and gone to another project. They indicated to our > > management > > > that we had 90 days to address the issue with our plan. Its a bit harder > > to > > > contact them now since they are gone, but I can probably get some > > questions > > > to them. They did leave a copy of the report, here is the entire > > verbiage: > > > > > > ---BEGIN > > > > > > *Description of Finding:* Object reuse cannot be verified. The FreeBSD > > > servers used have not been evaluated or certified by NIAP. As such, it > > > cannot be verified that the operating system ensures transient memory > > > cleansing (object reuse) features are in place. > > > > > > *Rationale for Severity Code Determination:* The Validation team has > > > determined this to be a Category II finding. By using unapproved > > Operating > > > Systems (OS) which do not ensure that no residual data from a former > > object > > > exists, a malicious user could gain access to memory and OS objects that > > > contain sensitive information. > > > > > > *Recommended Countermeasure(s):* Transition servers to an NIAP approved > > OS. > > > Decommission the FreeBSD servers. > > > ---END > > > > > > What I think they are looking for is a verification that every malloc > > has a > > > call to free afterwords that zeros out the memory used. I could be wrong, > > > but just a guess. > > > > > > JW > > > > Two common forms of object reuse are in memory allocation to a process and > > in blocks allocated to a file. As far as I understand the issue, > > malloc/free within a single process would not be a relevant concern > > (generally, only inter-process activity crosses security boundaries). A > > malloc that causes VM pages to be assigned to the process by the kernel, or > > file writes that cause blocks to be allocated to a file, would be the among > > the relevant issues. Unfortunately, as I'm not a VM or FS guru, I can't > > point to particular points in the kernel source that show that memory is > > zeroed when allocated to a new process, or blocks are zeroed when allocated > > to a file. However, this is fundamental to secure operation of any modern > > system, and if there is *any* evidence that FreeBSD operates to the > > contrary, it would be worthy of a security advisory (witness the sendfile() > > security advisory from earlier this week). > > > > I don't have a copy of "Design and Implementation of FreeBSD" handy, but I > > would imagine it points out the relevant code paths. However, it seems your > > management wants evidence of EAL certification, not evidence from code. > > Perhaps you can borrow such certification from nCircle or others. > > > > Guy > > > > > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer > > wrote: > > > > > >> On 9/13/13 1:49 AM, My Email wrote: > > >> > > >>> My apologies, I have been replying too all, I hope that is the correct > > >>> method. > > >>> > > >>> Anyway, that is very interesting information. I'd be extremely > > interested > > >>> in information on customizing malloc and jemalloc. Let me know where to > > >>> start. Thanks! > > >>> > > >> > > >> it's hard to know how to refute it because they don't explain WHAT > > memory > > >> they are talking about. > > >> there is NO OS in the world that can survive that test if they are > > talking > > >> about protection from a malware kernel module. > > >> On the other hand if they are just talking about user memory allocation > > >> then of course we NEVER hand uncleared memory to anyone. (even root). > > Ask > > >> them to tell you what memory they are talking about.. > > >> and if they want free memory in the pool to be clear then it wouldn't > > take > > >> much to > > >> add a module that zeros non vnode memory when it's handed back to the > > >> kernel. > > >> > > >> But for all we know they are talking about people stealing punch cards > > and > > >> photographing them.. > > >> > > >> JW > > >>> > > >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney > > wrote: > > >>> > > >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000: > > >>>> > > >>>>> I have posted this question (username-scryptkiddy) in the forums: > > >>>>> http://forums.freebsd.org/**showthread.php?t=41875< > > http://forums.freebsd.org/showthread.php?t=41875> > > >>>>> but was suggested to bring it here to the mailing list for > > discussion. > > >>>>> > > >>>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We were > > >>>>> inspected by a security team and they had issues with FreeBSD's > > memory > > >>>>> management. > > >>>>> > > >>>>> Namely the transient memory and object reuse areas of FreeBSD. They > > >>>>> claimed > > >>>>> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation > > >>>>> completed, > > >>>>> and therefore was vulnerable to the Transient memory problem. > > >>>>> > > >>>> Any system that uses malloc will have difficulties with this as most > > >>>> versions of free will not zero out the memory... You could make > > >>>> modifications to kernel malloc to always zero memory on free, and > > turn on > > >>>> the junk feature of jemalloc and that could possibly close this issue > > >>>> for them... > > >>>> > > >>>> Our higher ups need some sort of documentation / testing that can be > > >>>>> used > > >>>>> to counter this, since changing Operating Systems is not something we > > >>>>> have > > >>>>> time / manpower to do, but might have too based on this supposed > > >>>>> 'finding'. > > >>>>> > > >>>>> The post has all the details. Let me know I need to repost in this as > > >>>>> well. > > >>>>> > > >>>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I worked for > > >>>> nCircle a number of years ago, and they got their products EAL3 > > >>>> cerified. > > >>>> > > >>>> Link: > > >>>> http://www.** > > commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** > > >>>> 20v1.0.pdf< > > http://www.commoncriteriaportal.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf > > > > > >>>> > > >>>> It is possible someone else has received certification on a newer > > >>>> version, > > >>>> but I'm not aware of any at this time... > > >>>> > > >>>> -- > > >>>> John-Mark Gurney Voice: +1 415 225 5579 > > >>>> > > >>>> "All that I will do, has been done, All that I have, has not." > > >>>> > > >>> > > >>> > > >> > > > _______________________________________________ > > > freebsd-security@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > > To unsubscribe, send any mail to " > > freebsd-security-unsubscribe@freebsd.org" > > > > -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Thu Sep 12 22:17:11 2013 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 ESMTP id 2DAC5121; Thu, 12 Sep 2013 22:17:11 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6A362C20; Thu, 12 Sep 2013 22:17:10 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id vb8so424291obc.4 for ; Thu, 12 Sep 2013 15:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZFD6cPg4r7Pp9kABlDXfu6lffa9UY7NKufZBUfjRPw4=; b=cNoCAMPg7Mn6+U3GC4jCna//BXD+vSml3bZTQjzUjLEcgHLWek5NktDmc/70/NsXYA 5nRD/dF57ETzMd9x+jjmNOQES5eDrEROsFwW4/G+abicpJzYmR0/pWMsr8j3aiifxkWj AoXIBpFkO51UimuUB5ab5XEauPstn9WMILM55jJ7ZXV5MLrTexhbPgTdeLkyBdvRBnXr qQG6cAaimo8c0PERetK0i+AKWCZTehMl3r3YxClY/7Hp7fuzoYe2SNvNODXK1/GP5uhj vF/TKPm36wK7SQqcs1bJ4aQHCekvPbDvIZqC5nqhzstTo5j1P9veUco6hnYEzLbgFOv5 8bBA== X-Received: by 10.182.18.102 with SMTP id v6mr3686987obd.71.1379024229973; Thu, 12 Sep 2013 15:17:09 -0700 (PDT) Received: from [172.22.132.60] ([192.119.231.58]) by mx.google.com with ESMTPSA id j9sm9161914oef.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 15:17:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: FreeBSD Transient Memory problem? From: Guy Helmer In-Reply-To: Date: Thu, 12 Sep 2013 17:17:07 -0500 Message-Id: <8573B6D6-0285-4167-9800-9DFC249694DA@gmail.com> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> To: Jonathon Wright X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 12 Sep 2013 22:42:57 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:17:11 -0000 On Sep 12, 2013, at 3:33 PM, Jonathon Wright = wrote: > Thanks for those insights Guy. Makes sense that they are referring to = security boundaries (inter-process related) only. > =20 > I didn't get the reference (witness the sendmail() security advisory = earlier this week). Was there a reference to this issue in the one = earlier this week, and / or how do I view the security advisories? Security advisories are at = http://www.freebsd.org/security/advisories.html I believe I receive them on the lists freebsd-announce, = freebsd-security, and bugtraq (not a FreeBSD list). The sendfile advisory this week = (http://www.freebsd.org/security/advisories/FreeBSD-SA-13:11.sendfile.asc)= was about information disclosure as the result of issuing a sendfile() = for a length greater than the length of the file. I see other = information disclosure vulnerabilities, one in pipes = (http://www.freebsd.org/security/advisories/FreeBSD-SA-09:09.pipe.asc = and a prior one = http://www.freebsd.org/security/advisories/FreeBSD-SA-05:02.sendfile.asc),= one in firewire = (http://www.freebsd.org/security/advisories/FreeBSD-SA-06:25.kmem.asc) = and probably a couple of others I don't remember.=20 Point being: the project takes information disclosure issues very = seriously. > As far as the book, I am trying to find an online version that I can = copy / paste out the section that would talk about this. > I did go back to the teams local rep who is simply "tracking" the = item. He stated that the "proof" would preferrably be an EAL cert, but = verbiage in that book or other "formal" documenation would be = considered. > =20 > So few questions: > Do you know where I can get the book in an online copy? I'm not sure -- maybe Amazon? > Do you have a link to nCircle or site (my GoogleFu is not very strong, = I only got tripwire hits) Not sure about this either - sorry. Hope this helps, Guy > =20 > Thanks > =20 >=20 >=20 > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer = wrote: > On Sep 12, 2013, at 2:33 PM, Jonathon Wright = wrote: >=20 > > I agree, really, I do. This is very frustrating to me. = Unfortunately, the > > team has left and gone to another project. They indicated to our = management > > that we had 90 days to address the issue with our plan. Its a bit = harder to > > contact them now since they are gone, but I can probably get some = questions > > to them. They did leave a copy of the report, here is the entire = verbiage: > > > > ---BEGIN > > > > *Description of Finding:* Object reuse cannot be verified. The = FreeBSD > > servers used have not been evaluated or certified by NIAP. As such, = it > > cannot be verified that the operating system ensures transient = memory > > cleansing (object reuse) features are in place. > > > > *Rationale for Severity Code Determination:* The Validation team has > > determined this to be a Category II finding. By using unapproved = Operating > > Systems (OS) which do not ensure that no residual data from a former = object > > exists, a malicious user could gain access to memory and OS objects = that > > contain sensitive information. > > > > *Recommended Countermeasure(s):* Transition servers to an NIAP = approved OS. > > Decommission the FreeBSD servers. > > ---END > > > > What I think they are looking for is a verification that every = malloc has a > > call to free afterwords that zeros out the memory used. I could be = wrong, > > but just a guess. > > > > JW >=20 > Two common forms of object reuse are in memory allocation to a process = and in blocks allocated to a file. As far as I understand the issue, = malloc/free within a single process would not be a relevant concern = (generally, only inter-process activity crosses security boundaries). A = malloc that causes VM pages to be assigned to the process by the kernel, = or file writes that cause blocks to be allocated to a file, would be the = among the relevant issues. Unfortunately, as I'm not a VM or FS guru, I = can't point to particular points in the kernel source that show that = memory is zeroed when allocated to a new process, or blocks are zeroed = when allocated to a file. However, this is fundamental to secure = operation of any modern system, and if there is *any* evidence that = FreeBSD operates to the contrary, it would be worthy of a security = advisory (witness the sendfile() security advisory from earlier this = week). >=20 > I don't have a copy of "Design and Implementation of FreeBSD" handy, = but I would imagine it points out the relevant code paths. However, it = seems your management wants evidence of EAL certification, not evidence = from code. Perhaps you can borrow such certification from nCircle or = others. >=20 > Guy >=20 > > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer = wrote: > > > >> On 9/13/13 1:49 AM, My Email wrote: > >> > >>> My apologies, I have been replying too all, I hope that is the = correct > >>> method. > >>> > >>> Anyway, that is very interesting information. I'd be extremely = interested > >>> in information on customizing malloc and jemalloc. Let me know = where to > >>> start. Thanks! > >>> > >> > >> it's hard to know how to refute it because they don't explain WHAT = memory > >> they are talking about. > >> there is NO OS in the world that can survive that test if they are = talking > >> about protection from a malware kernel module. > >> On the other hand if they are just talking about user memory = allocation > >> then of course we NEVER hand uncleared memory to anyone. (even = root). Ask > >> them to tell you what memory they are talking about.. > >> and if they want free memory in the pool to be clear then it = wouldn't take > >> much to > >> add a module that zeros non vnode memory when it's handed back to = the > >> kernel. > >> > >> But for all we know they are talking about people stealing punch = cards and > >> photographing them.. > >> > >> JW > >>> > >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney = wrote: > >>> > >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 = -1000: > >>>> > >>>>> I have posted this question (username-scryptkiddy) in the = forums: > >>>>> = http://forums.freebsd.org/**showthread.php?t=3D41875 > >>>>> but was suggested to bring it here to the mailing list for = discussion. > >>>>> > >>>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. We = were > >>>>> inspected by a security team and they had issues with FreeBSD's = memory > >>>>> management. > >>>>> > >>>>> Namely the transient memory and object reuse areas of FreeBSD. = They > >>>>> claimed > >>>>> that FreeBSD did not have a Common Criteria (EAL1-4) evaluation > >>>>> completed, > >>>>> and therefore was vulnerable to the Transient memory problem. > >>>>> > >>>> Any system that uses malloc will have difficulties with this as = most > >>>> versions of free will not zero out the memory... You could make > >>>> modifications to kernel malloc to always zero memory on free, and = turn on > >>>> the junk feature of jemalloc and that could possibly close this = issue > >>>> for them... > >>>> > >>>> Our higher ups need some sort of documentation / testing that = can be > >>>>> used > >>>>> to counter this, since changing Operating Systems is not = something we > >>>>> have > >>>>> time / manpower to do, but might have too based on this supposed > >>>>> 'finding'. > >>>>> > >>>>> The post has all the details. Let me know I need to repost in = this as > >>>>> well. > >>>>> > >>>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I = worked for > >>>> nCircle a number of years ago, and they got their products EAL3 > >>>> cerified. > >>>> > >>>> Link: > >>>> = http://www.**commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** > >>>> = 20v1.0.pdf > >>>> > >>>> It is possible someone else has received certification on a newer > >>>> version, > >>>> but I'm not aware of any at this time... > >>>> > >>>> -- > >>>> John-Mark Gurney Voice: +1 415 225 5579 > >>>> > >>>> "All that I will do, has been done, All that I have, has = not." > >>>> > >>> > >>> > >> > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to = "freebsd-security-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 00:40:14 2013 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 ESMTP id D1ABD50D; Fri, 13 Sep 2013 00:40:14 +0000 (UTC) (envelope-from brett@lariat.org) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 781A929C9; Fri, 13 Sep 2013 00:40:14 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id SAA28208; Thu, 12 Sep 2013 18:40:05 -0600 (MDT) Message-Id: <201309130040.SAA28208@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Sep 2013 18:39:13 -0600 To: Jonathon Wright , Guy Helmer From: Brett Glass Subject: Re: FreeBSD Transient Memory problem? In-Reply-To: References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 00:40:14 -0000 One other point of possible interest which points out how silly this whole thing is. While the NIAP Web site does not list FreeBSD as a "compliant" operating system product, it lists Juniper routers, which run an embedded version of FreeBSD, as compliant. See https://www.niap-ccevs.org/CCEVS_Products/pcl.cfm?tech_name=Router There may be other products which have "FreeBSD inside" on their list as well. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 00:47:53 2013 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 ESMTP id 0B8C383B; Fri, 13 Sep 2013 00:47:53 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AADDF2A4E; Fri, 13 Sep 2013 00:47:52 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hf12so462888vcb.27 for ; Thu, 12 Sep 2013 17:47:51 -0700 (PDT) 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=0ABESk9/kPdyKo2zHMB6LGKXmIjY++B6GOxXTBmwSCs=; b=sfX3M83SegmqNpQRE/khlDHnEFaSCR6cuGablJu/rhhun5W+Uff/hh0Vu+KAPkb/ND oRTWib1nKUM3++SJasuz8jWoFwGXDD9fHgx0m2vfH1H5qoQMOaYY668ja9wUqfEPcaQp gUw+MtaB4LJwAb8A+xgfVdRLgZ5/EovkFXe6D8saNAHJz15laVQLHEvowhL4XrxQcy7c 33bA94pg1bFDaeY569G30aNUFtXkj7wu6DsTxiuTYmTAjIh525UA0gGl3EVZP6ZUWEVP nP8MV9TfzcwwwE5h3PS8sMp6izS036qa2oQBuW8BTQ0iMJfaB3wP/INkAs20avMqY2WJ WZQg== MIME-Version: 1.0 X-Received: by 10.52.27.243 with SMTP id w19mr4232534vdg.3.1379033271739; Thu, 12 Sep 2013 17:47:51 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Thu, 12 Sep 2013 17:47:51 -0700 (PDT) In-Reply-To: <201309130040.SAA28208@mail.lariat.net> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309130040.SAA28208@mail.lariat.net> Date: Thu, 12 Sep 2013 14:47:51 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Guy Helmer , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 00:47:53 -0000 Thanks Brett, That item just made it to the top of the argument list I'm formulating right now from everyone's input. =) That makes a very strong argument for the OS as "approved". On Thu, Sep 12, 2013 at 2:39 PM, Brett Glass wrote: > One other point of possible interest which points out how silly > this whole thing is. > > While the NIAP Web site does not list FreeBSD as a "compliant" > operating system product, it lists Juniper routers, which run an > embedded version of FreeBSD, as compliant. See > > https://www.niap-ccevs.org/**CCEVS_Products/pcl.cfm?tech_**name=Router > > There may be other products which have "FreeBSD inside" on their > list as well. > > --Brett Glass > > From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 00:54:10 2013 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 ESMTP id 10855A84; Fri, 13 Sep 2013 00:54:10 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 78CFB2AB4; Fri, 13 Sep 2013 00:54:09 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id f12so512126wgh.29 for ; Thu, 12 Sep 2013 17:54:07 -0700 (PDT) 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=b7Bl7TWvcZZtfQo0UcBYwWHQXWnsMRG6lHLe0hqmNCs=; b=emGrwsjwA9wP+2bhsPnkPz6Xarm/ExWa/VANabT1XVemyerMTRPXafbKi9R527xoTk +cBgO+eo0vINdw6k/qdFE2KgQYsuMbbKiN0JI9Xln+pAB33Q302nBhECgQZB/tb+aGC0 TOp9alc80hQ4flgUx+RuwvggNGFmX5PGnAhhYzQxh4Z+zk4JEhaz2Ki1k1lqQ1HkbRa3 3nYyY4XF3xvdLgUUzTJXfd+eaNi13lCih8403vmucKFezmRxLxIick0wMZp2xET/iEEA rHmbXv4zmrSJ4zucTizANF0Bb97T9d2iyh+wdivqN/sfdaC41IbRSObidHV0+pxVKMSk O3qw== MIME-Version: 1.0 X-Received: by 10.180.206.42 with SMTP id ll10mr402623wic.50.1379033647891; Thu, 12 Sep 2013 17:54:07 -0700 (PDT) Received: by 10.216.180.2 with HTTP; Thu, 12 Sep 2013 17:54:07 -0700 (PDT) In-Reply-To: References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309130040.SAA28208@mail.lariat.net> Date: Fri, 13 Sep 2013 03:54:07 +0300 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Kimmo Paasiala To: Jonathon Wright Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org" , Guy Helmer , Julian Elischer , John-Mark Gurney X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 00:54:10 -0000 On Fri, Sep 13, 2013 at 3:47 AM, Jonathon Wright wrote: > Thanks Brett, > > That item just made it to the top of the argument list I'm formulating > right now from everyone's input. =) > That makes a very strong argument for the OS as "approved". > > > On Thu, Sep 12, 2013 at 2:39 PM, Brett Glass wrote: > >> One other point of possible interest which points out how silly >> this whole thing is. >> >> While the NIAP Web site does not list FreeBSD as a "compliant" >> operating system product, it lists Juniper routers, which run an >> embedded version of FreeBSD, as compliant. See >> >> https://www.niap-ccevs.org/**CCEVS_Products/pcl.cfm?tech_**name=Router >> >> There may be other products which have "FreeBSD inside" on their >> list as well. >> >> --Brett Glass >> >> Unfortunately that might just mean that the company behind Juniper has payed enough money to get their product certified while basic FreeBSD remains uncertified. All this certification business is corruption if you ask me. -Kimmo From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 01:02:04 2013 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 ESMTP id 41647D92; Fri, 13 Sep 2013 01:02:04 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c: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 DDEFB2B4D; Fri, 13 Sep 2013 01:02:03 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so458235vcb.12 for ; Thu, 12 Sep 2013 18:02:03 -0700 (PDT) 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=tQcz5CKSUKyeSrBUApKVdhQe5gTMx6OgOxgBqDNAA4I=; b=hLvUCAxEsryfgSzxWCQBSZK2OBUBEr+RclRyZmzxB+AhpAio+kecF/si92h8erEJ1k /+neiXNc9/+ILqKzCwUSUkvTPkXNAjys8TG+b/nPZujFGa3Wk+8jwi0TkQ2qJ11dj3nV Gg5bA78gdtjO1+dz0eo6NC7y2ccoe+wSpjnjnLL9HLOpD6AJEcvalC2LTxfw/svusps3 ewT5GNk7dl5YwSJ6D0MwBMtis/Nyqevgb+wz8Gstr1CboHhLTBhSqGd364ybkSHfo5Tj s4M/82T4mPlE3076YPYAa5gHaXgym+fhWlx5oEAtaMJ7JzaNod3bJFHfkvDgBC0EBiWt 2nnQ== MIME-Version: 1.0 X-Received: by 10.220.145.132 with SMTP id d4mr9215368vcv.9.1379034122933; Thu, 12 Sep 2013 18:02:02 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Thu, 12 Sep 2013 18:02:02 -0700 (PDT) In-Reply-To: References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309130040.SAA28208@mail.lariat.net> Date: Thu, 12 Sep 2013 15:02:02 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , Guy Helmer , Julian Elischer , John-Mark Gurney X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 01:02:04 -0000 I agree Kimmo, Its much like the certification of professionals. I had to get 4-5 certs just to keep my job, regardless if I knew how to do it or not. We even lost people who were fired because they could not get the certs, yet had been doing the job for a very long time. ...its a paper, nothing more to me. On Thu, Sep 12, 2013 at 2:54 PM, Kimmo Paasiala wrote: > On Fri, Sep 13, 2013 at 3:47 AM, Jonathon Wright > wrote: > > Thanks Brett, > > > > That item just made it to the top of the argument list I'm formulating > > right now from everyone's input. =) > > That makes a very strong argument for the OS as "approved". > > > > > > On Thu, Sep 12, 2013 at 2:39 PM, Brett Glass wrote: > > > >> One other point of possible interest which points out how silly > >> this whole thing is. > >> > >> While the NIAP Web site does not list FreeBSD as a "compliant" > >> operating system product, it lists Juniper routers, which run an > >> embedded version of FreeBSD, as compliant. See > >> > >> https://www.niap-ccevs.org/**CCEVS_Products/pcl.cfm?tech_**name=Router< > https://www.niap-ccevs.org/CCEVS_Products/pcl.cfm?tech_name=Router> > >> > >> There may be other products which have "FreeBSD inside" on their > >> list as well. > >> > >> --Brett Glass > >> > >> > > Unfortunately that might just mean that the company behind Juniper has > payed enough money to get their product certified while basic FreeBSD > remains uncertified. All this certification business is corruption if > you ask me. > > > -Kimmo > From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 04:21:11 2013 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 ESMTP id ED82451C for ; Fri, 13 Sep 2013 04:21:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 A56612484 for ; Fri, 13 Sep 2013 04:21:11 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r8D4L5wX085775 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 21:21:08 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <523292AC.1050907@freebsd.org> Date: Fri, 13 Sep 2013 12:21:00 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Guy Helmer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 04:21:12 -0000 On 9/13/13 4:33 AM, Jonathon Wright wrote: > Thanks for those insights Guy. Makes sense that they are referring > to security boundaries (inter-process related) only. what's the name of the "security" company? maybe we can publicly lambast them as idiots on slashdot. > I didn't get the reference (witness the sendmail() security advisory > earlier this week). Was there a reference to this issue in the one > earlier this week, and / or how do I view the security advisories? > As far as the book, I am trying to find an online version that I can > copy / paste out the section that would talk about this. > I did go back to the teams local rep who is simply "tracking" the > item. He stated that the "proof" would preferrably be an EAL cert, > but verbiage in that book or other "formal" documenation would be > considered. > So few questions: > Do you know where I can get the book in an online copy? > Do you have a link to nCircle or site (my GoogleFu is not very > strong, I only got tripwire hits) > Thanks > > > On Thu, Sep 12, 2013 at 10:05 AM, Guy Helmer > wrote: > > On Sep 12, 2013, at 2:33 PM, Jonathon Wright > > wrote: > > > I agree, really, I do. This is very frustrating to me. > Unfortunately, the > > team has left and gone to another project. They indicated to > our management > > that we had 90 days to address the issue with our plan. Its a > bit harder to > > contact them now since they are gone, but I can probably get > some questions > > to them. They did leave a copy of the report, here is the > entire verbiage: > > > > ---BEGIN > > > > *Description of Finding:* Object reuse cannot be verified. The > FreeBSD > > servers used have not been evaluated or certified by NIAP. As > such, it > > cannot be verified that the operating system ensures transient > memory > > cleansing (object reuse) features are in place. > > > > *Rationale for Severity Code Determination:* The Validation > team has > > determined this to be a Category II finding. By using > unapproved Operating > > Systems (OS) which do not ensure that no residual data from a > former object > > exists, a malicious user could gain access to memory and OS > objects that > > contain sensitive information. > > > > *Recommended Countermeasure(s):* Transition servers to an NIAP > approved OS. > > Decommission the FreeBSD servers. > > ---END > > > > What I think they are looking for is a verification that every > malloc has a > > call to free afterwords that zeros out the memory used. I > could be wrong, > > but just a guess. > > > > JW > > Two common forms of object reuse are in memory allocation to a > process and in blocks allocated to a file. As far as I > understand the issue, malloc/free within a single process would > not be a relevant concern (generally, only inter-process > activity crosses security boundaries). A malloc that causes VM > pages to be assigned to the process by the kernel, or file > writes that cause blocks to be allocated to a file, would be the > among the relevant issues. Unfortunately, as I'm not a VM or FS > guru, I can't point to particular points in the kernel source > that show that memory is zeroed when allocated to a new process, > or blocks are zeroed when allocated to a file. However, this is > fundamental to secure operation of any modern system, and if > there is *any* evidence that FreeBSD operates to the contrary, > it would be worthy of a security advisory (witness the > sendfile() security advisory from earlier this week). > > I don't have a copy of "Design and Implementation of FreeBSD" > handy, but I would imagine it points out the relevant code > paths. However, it seems your management wants evidence of EAL > certification, not evidence from code. Perhaps you can borrow > such certification from nCircle or others. > > Guy > > > On Thu, Sep 12, 2013 at 8:00 AM, Julian Elischer > > wrote: > > > >> On 9/13/13 1:49 AM, My Email wrote: > >> > >>> My apologies, I have been replying too all, I hope that is > the correct > >>> method. > >>> > >>> Anyway, that is very interesting information. I'd be > extremely interested > >>> in information on customizing malloc and jemalloc. Let me > know where to > >>> start. Thanks! > >>> > >> > >> it's hard to know how to refute it because they don't explain > WHAT memory > >> they are talking about. > >> there is NO OS in the world that can survive that test if > they are talking > >> about protection from a malware kernel module. > >> On the other hand if they are just talking about user memory > allocation > >> then of course we NEVER hand uncleared memory to anyone. > (even root). Ask > >> them to tell you what memory they are talking about.. > >> and if they want free memory in the pool to be clear then it > wouldn't take > >> much to > >> add a module that zeros non vnode memory when it's handed > back to the > >> kernel. > >> > >> But for all we know they are talking about people stealing > punch cards and > >> photographing them.. > >> > >> JW > >>> > >>> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney > > wrote: > >>> > >>> Jonathon Wright wrote this message on Wed, Sep 11, 2013 at > 14:15 -1000: > >>>> > >>>>> I have posted this question (username-scryptkiddy) in the > forums: > >>>>> > http://forums.freebsd.org/**showthread.php?t=41875 > >>>>> but was suggested to bring it here to the mailing list for > discussion. > >>>>> > >>>>> Basically, FreeBSD 8.3 (64bit) is what we use in our shop. > We were > >>>>> inspected by a security team and they had issues with > FreeBSD's memory > >>>>> management. > >>>>> > >>>>> Namely the transient memory and object reuse areas of > FreeBSD. They > >>>>> claimed > >>>>> that FreeBSD did not have a Common Criteria (EAL1-4) > evaluation > >>>>> completed, > >>>>> and therefore was vulnerable to the Transient memory problem. > >>>>> > >>>> Any system that uses malloc will have difficulties with > this as most > >>>> versions of free will not zero out the memory... You could > make > >>>> modifications to kernel malloc to always zero memory on > free, and turn on > >>>> the junk feature of jemalloc and that could possibly close > this issue > >>>> for them... > >>>> > >>>> Our higher ups need some sort of documentation / testing > that can be > >>>>> used > >>>>> to counter this, since changing Operating Systems is not > something we > >>>>> have > >>>>> time / manpower to do, but might have too based on this > supposed > >>>>> 'finding'. > >>>>> > >>>>> The post has all the details. Let me know I need to repost > in this as > >>>>> well. > >>>>> > >>>> I know that FreeBSD 4.7 and 4.9 has been EAL3 ceritfied. I > worked for > >>>> nCircle a number of years ago, and they got their products EAL3 > >>>> cerified. > >>>> > >>>> Link: > >>>> > http://www.**commoncriteriaportal.org:80/**files/epfiles/nCircle%20CR%** > > >>>> > 20v1.0.pdf > >>>> > >>>> It is possible someone else has received certification on a > newer > >>>> version, > >>>> but I'm not aware of any at this time... > >>>> > >>>> -- > >>>> John-Mark Gurney Voice: +1 415 225 5579 > > >>>> > >>>> "All that I will do, has been done, All that I have, > has not." > >>>> > >>> > >>> > >> > > _______________________________________________ > > freebsd-security@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org > " > > From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 05:18:52 2013 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 ESMTP id 82F05BA2; Fri, 13 Sep 2013 05:18:52 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 41D7326E5; Fri, 13 Sep 2013 05:18:51 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e570:39d1:5fba:531f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id D8F8D4AC57; Fri, 13 Sep 2013 09:18:43 +0400 (MSK) Date: Fri, 13 Sep 2013 09:18:35 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1458963304.20130913091835@serebryakov.spb.ru> To: Julian Elischer Subject: Re: FreeBSD Transient Memory problem? In-Reply-To: <5231D461.5050504@freebsd.org> References: <5231D461.5050504@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 05:18:52 -0000 Hello, Julian. You wrote 12 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 18:49:05: JE> Pretty much all they've proved to me is that they have no idea of what JE> they are talking about. JE> You need to ask them for a better description of the problem as so far= =20 JE> all you've JE> seen is about a hundred computer science professionals rolling around= =20 JE> on the floor JE> laughing when you showed them the paragraph from the report.. JE> and you can quote me on that one. In my expirience, "Security audit" people, who could, for example, do PCI/DSS audit, are like this. So, yet, it is their level of competence, but you could not pass around them, if you want official PCI/DSS certification, for example. Did you seen this epic thread on stackoverflow (or its devops/sysops counterpart) about "log file with every login of each user with password in clear text,'' for example? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 07:27:30 2013 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 ESMTP id 057F73CB for ; Fri, 13 Sep 2013 07:27:30 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from fw.ax.cz (fw.ax.cz [IPv6:2a00:1aa8:1:1000::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 817BC2CBB for ; Fri, 13 Sep 2013 07:27:28 +0000 (UTC) Received: from [127.0.0.1] (host10.hide.ax.cz [172.20.1.29]) by fw.ax.cz (8.14.5/8.14.5) with ESMTP id r8D7Qkct079338; Fri, 13 Sep 2013 09:26:47 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <5232BE53.4040900@obluda.cz> Date: Fri, 13 Sep 2013 09:27:15 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309130040.SAA28208@mail.lariat.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130912-1, 12.09.2013), Outbound message X-Antivirus-Status: Clean Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:27:30 -0000 Kimmo Paasiala wrote: >> While the NIAP Web site does not list FreeBSD as a "compliant" >>> operating system product, it lists Juniper routers, which run an >>> embedded version of FreeBSD, as compliant. See > Unfortunately that might just mean that the company behind Juniper has > payed enough money to get their product certified while basic FreeBSD > remains uncertified. Sure. But there are other aspects as well. Juniper's FreeBSD has been verified (whatever it mean in such particular case) as installed inside such router - e.g. version, patch level, kernel compilation options, loaded kernel modules, ... In short, results of security audit of FreeBSD 9.1-R-p2 compiled without if_re module is not applicable to FreeBSD 9.1-R-p3 compiled with if_re module nor to FreeBSD 9.1-R-p3 compiled without if_re module Dan From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 10:17:36 2013 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 ESMTP id 47F46566; Fri, 13 Sep 2013 10:17:36 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 07C2E26E0; Fri, 13 Sep 2013 10:17:35 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D8B514D5B; Fri, 13 Sep 2013 10:17:34 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id CB6163687B; Fri, 13 Sep 2013 12:17:06 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Lev Serebryakov Subject: Re: FreeBSD Transient Memory problem? References: <5231D461.5050504@freebsd.org> <1458963304.20130913091835@serebryakov.spb.ru> Date: Fri, 13 Sep 2013 12:17:06 +0200 In-Reply-To: <1458963304.20130913091835@serebryakov.spb.ru> (Lev Serebryakov's message of "Fri, 13 Sep 2013 09:18:35 +0400") Message-ID: <86k3il58m5.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, Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 10:17:36 -0000 Lev Serebryakov writes: > In my expirience, "Security audit" people, who could, for example, do > PCI/DSS audit, are like this. So, yet, it is their level of > competence, but you could not pass around them, if you want official > PCI/DSS certification, for example. Did you seen this epic thread on > stackoverflow (or its devops/sysops counterpart) about "log file with > every login of each user with password in clear text,'' for example? That was the first thing that sprung to my mind as well. scryptkiddy, you should tell them to read this: http://serverfault.com/questions/293217/our-security-auditor-is-an-idiot-ho= w-do-i-give-him-the-information-he-wants I've been in a similar situation myself. The JITC audited a customer's product for IPv6 compliance and failed it because it did not put an ICMP destination unreachable on the wire when neighbor discovery failed. Note that the RFC *explicitly states* (but not in a normative section) that this is not required when the error occurs on the originating node. (the product in question did not run FreeBSD, but used an old version of the FreeBSD IPv6 stack) They had other idiotic requirements that we were able to work around, and found one genuine but benign bug that had already been fixed in FreeBSD. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 10:24:59 2013 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 ESMTP id A00F98AB for ; Fri, 13 Sep 2013 10:24:59 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 61E552750 for ; Fri, 13 Sep 2013 10:24:59 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 7EC344D7B; Fri, 13 Sep 2013 10:24:58 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 7F2593688F; Fri, 13 Sep 2013 12:24:30 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: My Email Subject: Re: FreeBSD Transient Memory problem? References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <20130912183206.GK68682@funkthat.com> Date: Fri, 13 Sep 2013 12:24:30 +0200 In-Reply-To: <20130912183206.GK68682@funkthat.com> (John-Mark Gurney's message of "Thu, 12 Sep 2013 11:32:07 -0700") Message-ID: <86d2od589t.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" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 10:24:59 -0000 John-Mark Gurney writes: > for kernel malloc, look at sys/kern_malloc.c.. It doesn't look like > there is a knob to turn on kernel malloc filling, but it wouldn't be > hard... You want to do it in UMA, not in malloc() / free(). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 10:26:22 2013 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 ESMTP id 3890599C; Fri, 13 Sep 2013 10:26:22 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EC17F276D; Fri, 13 Sep 2013 10:26:21 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 259574D81; Fri, 13 Sep 2013 10:26:21 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2D1AE36893; Fri, 13 Sep 2013 12:26:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Lev Serebryakov Subject: Re: FreeBSD Transient Memory problem? References: <5231D461.5050504@freebsd.org> <1458963304.20130913091835@serebryakov.spb.ru> <86k3il58m5.fsf@nine.des.no> Date: Fri, 13 Sep 2013 12:26:23 +0200 In-Reply-To: <86k3il58m5.fsf@nine.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8r?= =?utf-8?Q?grav=22's?= message of "Fri, 13 Sep 2013 12:17:06 +0200") Message-ID: <868uz1586o.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, Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 10:26:22 -0000 Dag-Erling Sm=C3=B8rgrav writes: > scryptkiddy, you should tell them to read this: s/scryptkiddy/Jonathon/ - I didn't have the entire thread in scope and couldn't find your name. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 16:12:08 2013 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 ESMTP id E177576E for ; Fri, 13 Sep 2013 16:12:08 +0000 (UTC) (envelope-from brett@lariat.org) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 966202C2C for ; Fri, 13 Sep 2013 16:12:07 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id KAA09855; Fri, 13 Sep 2013 10:11:53 -0600 (MDT) Message-Id: <201309131611.KAA09855@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Sep 2013 05:47:13 -0600 To: Dan Lukes , Jonathon Wright From: Brett Glass Subject: Re: FreeBSD Transient Memory problem? In-Reply-To: <5232BE53.4040900@obluda.cz> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309130040.SAA28208@mail.lariat.net> <5232BE53.4040900@obluda.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:12:08 -0000 At 01:27 AM 9/13/2013, Dan Lukes wrote: >Juniper's FreeBSD has been verified (whatever it mean in such particular >case) as installed inside such router - e.g. version, patch level, >kernel compilation options, loaded kernel modules, ... > >In short, results of security audit of FreeBSD 9.1-R-p2 compiled without >if_re module is not applicable to FreeBSD 9.1-R-p3 compiled with if_re >module nor to FreeBSD 9.1-R-p3 compiled without if_re module True, but the details of memory allocation and scrubbing are unlikely to change. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 16:46:51 2013 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 ESMTP id EB7DBDFA for ; Fri, 13 Sep 2013 16:46:51 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3E992E07 for ; Fri, 13 Sep 2013 16:46:51 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r8DGklfZ018402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 09:46:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8DGklo4018401; Fri, 13 Sep 2013 09:46:47 -0700 (PDT) (envelope-from jmg) Date: Fri, 13 Sep 2013 09:46:47 -0700 From: John-Mark Gurney To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: FreeBSD Transient Memory problem? Message-ID: <20130913164647.GR68682@funkthat.com> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , My Email , "freebsd-security@freebsd.org" References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <20130912183206.GK68682@funkthat.com> <86d2od589t.fsf@nine.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d2od589t.fsf@nine.des.no> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 13 Sep 2013 09:46:48 -0700 (PDT) Cc: My Email , "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:46:52 -0000 Dag-Erling Smrgrav wrote this message on Fri, Sep 13, 2013 at 12:24 +0200: > John-Mark Gurney writes: > > for kernel malloc, look at sys/kern_malloc.c.. It doesn't look like > > there is a knob to turn on kernel malloc filling, but it wouldn't be > > hard... > > You want to do it in UMA, not in malloc() / free(). The reason I didn't suggest UMA is that UMA already has functions that do the cleaning when destroying an object... You can't just zero UMA objects on free w/o calling fini, otherwise you might leak resources.. Plus, it would be a lot of work to fix all the UMA consumers to make sure that their uminit/fini fuctions do the proper cleaning necessary... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 16:47:24 2013 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 ESMTP id 6D8CCEE3; Fri, 13 Sep 2013 16:47:24 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (unknown [IPv6:2001:470:8:162::1]) (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 393DF2E23; Fri, 13 Sep 2013 16:47:24 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VKWWc-000MWQ-LR; Fri, 13 Sep 2013 12:47:18 -0400 Date: Fri, 13 Sep 2013 12:47:18 -0400 From: Gary Palmer To: Jonathon Wright Subject: Re: FreeBSD Transient Memory problem? Message-ID: <20130913164718.GC33898@in-addr.com> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:47:24 -0000 On Thu, Sep 12, 2013 at 09:33:34AM -1000, Jonathon Wright wrote: > I agree, really, I do. This is very frustrating to me. Unfortunately, the > team has left and gone to another project. They indicated to our management > that we had 90 days to address the issue with our plan. Its a bit harder to > contact them now since they are gone, but I can probably get some questions > to them. They did leave a copy of the report, here is the entire verbiage: > > ---BEGIN > > *Description of Finding:* Object reuse cannot be verified. The FreeBSD > servers used have not been evaluated or certified by NIAP. As such, it > cannot be verified that the operating system ensures transient memory > cleansing (object reuse) features are in place. > > *Rationale for Severity Code Determination:* The Validation team has > determined this to be a Category II finding. By using unapproved Operating > Systems (OS) which do not ensure that no residual data from a former object > exists, a malicious user could gain access to memory and OS objects that > contain sensitive information. > > *Recommended Countermeasure(s):* Transition servers to an NIAP approved OS. > Decommission the FreeBSD servers. > ---END > > What I think they are looking for is a verification that every malloc has a > call to free afterwords that zeros out the memory used. I could be wrong, > but just a guess. If you search for "niap object reuse" you can find some information about what they are talking about. I don't think you need to turn on Z malloc option, it appears to be something else, although I'm not sure what TCB means on the page I found. I also would suggest to management that your auditors haven't actually defined a problem. They've made it sound like they have. > "By using unapproved Operating Systems (OS) which do not ensure that no > residual data from a former object exists, a malicious user could gain > access to memory and OS objects that contain sensitive information" No, their statement is wrong. They said they can't validate that it does, not because they tested and found it doesn't, but because it isn't on some mysterious list. Therefore the statement that the OS does not ensure that residual data is scrubbed is incorrect. A more correct statement is "the OS hasn't been validated to ", not that it *will* leak data. OK, it's semantics, but it's an important difference as they claim the OS doesn't ensure data is secure when they know no such thing. By playing the semantic game, and by the above incorrect statement, they've freaked your management out. Personally I wouldn't pay their bill until they correct their statement and provide an explanation as to why this is a bad thing, with examples and or references to the standard they claim to be checking against. Regards, Gary From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 18:23:20 2013 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 ESMTP id ED33094D; Fri, 13 Sep 2013 18:23:20 +0000 (UTC) (envelope-from jonathon.s.wright@gmail.com) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8256C279C; Fri, 13 Sep 2013 18:23:20 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id pa12so1274846veb.2 for ; Fri, 13 Sep 2013 11:23:19 -0700 (PDT) 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=uNbBSetYyZIU3cqAeoYel86xQuT7gQw3DlLaV1x7m5w=; b=hneOkEYI4Rtm+69Fgmaim+znvPuCeh696gyB6ghD+ioxQO/C4vG4ByHr03IXtW6yUN 2RnZ4bbunM611SqqffvP29yfdGXF/I27yWFx0hrrzdJQEOPQkckIg6QBzzt3wHizOt84 DqeJkHTcq/p1HvkSTd/r4kgDuAokAvOrLWUzXO2Nf7oVCmEcwiuGRswexa2QX+ycgd4x gsmreHY1axV/OoEqKfWXWN/vCG+ww+MqUwjTGN1rkIIClPVp1fy0VTeq26szutE7otEY 6VL3KQioEEnYnv1WAZQLEFm3E9Bz8jrgEYnottkO1/4zRU2WDS8skDhP7Kg8a75LqBWG oaLA== MIME-Version: 1.0 X-Received: by 10.52.103.101 with SMTP id fv5mr2368016vdb.31.1379096599607; Fri, 13 Sep 2013 11:23:19 -0700 (PDT) Received: by 10.58.41.66 with HTTP; Fri, 13 Sep 2013 11:23:19 -0700 (PDT) In-Reply-To: <20130913164718.GC33898@in-addr.com> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <20130913164718.GC33898@in-addr.com> Date: Fri, 13 Sep 2013 08:23:19 -1000 Message-ID: Subject: Re: FreeBSD Transient Memory problem? From: Jonathon Wright To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-security@freebsd.org" , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:23:21 -0000 Well stated Gary. I need to divulge more information it appears. The reason I'm unable to effectively fight the semantic game, and not pay the auditors, etc. etc. is because the auditors are the DoD. We work for a private company that's contracted out to provide services to the DoD. But we still have to pass their inspections. As you all know, the DoD does not exactly see things in anything but black and white. So yes, my management is freaked out because the DoD auditors (paid for by the DoD btw) are finding issues that we have to resolve to keep the contract going. That's why my hands are tied. I'll give them credit though, they are allowing me to demonstrate FreeBSD's capability in this manner by providing documentation since FreeBSD does not have the cert. Thats the first non-black and white auditor check I've seen in years. We have lots of time and efforts invested in our architecture which is based on FreeBSD and thats why we're fighting to keep it, hence the start of this post. Thanks again for all the insights, I'll keep ya up to date. We have another month or so to work this, so we're still formulating an initial response. JW On Fri, Sep 13, 2013 at 6:47 AM, Gary Palmer wrote: > On Thu, Sep 12, 2013 at 09:33:34AM -1000, Jonathon Wright wrote: > > I agree, really, I do. This is very frustrating to me. Unfortunately, the > > team has left and gone to another project. They indicated to our > management > > that we had 90 days to address the issue with our plan. Its a bit harder > to > > contact them now since they are gone, but I can probably get some > questions > > to them. They did leave a copy of the report, here is the entire > verbiage: > > > > ---BEGIN > > > > *Description of Finding:* Object reuse cannot be verified. The FreeBSD > > servers used have not been evaluated or certified by NIAP. As such, it > > cannot be verified that the operating system ensures transient memory > > cleansing (object reuse) features are in place. > > > > *Rationale for Severity Code Determination:* The Validation team has > > determined this to be a Category II finding. By using unapproved > Operating > > Systems (OS) which do not ensure that no residual data from a former > object > > exists, a malicious user could gain access to memory and OS objects that > > contain sensitive information. > > > > *Recommended Countermeasure(s):* Transition servers to an NIAP approved > OS. > > Decommission the FreeBSD servers. > > ---END > > > > What I think they are looking for is a verification that every malloc > has a > > call to free afterwords that zeros out the memory used. I could be wrong, > > but just a guess. > > If you search for "niap object reuse" you can find some information about > what they are talking about. I don't think you need to turn on Z malloc > option, it appears to be something else, although I'm not sure what TCB > means on the page I found. > > I also would suggest to management that your auditors haven't actually > defined a problem. They've made it sound like they have. > > > "By using unapproved Operating Systems (OS) which do not ensure that no > > residual data from a former object exists, a malicious user could gain > > access to memory and OS objects that contain sensitive information" > > No, their statement is wrong. They said they can't validate that it > does, not because they tested and found it doesn't, but because it isn't > on some mysterious list. Therefore the statement that the OS does not > ensure that residual data is scrubbed is incorrect. A more correct > statement is "the OS hasn't been validated to ", not that it *will* > leak data. OK, it's semantics, but it's an important difference as they > claim the OS doesn't ensure data is secure when they know no such thing. > > By playing the semantic game, and by the above incorrect statement, they've > freaked your management out. Personally I wouldn't pay their bill until > they correct their statement and provide an explanation as to why this is a > bad thing, with examples and or references to the standard they claim > to be checking against. > > Regards, > > Gary > From owner-freebsd-security@FreeBSD.ORG Fri Sep 13 21:27:40 2013 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 ESMTP id 8C872758; Fri, 13 Sep 2013 21:27:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 636F92564; Fri, 13 Sep 2013 21:27:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 61492B939; Fri, 13 Sep 2013 17:27:39 -0400 (EDT) From: John Baldwin To: freebsd-security@freebsd.org Subject: Re: FreeBSD Transient Memory problem? Date: Fri, 13 Sep 2013 17:03:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20130913164718.GC33898@in-addr.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201309131703.40685.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Sep 2013 17:27:39 -0400 (EDT) Cc: Gary Palmer , Jonathon Wright , John-Mark Gurney , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:27:40 -0000 On Friday, September 13, 2013 2:23:19 pm Jonathon Wright wrote: > Well stated Gary. > > I need to divulge more information it appears. The reason I'm unable to > effectively fight the semantic game, and not pay the auditors, etc. etc. is > because the auditors are the DoD. We work for a private company that's > contracted out to provide services to the DoD. But we still have to pass > their inspections. As you all know, the DoD does not exactly see things in > anything but black and white. > > So yes, my management is freaked out because the DoD auditors (paid for by > the DoD btw) are finding issues that we have to resolve to keep the > contract going. That's why my hands are tied. I'll give them credit though, > they are allowing me to demonstrate FreeBSD's capability in this manner by > providing documentation since FreeBSD does not have the cert. Thats the > first non-black and white auditor check I've seen in years. > > We have lots of time and efforts invested in our architecture which is > based on FreeBSD and thats why we're fighting to keep it, hence the start > of this post. > > Thanks again for all the insights, I'll keep ya up to date. We have another > month or so to work this, so we're still formulating an initial response. I think the sensible thing they are looking for is that new pages don't leak data between processes, not anything to do with malloc zeroing, etc. FreeBSD definitely does do this. However, the "right" answer is probably that you will have to pay to have the version of FreeBSD you are currently using audited. -- John Baldwin From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 02:41:13 2013 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 ESMTP id D6B59EF5; Sat, 14 Sep 2013 02:41:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 8A25B2B67; Sat, 14 Sep 2013 02:41:13 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r8E2f0dL089243 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 19:41:04 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5233CCB6.9010205@freebsd.org> Date: Sat, 14 Sep 2013 10:40:54 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: FreeBSD Transient Memory problem? References: <20130913164718.GC33898@in-addr.com> <201309131703.40685.jhb@freebsd.org> In-Reply-To: <201309131703.40685.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gary Palmer , freebsd-security@freebsd.org, John-Mark Gurney , Jonathon Wright X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 02:41:13 -0000 On 9/14/13 5:03 AM, John Baldwin wrote: > On Friday, September 13, 2013 2:23:19 pm Jonathon Wright wrote: >> Well stated Gary. >> >> I need to divulge more information it appears. The reason I'm unable to >> effectively fight the semantic game, and not pay the auditors, etc. etc. is >> because the auditors are the DoD. We work for a private company that's >> contracted out to provide services to the DoD. But we still have to pass >> their inspections. As you all know, the DoD does not exactly see things in >> anything but black and white. >> >> So yes, my management is freaked out because the DoD auditors (paid for by >> the DoD btw) are finding issues that we have to resolve to keep the >> contract going. That's why my hands are tied. I'll give them credit though, >> they are allowing me to demonstrate FreeBSD's capability in this manner by >> providing documentation since FreeBSD does not have the cert. Thats the >> first non-black and white auditor check I've seen in years. >> >> We have lots of time and efforts invested in our architecture which is >> based on FreeBSD and thats why we're fighting to keep it, hence the start >> of this post. >> >> Thanks again for all the insights, I'll keep ya up to date. We have another >> month or so to work this, so we're still formulating an initial response. > I think the sensible thing they are looking for is that new pages don't leak > data between processes, not anything to do with malloc zeroing, etc. FreeBSD > definitely does do this. However, the "right" answer is probably that you > will have to pay to have the version of FreeBSD you are currently using > audited. this will probably be a lot cheaper than changing to Linux at this point. From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 02:43:38 2013 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 ESMTP id 4ABF7FDF; Sat, 14 Sep 2013 02:43:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (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 0018E2B87; Sat, 14 Sep 2013 02:43:37 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-245-177.lns20.per2.internode.on.net [121.45.245.177]) (authenticated bits=0) by vps1.elischer.org (8.14.6/8.14.6) with ESMTP id r8E2hWFl089267 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 19:43:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5233CD4F.1020808@freebsd.org> Date: Sat, 14 Sep 2013 10:43:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Baldwin Subject: Re: FreeBSD Transient Memory problem? References: <20130913164718.GC33898@in-addr.com> <201309131703.40685.jhb@freebsd.org> <5233CCB6.9010205@freebsd.org> In-Reply-To: <5233CCB6.9010205@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gary Palmer , freebsd-security@freebsd.org, John-Mark Gurney , Jonathon Wright X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 02:43:38 -0000 On 9/14/13 10:40 AM, Julian Elischer wrote: > On 9/14/13 5:03 AM, John Baldwin wrote: >> On Friday, September 13, 2013 2:23:19 pm Jonathon Wright wrote: >>> Well stated Gary. >>> >>> I need to divulge more information it appears. The reason I'm >>> unable to >>> effectively fight the semantic game, and not pay the auditors, >>> etc. etc. is >>> because the auditors are the DoD. We work for a private company >>> that's >>> contracted out to provide services to the DoD. But we still have >>> to pass >>> their inspections. As you all know, the DoD does not exactly see >>> things in >>> anything but black and white. >>> >>> So yes, my management is freaked out because the DoD auditors >>> (paid for by >>> the DoD btw) are finding issues that we have to resolve to keep the >>> contract going. That's why my hands are tied. I'll give them >>> credit though, >>> they are allowing me to demonstrate FreeBSD's capability in this >>> manner by >>> providing documentation since FreeBSD does not have the cert. >>> Thats the >>> first non-black and white auditor check I've seen in years. >>> >>> We have lots of time and efforts invested in our architecture >>> which is >>> based on FreeBSD and thats why we're fighting to keep it, hence >>> the start >>> of this post. >>> >>> Thanks again for all the insights, I'll keep ya up to date. We >>> have another >>> month or so to work this, so we're still formulating an initial >>> response. >> I think the sensible thing they are looking for is that new pages >> don't leak >> data between processes, not anything to do with malloc zeroing, >> etc. FreeBSD >> definitely does do this. However, the "right" answer is probably >> that you >> will have to pay to have the version of FreeBSD you are currently >> using >> audited. > > this will probably be a lot cheaper than changing to Linux at this > point. It is possible you could ask the FreeBSD Foundation if they would put up some of the cash as a project.. it may be generally useful. > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > > From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 10:26:27 2013 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 ESMTP id 62F4013E for ; Sat, 14 Sep 2013 10:26:27 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7622E31 for ; Sat, 14 Sep 2013 10:26:27 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:e570:39d1:5fba:531f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 642534AC58; Sat, 14 Sep 2013 14:26:18 +0400 (MSK) Date: Sat, 14 Sep 2013 14:26:09 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <147224144.20130914142609@serebryakov.spb.ru> To: Brett Glass Subject: Re: FreeBSD Transient Memory problem? In-Reply-To: <201309131611.KAA09855@mail.lariat.net> References: <20130912053559.GF68682@funkthat.com> <979901F9-5F25-4DF1-95A8-32473C55B25F@gmail.com> <52320144.2090807@freebsd.org> <201309130040.SAA28208@mail.lariat.net> <5232BE53.4040900@obluda.cz> <201309131611.KAA09855@mail.lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Dan Lukes , Jonathon Wright , "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 10:26:27 -0000 Hello, Brett. You wrote 13 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 15:47:13: >>Juniper's FreeBSD has been verified (whatever it mean in such particular >>case) as installed inside such router - e.g. version, patch level, >>kernel compilation options, loaded kernel modules, ... >> >>In short, results of security audit of FreeBSD 9.1-R-p2 compiled without >>if_re module is not applicable to FreeBSD 9.1-R-p3 compiled with if_re >>module nor to FreeBSD 9.1-R-p3 compiled without if_re module BG> True, but the details of memory allocation and scrubbing are unlikely to BG> change. This "but" is not applicable to formal certification process. As engineer you are totally right. But certification is not engineering. Certificate is given to one concrete configuration. In some certification processes even change of brand of memory modules in computer could avoid certificate, for example (I don't say, that it is so for EVERY certification, but formal, bank- or government-recognized security ones typically are SUCH strict). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 12:05:16 2013 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 ESMTP id 249F9142 for ; Sat, 14 Sep 2013 12:05:16 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFF9A2323 for ; Sat, 14 Sep 2013 12:05:15 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r8EC5Ftn048376 for ; Sat, 14 Sep 2013 05:05:15 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r8EC5FJn048375 for freebsd-security@freebsd.org; Sat, 14 Sep 2013 05:05:15 -0700 (PDT) (envelope-from david) Resent-From: David Wolfskill Resent-Date: Sat, 14 Sep 2013 05:05:15 -0700 Resent-Message-ID: <20130914120515.GZ25357@albert.catwhisker.org> Resent-To: freebsd-security@freebsd.org Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.7/8.14.7) with ESMTP id r8EC1psB048343 for ; Sat, 14 Sep 2013 05:01:51 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.7/8.14.7/Submit) id r8EC1p2Z048342 for freebsd-security@freebsd.org; Sat, 14 Sep 2013 05:01:51 -0700 (PDT) (envelope-from david) Date: Sat, 14 Sep 2013 05:01:51 -0700 From: David Wolfskill To: freebsd-security@freebsd.org Subject: Odd sshd entry in auth.log Message-ID: <20130914120151.GY25357@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+mQruWSI2c46YBtV" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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: Sat, 14 Sep 2013 12:05:16 -0000 --+mQruWSI2c46YBtV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My (tiny) networks at home are sitting behind a multi-homed FreeBSD machine using IPFW & natd, with an externally-visible static /32 -- nothing particularly obscure or exotic, certainly. The packet-filter box is configured to forward incoming ssh (22/tcp) to my primary internal machine; in turn, that is configured to only permit public key authentication. Again, this isn't exactly "new and shiny" technology. One thing I do that may be a bit unusual is that I have the packet-filter's IPFW rules set up so that every attempted SSH "session-initiation" packet is logged. I have found this ... at least "of interest" a few times; below relates one of them. I am in the habit of reviewing the previous day's logs while I am running "make buildworld" ((& friends) on my laptop each morning. This morning, I found a single entry in auth.log that -- unusually -- was not obviously associated with any other auth.log entries; it's the middle of: Sep 13 11:18:38 albert sshd[43637]: Accepted publickey for david from 66.12= 9.224.36 port 5944 ssh2 Sep 13 11:18:43 albert sshd[43654]: Accepted publickey for david from 66.12= 9.224.36 port 24618 ssh2 Sep 13 12:43:24 albert sshd[43949]: fatal: Read from socket failed: Connect= ion reset by peer [preauth] Sep 13 13:10:26 albert sshd[36478]: Received disconnect from 172.17.0.254: = 11: disconnected by user Sep 13 13:10:26 albert sshd[38778]: Received disconnect from 172.17.0.254: = 11: disconnected by user So: the first couple of entries are from me accessing home from work. And the latter 2 entries are disconnections from my spouse's laptop (at home). But that middle one (this time, all by itself) seems ... odd (to me): Sep 13 12:43:24 albert sshd[43949]: fatal: Read from socket failed: Connect= ion reset by peer [preauth] I don't find any other auth.log entries that seem at all related, and that entry doesn't provide many hints about the origin of what caused it. If I look at /var/log/security (where the IPFW log entries go), the closest (temporally) entries I find (that aren't better-explained as belonging to obviously different activity are: Sep 13 10:22:28 janus kernel: ipfw: 10000 Accept TCP 216.127.84.116:10833 1= 72.16.8.13:22 out via dc0 Sep 13 12:43:13 janus kernel: ipfw: 10000 Accept TCP 216.127.84.116:54953 1= 72.16.8.13:22 out via dc0 So I'm *thinking* that someone was probing a wee bit ... but I have rather little to go on. And while I like to think that I'm not paranoid, I do have some reason to believe that there are definitely folks out there who would quite willingly take advantage of an inadequately-secured system. It's at times like this that I kinda wish that every log entry from sshd mentioned the IP address of the (would-be) SSH client. :-{ Comments? Suggestions? (I'm on the list, so I need not be Cc:ed. Private responses will be kept private, though. I've set Reply-To for convenience.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --+mQruWSI2c46YBtV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlI0UC4ACgkQmprOCmdXAD3qhgCdGEMCP/kKWh/0zknxd/yuabnN X5IAn0HRlgImFuTjFScXyKeaCBgYUMWJ =KpfI -----END PGP SIGNATURE----- --+mQruWSI2c46YBtV-- From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 12:37:11 2013 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 ESMTP id 5DD0F95A for ; Sat, 14 Sep 2013 12:37:11 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2291B2494 for ; Sat, 14 Sep 2013 12:37:10 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 9ADDD4F2E for ; Sat, 14 Sep 2013 12:37:04 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id DB9573607C; Sat, 14 Sep 2013 14:36:51 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-security@freebsd.org Subject: Re: Odd sshd entry in auth.log References: <20130914120151.GY25357@albert.catwhisker.org> Date: Sat, 14 Sep 2013 14:36:51 +0200 In-Reply-To: <20130914120151.GY25357@albert.catwhisker.org> (David Wolfskill's message of "Sat, 14 Sep 2013 05:01:51 -0700") Message-ID: <86vc23mvfg.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 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 12:37:11 -0000 David Wolfskill writes: > Sep 13 12:43:24 albert sshd[43949]: fatal: Read from socket failed: Conne= ction reset by peer [preauth] Probably a banner scan. I wouldn't worry about it. I see millions of these every day. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 13:06:25 2013 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 ESMTP id 56A32E9B for ; Sat, 14 Sep 2013 13:06:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13A0325F8 for ; Sat, 14 Sep 2013 13:06:25 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id D6801153439; Sat, 14 Sep 2013 15:06:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TBYz93PHpSg; Sat, 14 Sep 2013 15:06:19 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:8893:549f:c4aa:bb70] (unknown [IPv6:2001:4cb8:3:1:8893:549f:c4aa:bb70]) by smtp.digiware.nl (Postfix) with ESMTP id C6D0D153435; Sat, 14 Sep 2013 15:06:19 +0200 (CEST) Message-ID: <52345F43.5070601@digiware.nl> Date: Sat, 14 Sep 2013 15:06:11 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Odd sshd entry in auth.log References: <20130914120151.GY25357@albert.catwhisker.org> In-Reply-To: <20130914120151.GY25357@albert.catwhisker.org> 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.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 13:06:25 -0000 On 2013-09-14 14:01, David Wolfskill wrote: > Sep 13 12:43:24 albert sshd[43949]: fatal: Read from socket failed: Connection reset by peer [preauth] I see plentyu of these, if only because I test the sshd availablity with nagios without actually going thru the full login... I just abort once I see sshd report it's availability on the port. Hence the 'reset by peer [preauth].' Like DES says: Scanners generate more or less the same behavior. They scan, and try to determine if you are running a vulnerable sshd or something else they can work with.... I still have a wish on my todo to see if it is possible to report the ipnr... And then block hosts with to many tries. But it's not really high on the agenda... --WjW From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 14:04:01 2013 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 ESMTP id AA9F9B34; Sat, 14 Sep 2013 14:04:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1E528D8; Sat, 14 Sep 2013 14:04:00 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id F17DA4032; Sat, 14 Sep 2013 14:03:59 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 460884A101; Sat, 14 Sep 2013 16:03:17 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Lepore Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 References: <86hadre740.fsf@nine.des.no> <1379166722.1197.3.camel@revolution.hippie.lan> Date: Sat, 14 Sep 2013 16:03:16 +0200 In-Reply-To: <1379166722.1197.3.camel@revolution.hippie.lan> (Ian Lepore's message of "Sat, 14 Sep 2013 07:52:02 -0600") Message-ID: <86ob7vlcuz.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, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 14:04:01 -0000 Ian Lepore writes: > I just ran into a build error related to this: > [...] > I find that the attached patch fixes it for me. > [...] > @@ -1468,7 +1468,7 @@ lib/libcxxrt__L: gnu/lib/libgcc__L > lib/libradius lib/libsbuf lib/libtacplus \ > ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ > ${_cddl_lib_libzfs_core} \ > - lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ > + lib/libutil ${_lib_libypclnt} lib/libldns lib/libz lib/msun \ > ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ > ${_secure_lib_libssl} >=20=20 That's not going to work, because libldns requires libcrypto. You should try the following: @@ -1470,8 +1470,8 @@ ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ ${_cddl_lib_libzfs_core} \ lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ - ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ - ${_secure_lib_libssl} + ${_secure_lib_libcrypto} ${_lib_libldns} \ + ${_secure_lib_libssh} ${_secure_lib_libssl} =20 .if ${MK_ATF} !=3D "no" _lib_atf_libatf_c=3D lib/atf/libatf-c Oh, wait, that's actually an excerpt from the commit that enabled LDNS in OpenSSH. What a coincidence! DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 13:52:08 2013 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 ESMTP id 8E34F97D; Sat, 14 Sep 2013 13:52:08 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5EFCB2866; Sat, 14 Sep 2013 13:52:08 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VKqGc-0003u7-T6; Sat, 14 Sep 2013 13:52:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r8EDq3KG010684; Sat, 14 Sep 2013 07:52:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/fnKWfxFtLI6qzAUpugaBt Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86hadre740.fsf@nine.des.no> References: <86hadre740.fsf@nine.des.no> Content-Type: multipart/mixed; boundary="=-Od+6iFyHx+lFNMSnnmWx" Date: Sat, 14 Sep 2013 07:52:02 -0600 Message-ID: <1379166722.1197.3.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-Mailman-Approved-At: Sat, 14 Sep 2013 19:44:50 +0000 Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 13:52:08 -0000 --=-Od+6iFyHx+lFNMSnnmWx Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r8EDq3KG010684 On Wed, 2013-09-11 at 17:00 +0200, Dag-Erling Sm=F8rgrav wrote: > OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you > disable LDNS in src.conf. If DNSSEC is enabled, the default setting fo= r > VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust > DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" > (aka "train the user to type 'yes' and hit enter") and "no" (aka "train > the user to type 'yes' and hit enter without even the benefit of a > second opinion"). >=20 > DES I just ran into a build error related to this: --- libssh.so.5 --- building shared library libssh.so.5 /local/build/staging/freebsd/wand/obj/arm.armv6/local/build/staging/freeb= sd/wand/src/tmp/usr/bin/ld: cannot find -lldns cc: error: linker command failed with exit code 1 (use -v to see invocati= on) *** [libssh.so.5] Error code 1 It only happens in one of my many build sandboxes, so I suspect it's related to the WITH/WITHOUT options in effect and perhaps also to the timing of parallel-build stuff. In the sandbox where it fails I have WITHOUT_KERBEROS and WITHOUT_PROFILE so I think that changes the timing of getting to the libssh build. I find that the attached patch fixes it for me. -- Ian --=-Od+6iFyHx+lFNMSnnmWx Content-Disposition: inline; filename="libssh_build.diff" Content-Type: text/x-patch; name="libssh_build.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit --- Makefile.inc1 Fri Sep 13 21:38:02 2013 -0600 +++ Makefile.inc1 Sat Sep 14 06:47:36 2013 -0600 @@ -1468,7 +1468,7 @@ lib/libcxxrt__L: gnu/lib/libgcc__L lib/libradius lib/libsbuf lib/libtacplus \ ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ ${_cddl_lib_libzfs_core} \ - lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ + lib/libutil ${_lib_libypclnt} lib/libldns lib/libz lib/msun \ ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ ${_secure_lib_libssl} @@ -1505,10 +1505,11 @@ cddl/lib/libzfs_core__L: cddl/lib/libnvp .if ${MK_OPENSSL} != "no" _secure_lib_libcrypto= secure/lib/libcrypto _secure_lib_libssl= secure/lib/libssl -lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L +lib/libldns__L lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L .if ${MK_OPENSSH} != "no" _secure_lib_libssh= secure/lib/libssh -secure/lib/libssh__L: lib/libz__L secure/lib/libcrypto__L lib/libcrypt__L +secure/lib/libssh__L: lib/libz__L secure/lib/libcrypto__L lib/libcrypt__L \ + lib/libldns__L .if ${MK_KERBEROS_SUPPORT} != "no" secure/lib/libssh__L: lib/libgssapi__L kerberos5/lib/libkrb5__L \ kerberos5/lib/libhx509__L kerberos5/lib/libasn1__L lib/libcom_err__L \ --=-Od+6iFyHx+lFNMSnnmWx-- From owner-freebsd-security@FreeBSD.ORG Sat Sep 14 15:40:25 2013 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 ESMTP id 3FCFB2B3; Sat, 14 Sep 2013 15:40:25 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 145A72C6F; Sat, 14 Sep 2013 15:40:24 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VKrxP-000AYn-HG; Sat, 14 Sep 2013 15:40:23 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r8EFeKg8010725; Sat, 14 Sep 2013 09:40:20 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/G5uuBxHkx6c1GuPZN9IYs Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 From: Ian Lepore To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86ob7vlcuz.fsf@nine.des.no> References: <86hadre740.fsf@nine.des.no> <1379166722.1197.3.camel@revolution.hippie.lan> <86ob7vlcuz.fsf@nine.des.no> Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 14 Sep 2013 09:40:19 -0600 Message-ID: <1379173219.1197.5.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r8EFeKg8010725 X-Mailman-Approved-At: Sat, 14 Sep 2013 19:46:19 +0000 Cc: freebsd-security@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 15:40:25 -0000 On Sat, 2013-09-14 at 16:03 +0200, Dag-Erling Sm=F8rgrav wrote: > Ian Lepore writes: > > I just ran into a build error related to this: > > [...] > > I find that the attached patch fixes it for me. > > [...] > > @@ -1468,7 +1468,7 @@ lib/libcxxrt__L: gnu/lib/libgcc__L > > lib/libradius lib/libsbuf lib/libtacplus \ > > ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ > > ${_cddl_lib_libzfs_core} \ > > - lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ > > + lib/libutil ${_lib_libypclnt} lib/libldns lib/libz lib/msun \ > > ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ > > ${_secure_lib_libssl} > > =20 >=20 > That's not going to work, because libldns requires libcrypto. You > should try the following: >=20 > @@ -1470,8 +1470,8 @@ > ${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \ > ${_cddl_lib_libzfs_core} \ > lib/libutil ${_lib_libypclnt} lib/libz lib/msun \ > - ${_secure_lib_libcrypto} ${_secure_lib_libssh} \ > - ${_secure_lib_libssl} > + ${_secure_lib_libcrypto} ${_lib_libldns} \ > + ${_secure_lib_libssh} ${_secure_lib_libssl} > =20 > .if ${MK_ATF} !=3D "no" > _lib_atf_libatf_c=3D lib/atf/libatf-c >=20 > Oh, wait, that's actually an excerpt from the commit that enabled LDNS > in OpenSSH. What a coincidence! >=20 > DES Hrm, sure enough, even though that sandbox claims to be at r255532, your changes from r255460 are not in Makefile.inc1. So I've got some sort of brokeness/pollution in my sandbox I'll look into, sorry for the noise. -- Ian