From owner-freebsd-security@FreeBSD.ORG Wed Mar 5 23:39:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D8EEDD5; Wed, 5 Mar 2014 23:39:05 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E695D67; Wed, 5 Mar 2014 23:39:05 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 7688616157; Wed, 5 Mar 2014 15:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394062744; bh=uZKvk7jClgl/Nt5YZcwtNcpoHPV3sDD/lhzjS5Z/SXg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=2QnLeXEDJYkqTnvqFUStk23dCNFibl5ClSZXhwIbHsMorSOfrywCyPZa+asF8wKQM Pw+uylck8CDKuvlfmOPX+Eb5YjJG6HwZJ6ncgK2XxIEh2Cy8nHv8PY6UAnDdEs478h qygkb6cGE1j3j8hDbIpWEr5hGvsWigruHV5YSBpw= Message-ID: <5317B597.5050900@delphij.net> Date: Wed, 05 Mar 2014 15:39:03 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Nicola Galante , freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> In-Reply-To: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" , jamie@FreeBSD.org, "secteam@FreeBSD.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 23:39:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/05/14 15:07, Nicola Galante wrote: > I found a potential vulnerability with FreeBSD jails. I installed a > server (hostserver) for my institute. This hostserver has a certain > IP address, let's say 10.0.0.100, and I installed and configured > three service jails (elog, mail, www), each with a different IP > address (10.0.0.101, 10.0.0.102, 10.0.0.103) > > root@hostserver:/jails/j # jls JID IP Address Hostname > Path 1 10.0.0.101 elogjail /jails/j/elog 2 > 10.0.0.102 mailjail /jails/j/mail 3 > 10.0.0.103 wwwjail /jails/j/www > > I have an account on both the hostserver and the elogjail. Password > authentication on hostserver and ssh key authentication in the > jail. The service sshd is running on both the hostserver and > elogjail. If I ssh into the elogjail > > [galante@caronte ~]$ ssh galante@elogjail Enter passphrase for key > '/home/galante/.ssh/id_dsa': Last login: Wed Mar 5 21:37:23 2014 > from caronte galante@elogjail:~ % > > as expected. But if I turn off the sshd service in elogjail (and > keep the elogjail up and running) and I try to connect to elogjail, > I first get a complaint that the fingerprint for the RSA key sent > by the remote host has changed. If I remove the corresponding line > in my local .ssh/known_hosts file and try to reconnect, this is > what happens: > > [galante@caronte ~]$ ssh galante@elogjail Password for > galante@hostserver: Last login: Wed Mar 5 21:12:20 2014 from > caronte galante@hostserver:~ % > > I log into the host system! Of course this is possible because I > have an account on both the host system and the jail. However, I > believe that this can cause a serious potential security threat. I > can envision several scenarios where somebody attempts to get into > a jail and instead gets into the host system. I checked also the > DNS responsiveness. The problem persists even if I use IP addresses > instead of host names. >> How-To-Repeat: > Follow the steps described above. >> Fix: > I don't know how to fix the problem other than by disabling sshd in > the hostserver. I don't think this is a security issue and close this as invalid, however I'm bringing secteam@ and jamie@ in, just to make sure I didn't understood the problem wrong. The first thing is let's confirm that I'm understanding your question correctly. What happens is that: a) you have account on *both* jail and host system. b) you attempted to log in into jail's IP, which is also bound to host system; c) your configuration didn't explicitly specify SSH's listening address on host, so it's a wildcard (Listen 22 instead of Listen hostip:22, where you can see in sockstat -4l as *:22 for sshd). and d) when jail is shut down, when you connect to the jail's IP, you connected into the host. This is NOT a problem with jail. For starters, it's very bad idea to give out host shell account, privileged or not, to jail users if they are not trusted. Let's consider this scenario: jail$ su -l jail# cp /usr/bin/less /bin/root_shell jail# chown root:wheel /bin/root_shell jail# chmod 6555 /bin/root_shell jail# logout jail$ logout Then, you basically have a setuid binary that can be reached from host system. As an attacker I would do: host$ /path/to/jail/bin/root_shell # So the solution would be to change your configuration such that: 1) Do not give shell access to jail users unless they are also host system administrator. 2) Do not make host's sshd to listen on all addresses, instead, only listen to the designated host IP address. This is not a security measure but avoids confusion. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTF7WXAAoJEJW2GBstM+ns/dMP/2MdcY2FbXR7nl5cc5NL6Xyi O87+Eee5QbJ4pRP/CdvTD4OivHi8BecS9egQDhtRuIvv6XtHWCD26KPuMUYgZd4U 8min9L/kfFLwlBIuH9CKGR0iRzXDGY99NpRVpwSJBPxSeJrUZZzCMdoCwEQPvhkQ S4TNv9+qiXmqDAwJbcTFDUfhqc9FPuaLfdn/6+Cbi3MEAhJjaAuuvbZeUvhKLi/n xavs3e9tqcy3i3D6dJvSuOvDibBbrLpamch23VeyOMTZ78ahOKLa5dDAfkFJgx+g JicfTcdcSiPEutPenJo1bWUn5DbW1+aoNL+acBLty9Q0iknn8dcSG6PWDHnz3pmq +hE8lOq+7HGkVoqIGtDULlPy2eEeM6WwjUj4wcAQI7PfStkTc7eqJooj76mMmPg7 CKF0yaqAG/57Qys4G6eVRxW8sAV33k8gaeTjjrRX6tFYZvZElSZ57shxZPinxzQe XAAyq2E1gkxKnnvFZGEJSv4kmyE0u4jJAGW17N3x04R/VjPgtdBKZ4YeG3HoHdh3 vJ9LBUuZvx3zy0bVslJFKTNQq3tvCWhOkf4dITHKm2JBpaeo9VwGs50yUKYg/3NB //NDUnQCF9rpoqU40w9JKEOiWO+nZLUzdXLerI8TccU15Mz0dpo+06oC6e72DVtG aUQS8DKHmWB9SwgXX02d =ky3s -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Mar 6 00:43:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC077497; Thu, 6 Mar 2014 00:43:28 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001: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 9305134A; Thu, 6 Mar 2014 00:43:28 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id y20so2003642ier.41 for ; Wed, 05 Mar 2014 16:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rfYVsvOtQTnyF+wkBhWLjftDOyYIReR5MEkgxLbRaII=; b=cwavLJX3xbEuksEOjt55BGlhJYvpM2P6NKlK4cYu4Wc7CQHGbz159ORdKgV66e23tD OBDMyV/T1J3VLB9jzTPM0WffnhsLZ9pRDsavUsU+afCoYhzzY4WnnT6BACGI8LB0LLYU pGUrZsoKPhENTpEYFETykQw4xdaq1BHLnyC/cYVn3msIfspYpGHGGlXgalo5nMQngYND e+PXvsiwKqBy9bhhKznNwL+H1QzmBQYBIRJgAV+m5wMCa3A56rxyQbXvv+O3KkSiDnGb UL9fWe66B0/MVdwWh4HvfNlxHyA2Y9S9CQSlJ2CMnWUE7CH6ed7A8AIY75a5hpMdUG/+ ThcA== MIME-Version: 1.0 X-Received: by 10.43.90.202 with SMTP id bj10mr7267701icc.48.1394066607077; Wed, 05 Mar 2014 16:43:27 -0800 (PST) Received: by 10.50.164.227 with HTTP; Wed, 5 Mar 2014 16:43:27 -0800 (PST) In-Reply-To: <5317B597.5050900@delphij.net> References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> Date: Wed, 5 Mar 2014 18:43:27 -0600 Message-ID: Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail From: Scot Hetzel To: freebsd-gnats-submit@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-security@freebsd.org" , Nicola Galante X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:43:28 -0000 On Wed, Mar 5, 2014 at 5:39 PM, Xin Li wrote: > So the solution would be to change your configuration such that: > : > 2) Do not make host's sshd to listen on all addresses, instead, only > listen to the designated host IP address. This is not a security > measure but avoids confusion. > You will want to change the hosts sshd_config to only listen on the 10.0.0.100 address: ListenAddress 10.0.0.100 If the host needs to listen on multiple addresses, just add another ListenAddress. http://www.cyberciti.biz/tips/howto-openssh-sshd-listen-multiple-ip-address.html -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-security@FreeBSD.ORG Thu Mar 6 00:54:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E86297B; Thu, 6 Mar 2014 00:54:44 +0000 (UTC) Received: from m2.gritton.org (gritton.org [199.192.164.235]) (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 3D9CD656; Thu, 6 Mar 2014 00:54:43 +0000 (UTC) Received: from [192.168.0.34] (c-50-168-192-61.hsd1.ut.comcast.net [50.168.192.61]) (authenticated bits=0) by m2.gritton.org (8.14.7/8.14.7) with ESMTP id s260SiA8055544; Wed, 5 Mar 2014 17:28:44 -0700 (MST) (envelope-from jamie@freebsd.org) Message-ID: <5317C135.6060404@freebsd.org> Date: Wed, 05 Mar 2014 17:28:37 -0700 From: James Gritton User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: d@delphij.net, Nicola Galante Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> In-Reply-To: <5317B597.5050900@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Mar 2014 02:08:42 +0000 Cc: "freebsd-security@freebsd.org" , "secteam@FreeBSD.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 00:54:44 -0000 On 3/5/2014 4:39 PM, Xin Li wrote: > This is NOT a problem with jail. For starters, it's very bad idea to > give out host shell account, privileged or not, to jail users if they > are not trusted. Let's consider this scenario: > > jail$ su -l > jail# cp /usr/bin/less /bin/root_shell > jail# chown root:wheel /bin/root_shell > jail# chmod 6555 /bin/root_shell > jail# logout > jail$ logout > > Then, you basically have a setuid binary that can be reached from host > system. As an attacker I would do: > > host$ /path/to/jail/bin/root_shell That's an important point: jails are good for their *own* security, but they make the base system insecure for allowing untrusted users. I can see user accounts for the admin's own use (likely the condition that was originally reported), but that's the only account I would consider allowing. - Jamie From owner-freebsd-security@FreeBSD.ORG Thu Mar 6 02:13:59 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E135877 for ; Thu, 6 Mar 2014 02:13:59 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A6B8C85 for ; Thu, 6 Mar 2014 02:13:58 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id c11so1274994lbj.40 for ; Wed, 05 Mar 2014 18:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QIWdkAkogWGuWNApvGMbaAwCwdhsuIJT5w5PN8IhtQY=; b=ZHI0MkMqwRHtH1XSWzMEY9kgl9Q7wDvfTC/Wgw8FG6qi3enqnBBIIoUl0lP+5EsKx6 CcNwvGOb+mvqjULqwZKUoYtA4HSoUtVSonUBzDcnxSYMn4K7LIo/YAmehRri+k/nFjMm 3LRhOt66avKEl/k0vt7oOUgKiSftLMwBIR58FJQC4QLvfBTQtzHIebNzo53HiSpqUzn6 qWAcVx+TrZt4Zq6z/s51pl3BvE9izaOb5PoccPNBZdvOGN6rogY18+Gai/PWWyK7le6l B/LguV9EKsCLxfsQ20QoBAX04dJ5DkE6VdVOJfNhS11UUwVAJj/mbuBtVomvQAtVv6jD HpFg== MIME-Version: 1.0 X-Received: by 10.112.173.6 with SMTP id bg6mr5607908lbc.17.1394072037160; Wed, 05 Mar 2014 18:13:57 -0800 (PST) Received: by 10.112.35.167 with HTTP; Wed, 5 Mar 2014 18:13:57 -0800 (PST) In-Reply-To: <5317B597.5050900@delphij.net> References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> Date: Thu, 6 Mar 2014 02:13:57 +0000 Message-ID: Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail From: Tom Evans To: Xin LI Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org" , Nicola Galante X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 02:13:59 -0000 On Wed, Mar 5, 2014 at 11:39 PM, Xin Li wrote: > This is NOT a problem with jail. For starters, it's very bad idea to > give out host shell account, privileged or not, to jail users if they > are not trusted. Let's consider this scenario: > > jail$ su -l > jail# cp /usr/bin/less /bin/root_shell > jail# chown root:wheel /bin/root_shell > jail# chmod 6555 /bin/root_shell > jail# logout > jail$ logout > > Then, you basically have a setuid binary that can be reached from host > system. As an attacker I would do: > > host$ /path/to/jail/bin/root_shell > # > As a defender I would hope that someone has already done: host# chmod 700 /path/to You're right though, jail users have no business on the host. Cheers Tom From owner-freebsd-security@FreeBSD.ORG Thu Mar 6 06:55:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7054AD00 for ; Thu, 6 Mar 2014 06:55:23 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2805B67B for ; Thu, 6 Mar 2014 06:55:23 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id ur14so6636823igb.4 for ; Wed, 05 Mar 2014 22:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Q8qfQbjadUbGdkEPDo+n5kq2VoreYA4Vi3YAGiz+PZ0=; b=HSXyI+eE8zQuG0pjayCX3+dp4aYGH45KwuGzenmpUxMsfPyGZ+fVAt5tNVes0CFkzE 8ql+OXeVBCxk1rgKaaudCro03LupcX5HiiV7dwp9Z0CiWOwNDrTB9g9kvliVzkjUsllF ArbkA1zQbr98mx5NDchmRHrK7nOthxmXM62i0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Q8qfQbjadUbGdkEPDo+n5kq2VoreYA4Vi3YAGiz+PZ0=; b=Ki4ftic+fz8FxPs+mX5adyhhRJPs9iW8ayGET2o+Kb5sn83hrOAKPu8j6zn+x2yvHH /KjN0wd5xUxsMR6+juw9PMgDP525YVUp58PwuluTSiTTmu9cKYQe3XPDNdGrVD4pgsSZ T/p6ZG9Ul8oeViheREtOF3XJyR2XRAUIBZdP/yMU/riPRLHNK0xtllm+9YgokRy4mHZa xtBNXwiWocXr8F58kfALNW9YCgp0f7qdKbmifnCaP8frCYQnGydRwlOK7VcbSe7xwDJC +A9JAvMbfaACl9s14lDpoFjv4D/vEkcv9LkImXCHqCFYZ5iWLCsoTGbNprg+Rql0QFt2 Dz8A== X-Gm-Message-State: ALoCoQneY5OTxbSpauSEXxT8C15tver9++k/TBYEqkjYHVqzs8i1D1+ZoMasuuBxthvCQbxyxQph X-Received: by 10.42.232.206 with SMTP id jv14mr8558542icb.52.1394088922536; Wed, 05 Mar 2014 22:55:22 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id mi2sm21567374igb.3.2014.03.05.22.55.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 22:55:21 -0800 (PST) References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> Mime-Version: 1.0 (1.0) In-Reply-To: <5317B597.5050900@delphij.net> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <0E7A07FB-FE42-41BE-9FE2-36558C421411@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail Date: Thu, 6 Mar 2014 01:55:11 -0500 To: "d@delphij.net" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" , "freebsd-gnats-submit@FreeBSD.org" , "secteam@FreeBSD.org" , "jamie@FreeBSD.org" , Nicola Galante X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 06:55:23 -0000 --Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I would also add . . . separate ssh keys and passwords if the user needs ac= cess to both host and jailed systems. This is just common practice and not a= security flaw by any means but an engineering oversight. Popsicle sticks also have a security flaw, they let you jab yourself in the t= hroat if you fall while sucking on them. Solution . . . sit down. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Mar 5, 2014, at 18:39, Xin Li wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 >> On 03/05/14 15:07, Nicola Galante wrote: >> I found a potential vulnerability with FreeBSD jails. I installed a >> server (hostserver) for my institute. This hostserver has a certain >> IP address, let's say 10.0.0.100, and I installed and configured >> three service jails (elog, mail, www), each with a different IP >> address (10.0.0.101, 10.0.0.102, 10.0.0.103) >>=20 >> root@hostserver:/jails/j # jls JID IP Address Hostname >> Path 1 10.0.0.101 elogjail /jails/j/elog 2 >> 10.0.0.102 mailjail /jails/j/mail 3 >> 10.0.0.103 wwwjail /jails/j/www >>=20 >> I have an account on both the hostserver and the elogjail. Password >> authentication on hostserver and ssh key authentication in the >> jail. The service sshd is running on both the hostserver and >> elogjail. If I ssh into the elogjail >>=20 >> [galante@caronte ~]$ ssh galante@elogjail Enter passphrase for key >> '/home/galante/.ssh/id_dsa': Last login: Wed Mar 5 21:37:23 2014 >> from caronte galante@elogjail:~ % >>=20 >> as expected. But if I turn off the sshd service in elogjail (and >> keep the elogjail up and running) and I try to connect to elogjail, >> I first get a complaint that the fingerprint for the RSA key sent >> by the remote host has changed. If I remove the corresponding line >> in my local .ssh/known_hosts file and try to reconnect, this is >> what happens: >>=20 >> [galante@caronte ~]$ ssh galante@elogjail Password for >> galante@hostserver: Last login: Wed Mar 5 21:12:20 2014 from >> caronte galante@hostserver:~ % >>=20 >> I log into the host system! Of course this is possible because I >> have an account on both the host system and the jail. However, I >> believe that this can cause a serious potential security threat. I >> can envision several scenarios where somebody attempts to get into >> a jail and instead gets into the host system. I checked also the >> DNS responsiveness. The problem persists even if I use IP addresses >> instead of host names. >>> How-To-Repeat: >> Follow the steps described above. >>> Fix: >> I don't know how to fix the problem other than by disabling sshd in >> the hostserver. >=20 > I don't think this is a security issue and close this as invalid, > however I'm bringing secteam@ and jamie@ in, just to make sure I > didn't understood the problem wrong. >=20 > The first thing is let's confirm that I'm understanding your question > correctly. What happens is that: >=20 > a) you have account on *both* jail and host system. > b) you attempted to log in into jail's IP, which is also bound to host > system; > c) your configuration didn't explicitly specify SSH's listening > address on host, so it's a wildcard (Listen 22 instead of Listen > hostip:22, where you can see in sockstat -4l as *:22 for sshd). >=20 > and >=20 > d) when jail is shut down, when you connect to the jail's IP, you > connected into the host. >=20 > This is NOT a problem with jail. For starters, it's very bad idea to > give out host shell account, privileged or not, to jail users if they > are not trusted. Let's consider this scenario: >=20 > jail$ su -l > jail# cp /usr/bin/less /bin/root_shell > jail# chown root:wheel /bin/root_shell > jail# chmod 6555 /bin/root_shell > jail# logout > jail$ logout >=20 > Then, you basically have a setuid binary that can be reached from host > system. As an attacker I would do: >=20 > host$ /path/to/jail/bin/root_shell > # >=20 > So the solution would be to change your configuration such that: >=20 > 1) Do not give shell access to jail users unless they are also host > system administrator. >=20 > 2) Do not make host's sshd to listen on all addresses, instead, only > listen to the designated host IP address. This is not a security > measure but avoids confusion. >=20 > Cheers, > - --=20 > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) >=20 > iQIcBAEBCgAGBQJTF7WXAAoJEJW2GBstM+ns/dMP/2MdcY2FbXR7nl5cc5NL6Xyi > O87+Eee5QbJ4pRP/CdvTD4OivHi8BecS9egQDhtRuIvv6XtHWCD26KPuMUYgZd4U > 8min9L/kfFLwlBIuH9CKGR0iRzXDGY99NpRVpwSJBPxSeJrUZZzCMdoCwEQPvhkQ > S4TNv9+qiXmqDAwJbcTFDUfhqc9FPuaLfdn/6+Cbi3MEAhJjaAuuvbZeUvhKLi/n > xavs3e9tqcy3i3D6dJvSuOvDibBbrLpamch23VeyOMTZ78ahOKLa5dDAfkFJgx+g > JicfTcdcSiPEutPenJo1bWUn5DbW1+aoNL+acBLty9Q0iknn8dcSG6PWDHnz3pmq > +hE8lOq+7HGkVoqIGtDULlPy2eEeM6WwjUj4wcAQI7PfStkTc7eqJooj76mMmPg7 > CKF0yaqAG/57Qys4G6eVRxW8sAV33k8gaeTjjrRX6tFYZvZElSZ57shxZPinxzQe > XAAyq2E1gkxKnnvFZGEJSv4kmyE0u4jJAGW17N3x04R/VjPgtdBKZ4YeG3HoHdh3 > vJ9LBUuZvx3zy0bVslJFKTNQq3tvCWhOkf4dITHKm2JBpaeo9VwGs50yUKYg/3NB > //NDUnQCF9rpoqU40w9JKEOiWO+nZLUzdXLerI8TccU15Mz0dpo+06oC6e72DVtG > aUQS8DKHmWB9SwgXX02d > =3Dky3s > -----END PGP SIGNATURE----- > _______________________________________________ > 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= " --Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDMwNjA2NTUxM1owIwYJKoZIhvcN AQkEMRYEFL8SpszpkhyGJCklp1Blu9/vWW5bMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEACQl+gza9aR72olXVkfuD dxp9EBsAoOVkzlzFtwpFQgPZIkhLOKukHFW/VLKH37mAjtXcMRkVg55M/g9KT+oQgKW+BW+VOQtX wx+rX10cwk3q2pZBS4GJ2x401p9HapyNq5niwTDckaFK+cNv5hylXXrIYe97lsSQ7qZRiG1SIndq kLsCEIQTJbqw9tDbTosUyjGudNZQ/yWZGXQbvrUPjg0ftt5cPMrpkgTEgq10yl3c0esADC7VhL9O 1vNQOULOGrMYuDjblNWfm5GR1XomwQcz/NSEnBeBGk5y43R51VFZuoHMbVOqE+OOq7Vz0+ZM7GW7 Jdv7lDWkdH3K8WetDQAAAAAAAA== --Apple-Mail-B57BD488-AE1F-4C09-AEEE-4BF1170F2439-- From owner-freebsd-security@FreeBSD.ORG Thu Mar 6 14:10:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB056F70; Thu, 6 Mar 2014 14:10:34 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 57C1B90A; Thu, 6 Mar 2014 14:10:34 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id pa12so2733767veb.0 for ; Thu, 06 Mar 2014 06:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hz5cmZvmzfao2z0+wTHX5Dt7emLw8uKWQCNppYeRAio=; b=crqggKBn7pJCnJu2pOfesQCEYFf86kNyMtR08sA3SUTB+7FOu5k1tpaAS06NFNLILg gPIk4FL34oIpNspeIjYytn5aB5x/lnMy9E/a7QbGJp493yA/G/CeHWq1be0nJcCVD1FL kNyA7oi/lDUqAW2et/WkINxpHyF8uQgsjO/XARNKF96UfKqNmr3qe5IygssqTFhVrbIA JXlh6zlOccioMxK7K4rWpL5y18n3ZdX0pwK+xuS2tf1jPh7eP/1QlVH/9bmskK2R9JZb 9f0wFFU8ppXTT1cjsnkaIQ5lqicQfHBNrpCF/axumVxrA6ENkmuoLtRMPGRCkEVNzgrU RF7A== MIME-Version: 1.0 X-Received: by 10.220.249.6 with SMTP id mi6mr301224vcb.33.1394115033395; Thu, 06 Mar 2014 06:10:33 -0800 (PST) Received: by 10.58.203.170 with HTTP; Thu, 6 Mar 2014 06:10:33 -0800 (PST) In-Reply-To: <0E7A07FB-FE42-41BE-9FE2-36558C421411@dataix.net> References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> <0E7A07FB-FE42-41BE-9FE2-36558C421411@dataix.net> Date: Thu, 6 Mar 2014 09:10:33 -0500 Message-ID: Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail From: Shawn Webb To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "d@delphij.net" , "secteam@FreeBSD.org" , "freebsd-security@freebsd.org" , "jamie@FreeBSD.org" , "freebsd-gnats-submit@FreeBSD.org" , Nicola Galante X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:10:34 -0000 On Thu, Mar 6, 2014 at 1:55 AM, Jason Hellenthal wrote: > I would also add . . . separate ssh keys and passwords if the user needs > access to both host and jailed systems. This is just common practice and > not a security flaw by any means but an engineering oversight. > > Popsicle sticks also have a security flaw, they let you jab yourself in > the throat if you fall while sucking on them. Solution . . . sit down. One can also use vnet (VIMAGE kernel option) in conjunction with jails to give each jail its own full TCP/IP stack, rather than sharing the TCP/IP stack with the host. From owner-freebsd-security@FreeBSD.ORG Fri Mar 7 11:02:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B18E26ED for ; Fri, 7 Mar 2014 11:02:32 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 71AE1F1B for ; Fri, 7 Mar 2014 11:02:32 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 7AE945E87; Fri, 7 Mar 2014 11:02:31 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 0AC99EF1; Fri, 7 Mar 2014 12:02:07 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Tom Evans Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> Date: Fri, 07 Mar 2014 12:02:06 +0100 In-Reply-To: (Tom Evans's message of "Thu, 6 Mar 2014 02:13:57 +0000") Message-ID: <86d2hy6zm9.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-security@freebsd.org" , Xin LI , Nicola Galante X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:02:32 -0000 Tom Evans writes: > As a defender I would hope that someone has already done: > > host# chmod 700 /path/to > > You're right though, jail users have no business on the host. cf. the warning I added to the handbook after the last trip on this merry-go-round: http://www.freebsd.org/doc/handbook/jails.html DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat Mar 8 22:31:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5767E77; Sat, 8 Mar 2014 22:31:15 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 60F3917D; Sat, 8 Mar 2014 22:31:15 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so5146481vcb.38 for ; Sat, 08 Mar 2014 14:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2DGypOAfTAXVmvw1KNqpmkNWMgNlyUrjgn4QkZdyWOo=; b=g/tEACNdm9g5ApkaVooq5DkWbcXt26H1k2+HxAg65XwavNPLD8Ax4QUyPml+3ZOEnD K9P/MwuMZel1+g9iAe4ZGcCjm9jAQF9xHuXxxanhBAZxpPaJstlO/rhzUIJJprLcyOm6 jVB4rDO4kpAu0sr6khVOHz6zZKaUMb7RDjKaFEuLkBpZa/3HkmuZxDBOIBn0+6wtnxFW o5NehtT+gLLZHPT7M6YUF60kzSPls4J2sQp2WrmghaVusHqq3WMAPqivO7yvnvLD0iEo J82FlXe5RVVEd/3nkRc24oGCGK/Itbnlay1rGDdXpN4+5043M0fK6kMFdgUSrZsB2tIx hWIg== MIME-Version: 1.0 X-Received: by 10.220.95.139 with SMTP id d11mr1839839vcn.21.1394317874488; Sat, 08 Mar 2014 14:31:14 -0800 (PST) Received: by 10.220.106.199 with HTTP; Sat, 8 Mar 2014 14:31:14 -0800 (PST) Date: Sat, 8 Mar 2014 17:31:14 -0500 Message-ID: Subject: Secure Infrastructure [Crypto signed ISO images] From: grarpamp To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 08 Mar 2014 23:02:32 +0000 Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 22:31:15 -0000 >>> Cryptografically signed ISO images >>> http://docs.freebsd.org/cgi/mid.cgi?20140302172759.GA4728 >> If the use of [the signed] SHA-2[56] hashes don't provide enough >> assurance that the ISO images are authentic can you explain the >> crypto technology that you are looking for? Signing the ISO's [hashes of same] is a common practice. As is now signing the packages. However, just remember that both of these are only handwavy security bandaids trying to be placed from the periphery in, which is not the way to do things right... Until the FreeBSD project ... (1) moves to a repository such as Git [or something like the even further crypto integrated Monotone], where the repository itself has an internal crypto hash structure that can be signed from the very first initializing commit and upon later commits/tags/branches, etc... and (2) has and uses deterministic reproducible builds for everything flowing downstream from that [the source repo, packages, isos, build servers, rsync/ftp/http distribution servers, web/wiki/forum/mail servers, etc...] ... signing the periphery may look good to the casual observer, but it is ultimately untraceable in any cryptographic sense to the code from which those periphery elements are purported to come from. That's not a good position to be in, and is a clarification regarding discontiguous trust chains that needs pointed out. It also wouldn't hurt to have the repo on ZFS raidzN sha256, ECC ram, etc... if not already. >> if you verified the certificate of https host... ... you probably have more to learn about verification. https://www.eff.org/observatory https://en.wikipedia.org/wiki/Certificate_transparency And let's not forget the needed DNSSEC and IPSEC components. Though 1 and 2 above would be a great start. References... https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details https://wiki.debian.org/ReproducibleBuilds https://gitian.org/ http://git-scm.com/about/distributed http://git-scm.com/about/info-assurance http://www.monotone.ca/ From owner-freebsd-security@FreeBSD.ORG Thu Mar 13 21:08:37 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9121735B; Thu, 13 Mar 2014 21:08:37 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F05EEEE; Thu, 13 Mar 2014 21:08:37 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A75A71D5F4; Thu, 13 Mar 2014 14:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394744916; bh=43hM9yU1IxFFMvcSTofO+GikhwybwDgej+3A7ZPJ+EU=; h=Date:From:Reply-To:CC:Subject; b=Gk9Cjzt2UbesqIehaEd1lu8YAStFPcyo72G6lrYgSJv+YqEP2EDWhB5svLhc5LDPy q3KL5f3VgNwanoCDnGqPPNdsvTYhfyIyWrnhveE3gtXlYgsGrZgzTAsrU2uHzLDNEN ULQDjTcCHcVnIGZHIiFjgXrcyFPtrlNHZXaPi+wI= Message-ID: <53221E54.1030600@delphij.net> Date: Thu, 13 Mar 2014 14:08:36 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 Subject: [PATCH] casperd should detach from controlling session X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------050803050608090306080000" Cc: "freebsd-security@freebsd.org" , Pawel Jakub Dawidek X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 21:08:37 -0000 This is a multi-part message in MIME format. --------------050803050608090306080000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Pawel, I have noticed that casperd's child (zygote) would still use controlling session from parent. This can be observed by running ps - -ax on systems running casperd, where the child have a spurious console associated. The attached patch would fix it. May I commit it against -HEAD? By the way, the zygote child also closes file descriptor 4 twice (harmless; it's either sp[0] or the /dev/null which is closed before starting zygote_main, or before returning from stdnull(). Based on the construct of the code, I believe both close() can be omitted. If this makes sense I'll submit a new patch. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTIh5UAAoJEJW2GBstM+nsDIoP/jJ0na0zNFoxruLWCZEr7uDr ulgP8iV3B4b0OhTnCGsnlU3MOoypbLG9kMxJGVhfumZlxl/m6tg3nwBUA42Z/BHF r6XsPRv47A84PrJckVJcXhcvKOGPVlB23SdITjv2wW13Sj+d+g2j7cLULibvFLR/ a+hx5WVHYeFZPWuJL1g/LxtHvxCMvYoT7wgYMjrUdTuYr5kMC/hMgBk569AuC5QJ PQXvRKvaWvCGbNLj2BQTsEtunszmed7A/AUqDSx5pSju11J5vYETIuR+CSPn7kE1 6EwAY60jyoRMldQ7kRsp8FYsQX9OBDQVK7Gp95FF/jgBOIqo3B+I2SgKwBGrMM/G 4Z026QD3sAH7jcG6eK9mLrSIBtJ4zK5g9HwzE7v52lGRHsqm9n6gifcRIjBZW+iL MX1VujJ1Ew1PUxWFj3cgEgHkQ/cftTjl20TB0NW8SsskCy9cRhEN6Z+qEhT81zHf ywM8u3g8ndH/m/iwm1tho/Csp7ejHjGhD5sJf4pCfrwDkY3jVW0nd7Q4djMpDDBL to4tIyomXW3Mhhr+9Xt7x8sq+/YhYR+h/gslX3Q/VFnd/FEL/Ae7C1NS8KpRdZYG wkXzgdJBgRUxlVMxKGYn8wEtDreaMVrB4jkOAlGdSqaSuLtQpb5acuWpvlk+nDs2 VDYbEHUEPeBbcAAoZkIR =kdOi -----END PGP SIGNATURE----- --------------050803050608090306080000 Content-Type: text/plain; charset=UTF-8; name="casperd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="casperd.diff" Index: sbin/casperd/zygote.c =================================================================== --- sbin/casperd/zygote.c (revision 263112) +++ sbin/casperd/zygote.c (working copy) @@ -63,6 +63,9 @@ stdnull(void) if (fd == -1) errx(1, "Unable to open %s", _PATH_DEVNULL); + if (setsid() == -1) + errx(1, "Unable to detach from session"); + if (dup2(fd, STDIN_FILENO) == -1) errx(1, "Unable to cover stdin"); if (dup2(fd, STDOUT_FILENO) == -1) --------------050803050608090306080000-- From owner-freebsd-security@FreeBSD.ORG Fri Mar 14 09:38:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54F33AF6 for ; Fri, 14 Mar 2014 09:38:44 +0000 (UTC) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:140:72e1::ac16:e45e]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD26DB6 for ; Fri, 14 Mar 2014 09:38:44 +0000 (UTC) Received: from t420.rlwinm.de (p54BC48D7.dip0.t-ipconnect.de [84.188.72.215]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 6060CB014 for ; Fri, 14 Mar 2014 09:38:43 +0000 (UTC) Message-ID: <5322CE23.6000904@rlwinm.de> Date: Fri, 14 Mar 2014 10:38:43 +0100 From: Crest User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: [PATCH] casperd should detach from controlling session References: <53221E54.1030600@delphij.net> In-Reply-To: <53221E54.1030600@delphij.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 09:38:44 -0000 On 13.03.2014 22:08, Xin Li wrote: > Hi, Pawel, > > I have noticed that casperd's child (zygote) would still use > controlling session from parent. This can be observed by running > ps -ax on systems running casperd, where the child have a spurious > console associated. > > The attached patch would fix it. May I commit it against -HEAD? > > By the way, the zygote child also closes file descriptor 4 twice > (harmless; it's either sp[0] or the /dev/null which is closed > before starting zygote_main, or before returning from stdnull(). > Based on the construct of the code, I believe both close() can be > omitted. If this makes sense I'll submit a new patch. Wouldn't this patch break support for external monitoring e.g. by daemontools. By convention a daemontools run script is started with its own process group and execs into the service. If a service tries to unconditionally create its own process group it will fail. From owner-freebsd-security@FreeBSD.ORG Fri Mar 14 17:00:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4B453D6 for ; Fri, 14 Mar 2014 17:00:54 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 88851306 for ; Fri, 14 Mar 2014 17:00:54 +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 LAA21140; Fri, 14 Mar 2014 11:00:34 -0600 (MDT) Message-Id: <201403141700.LAA21140@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Mar 2014 09:38:50 -0600 To: Fabian Wenk , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <52D7A944.70604@wenks.ch> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 17:00:54 -0000 Everyone: Two months after this vulnerability was announced, we're still seeing attempts to use the NTP "monitor" query to execute and amplify DDoS attacks. Unfortunately, FreeBSD, in its default configuration, will amplify the attacks if not patched and will still relay them (by sending "rejection" packets), obfuscating the source of the attack, if the system is patched using freebsd-update but the default ntp.conf file is not changed. To avoid this, it's necessary to change /etc/ntp.conf to include the following lines: # Stop amplification attacks via NTP servers disable monitor restrict default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict 127.127.1.0 # Note: Comment out these lines on machines without IPv6 restrict -6 default kod nomodify notrap nopeer noquery restrict -6 ::1 We've tested this configuration on our servers and it successfully prevents the latest patches of FreeBSD 9.x and 10.0 from participating in a DDoS attack, either as a relay or as an amplifier. Some of our own systems which were probed prior to the time we secured them are still receiving a large stream of attack packets, apparently from a botnet. I'd recommend that the lines above be included in the default /etc/ntp.conf in all future releases, and that all systems that use the default ntp.conf without modification be patched automatically via freebsd-update. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Fri Mar 14 20:27:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BC7D3C6 for ; Fri, 14 Mar 2014 20:27:28 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 44AE5AEE for ; Fri, 14 Mar 2014 20:27:27 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::1827:eacd:6af9:9196] (unknown [IPv6:2001:7b8:3a7:0:1827:eacd:6af9:9196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 608635C45; Fri, 14 Mar 2014 21:27:19 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_D39B6696-BA2C-49E6-8250-6CB78DDFBAA5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: NTP security hole CVE-2013-5211? From: Dimitry Andric In-Reply-To: <201403141700.LAA21140@mail.lariat.net> Date: Fri, 14 Mar 2014 21:27:00 +0100 Message-Id: <106CC1B8-932F-44CD-B307-C5B470359ABD@FreeBSD.org> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Fri, 14 Mar 2014 21:01:11 +0000 Cc: freebsd-security@freebsd.org, Fabian Wenk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:27:28 -0000 --Apple-Mail=_D39B6696-BA2C-49E6-8250-6CB78DDFBAA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Mar 2014, at 16:38, Brett Glass wrote: > Two months after this vulnerability was announced, we're still seeing = attempts to use the NTP "monitor" query to execute and amplify DDoS = attacks. Unfortunately, FreeBSD, in its default configuration, will = amplify the attacks if not patched and will still relay them (by sending = "rejection" packets), obfuscating the source of the attack, if the = system is patched using freebsd-update but the default ntp.conf file is = not changed. >=20 > To avoid this, it's necessary to change /etc/ntp.conf to include the = following lines: >=20 > # Stop amplification attacks via NTP servers > disable monitor > restrict default kod nomodify notrap nopeer noquery > restrict 127.0.0.1 > restrict 127.127.1.0 > # Note: Comment out these lines on machines without IPv6 > restrict -6 default kod nomodify notrap nopeer noquery > restrict -6 ::1 >=20 > We've tested this configuration on our servers and it successfully = prevents the latest patches of FreeBSD 9.x and 10.0 from participating = in a DDoS attack, either as a relay or as an amplifier. >=20 > Some of our own systems which were probed prior to the time we secured = them are still receiving a large stream of attack packets, apparently = from a botnet. >=20 > I'd recommend that the lines above be included in the default = /etc/ntp.conf in all future releases, and that all systems that use the = default ntp.conf without modification be patched automatically via = freebsd-update. It looks like you missed = http://www.freebsd.org/security/advisories/FreeBSD-SA-14:02.ntpd.asc = then? Which was released on Jan 14, and has all the instructions how to = patch your system. It also shows this was fixed for all supported = FreeBSD releases. -Dimitry --Apple-Mail=_D39B6696-BA2C-49E6-8250-6CB78DDFBAA5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMjZhwACgkQsF6jCi4glqObRwCg7cZjUNLp401rWUNu6PrVunvu wVEAoOL0+VXdiGWQkIXIWWOipY56b7Vt =Li5p -----END PGP SIGNATURE----- --Apple-Mail=_D39B6696-BA2C-49E6-8250-6CB78DDFBAA5-- From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 01:39:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3B4745E; Sat, 15 Mar 2014 01:39:20 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 996138FA; Sat, 15 Mar 2014 01:39:20 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id EF3501DE48; Fri, 14 Mar 2014 18:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394847560; bh=DNUQ3pXNQlHQwn3FQGEdcHyX4uOlbIDLrwPmgi8/KWg=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=ZNTCTdbrFW7jbY8edeggDG7GzS3ISbet3ucJfuvzYMvYUP/ip/pk+l2jjY/g+ZgE4 CicgmvGIXeWTzcny/2P92HWv5x52ChaG2e+FN+obQ9sOrOouw/sCNWZkJmeaOtn9ZP EXNdWxj370Rzjjq4us5bnL83otJhn+IC3IgoiBnI= Message-ID: <5323AF47.9080107@delphij.net> Date: Fri, 14 Mar 2014 18:39:19 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Brett Glass , Fabian Wenk , freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> In-Reply-To: <201403141700.LAA21140@mail.lariat.net> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------070403090600020800020507" Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 01:39:20 -0000 This is a multi-part message in MIME format. --------------070403090600020800020507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/14/14 08:38, Brett Glass wrote: > We've tested this configuration on our servers and it successfully > prevents the latest patches of FreeBSD 9.x and 10.0 from > participating in a DDoS attack, either as a relay or as an > amplifier. FreeBSD 10.0-RELEASE ships with new default NTP settings, are you talking an earlier RC (before RC4 as r259975), or are you saying 10.0-RELEASE ships with a ntp.conf with wrong defaults? > Some of our own systems which were probed prior to the time we > secured them are still receiving a large stream of attack packets, > apparently from a botnet. > > I'd recommend that the lines above be included in the default > /etc/ntp.conf in all future releases, and that all systems that use > the This is done before the advisory as r259974 (2013-12-27 23:09:40Z). > default ntp.conf without modification be patched automatically via > freebsd-update. We sure can do this as a new advisory but it's not guaranteed to work because end user may have to do manual merge and may choose not to accept these. Note that like I stated before, for attackers it would be efficient to just deliver the packets themselves, plus, the suggested change does not remove their ability to do it because they can still deliver legitimate NTP inquiries with forged source IP to the NTP server which will still give response to the victim (or in your terms, "relay" which is technically inaccurate). An alternative would be to patch ntpd so that it blackholes the monlist request when monitor is disabled (see attachment). Note that while this would stop the response packet from attacker being sent to forged IP address if the packet is requesting for monlist, but not the case I have mentioned before. I'd like to request someone who is more familiar with NTP code to review that for me and see if we should do that as a necessary evil. (For hackers@lists.ntp.org: we have disabled 'monitor' in ntpd by default in [1] and this is an additional step for ntp prior to 4.2.7). [1] http://www.freebsd.org/security/advisories/FreeBSD-SA-14:02.ntpd.asc ; patch at http://security.freebsd.org/patches/SA-14:02/ntpd.patch Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTI69GAAoJEJW2GBstM+nswtIP/Rez/w+jB7bG7E2h+0H4JLfN /Vb0z1TDJ3IWhTee7cbuwAotNcyWv7zo91OWvJiBx8Idi/YCGlkSuSJve1JiwrN7 aFnkbega+JElYs2u9GJwgn0+eHHAWawLDa8NItu6v6G6TY5CZfHNaAXmUv6smak3 QH6MHB8E1h4Y0O525FkFErPxl8UvNpCD+RU7uDFeXof451b99R6CsZxlrfMlfxd3 D580k5NWNITJd/8jrYbd3dEIQyIEJDAGqYRf8vOgslIIi80UqmVJZmwYPZrDdD7L 4IoS7CsB5Zbhq9IT6ZEwRyPI7I1B5YmO3ynYvqZMgLb1mJ2aIT4CeqIflSHm/Cbb VJBJSX4LqUwp8W8mDfFf6ui5nDyNKXDNprZP6m7FquXDjM8E2UdeQMPXvLqwMBDT k7vZ9AELmIgBa+p6CK6cTGPhdUxWXQGkFob/3Fky4WpgZZZm9+vpVYK8IbpyWmNL MD5UukMUJtTE0XZUJb7VoAt3eW05N1spgPr1QGdzdR5OrokVV+XY9mQ7YcTyUMLJ AFieNlpS0rEQIifZeo8BbrUym2ds/hVAlGw8eMabPAVyQ+VLV8zTsmHU+vvaIvZR sDMA+5wr43lyuG5z7ysp84xg54KRu7ET2FlmiKHuaW6rJmBL/iHQlqn8+FAKuJJI EARE14TeLen2MjcXY8T4 =BmL2 -----END PGP SIGNATURE----- --------------070403090600020800020507 Content-Type: text/plain; charset=UTF-8; name="ntp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ntp.diff" Index: contrib/ntp/ntpd/ntp_request.c =================================================================== --- contrib/ntp/ntpd/ntp_request.c (revision 263196) +++ contrib/ntp/ntpd/ntp_request.c (working copy) @@ -1920,7 +1920,6 @@ mon_getlist_0( printf("wants monitor 0 list\n"); #endif if (!mon_enabled) { - req_ack(srcadr, inter, inpkt, INFO_ERR_NODATA); return; } im = (struct info_monitor *)prepare_pkt(srcadr, inter, inpkt, @@ -1965,7 +1964,6 @@ mon_getlist_1( extern int mon_enabled; if (!mon_enabled) { - req_ack(srcadr, inter, inpkt, INFO_ERR_NODATA); return; } im = (struct info_monitor_1 *)prepare_pkt(srcadr, inter, inpkt, --------------070403090600020800020507-- From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 03:35:59 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCB932C2; Sat, 15 Mar 2014 03:35:59 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFDA403; Sat, 15 Mar 2014 03:35:58 +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 VAA27118; Fri, 14 Mar 2014 21:35:53 -0600 (MDT) Message-Id: <201403150335.VAA27118@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Mar 2014 21:30:30 -0600 To: Dimitry Andric From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <106CC1B8-932F-44CD-B307-C5B470359ABD@FreeBSD.org> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <106CC1B8-932F-44CD-B307-C5B470359ABD@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-security@FreeBSD.org, Fabian Wenk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:35:59 -0000 At 02:27 PM 3/14/2014, Dimitry Andric wrote: >It looks like you missed >http://www.freebsd.org/security/advisories/FreeBSD-SA-14:02.ntpd.asc >then? Which was released on Jan 14, and has all the instructions >how to patch your system. I did not miss the advisory. The "solution" given in the advisory -- patching ntpd -- is necessary but not sufficient. The configuration file must also be changed, because the system will still serve as a relay for attacks if the default ntp.conf (or one like it) is used. The lines # Stop amplification attacks via NTP servers disable monitor restrict default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict 127.127.1.0 # Note: Comment out these lines on machines without IPv6 restrict -6 default kod nomodify notrap nopeer noquery restrict -6 ::1 Note that these lines are similar to those in the "workaround" section of the advisory but add the command "disable monitor" and add the "kod" option (which may quell queries from some exploited systems). --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 03:43:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C507655E; Sat, 15 Mar 2014 03:43:57 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 64DCE6AD; Sat, 15 Mar 2014 03:43:57 +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 VAA27172; Fri, 14 Mar 2014 21:43:42 -0600 (MDT) Message-Id: <201403150343.VAA27172@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Mar 2014 21:43:37 -0600 To: d@delphij.net, Fabian Wenk , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <5323AF47.9080107@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323AF47.9080107@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 03:43:57 -0000 At 07:39 PM 3/14/2014, Xin Li wrote: >FreeBSD 10.0-RELEASE ships with new default NTP settings, are you >talking an earlier RC (before RC4 as r259975), or are you saying >10.0-RELEASE ships with a ntp.conf with wrong defaults? The latter. The ntp.conf shipped with 10.0-RELEASE still allows relaying of attacks, even with an ntpd that is patched to prevent amplification. >We sure can do this as a new advisory but it's not guaranteed to work >because end user may have to do manual merge and may choose not to >accept these. True. Perhaps, if freebsd-update finds that ntp.conf is not the default that was shipped with the release, a warning should be given that a manual merge is needed. >Note that like I stated before, for attackers it would be efficient to >just deliver the packets themselves, Attackers have an interest in obfuscating the sources of attacks, since this makes them more difficult to block. We have several patched servers which malicious parties are attempting to use as relays even though they cannot use them to amplify the volume of data sent. Once we altered ntp.conf, we were able to put a stop to this. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 05:34:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 636E37C9; Sat, 15 Mar 2014 05:34:42 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D564F09; Sat, 15 Mar 2014 05:34:42 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 90B301EE0C; Fri, 14 Mar 2014 22:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394861681; bh=stpo7iMLDLAWpLy8zHTn56Y4k9CbddDW1PGThz8E1A4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=AsCiM8CTvgXDEG0+1ZeJ4LwpNvmUS90JmIYmhUcsJJeqcLtuIencx56kwP7lhhuxm cpW+ySiOpM4Qjk7XSOuTCOZhS4qOosame4bZGDrkC1vLoG2NxwAq9t6/DX/eHg8VTO kKI4743XVXztDA24LGSex4bW+I4RZi64XuD5wp0I= Message-ID: <5323E670.5020905@delphij.net> Date: Fri, 14 Mar 2014 22:34:40 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Brett Glass , d@delphij.net, Fabian Wenk , freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323AF47.9080107@delphij.net> <201403150343.VAA27172@mail.lariat.net> In-Reply-To: <201403150343.VAA27172@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 05:34:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/14/14, 8:43 PM, Brett Glass wrote: > At 07:39 PM 3/14/2014, Xin Li wrote: > >> FreeBSD 10.0-RELEASE ships with new default NTP settings, are >> you talking an earlier RC (before RC4 as r259975), or are you >> saying 10.0-RELEASE ships with a ntp.conf with wrong defaults? > > The latter. The ntp.conf shipped with 10.0-RELEASE still allows > relaying of attacks, even with an ntpd that is patched to prevent > amplification. I can't reproduce with fresh install. How did you tested it (or what is missing in the default ntp.conf), can you elaborate? Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTI+ZvAAoJEJW2GBstM+ns18UP/031jrsOBWNewc/WbvpxbE0I KxY1p07drvzE1ftYfwZ7Wi8F9U+f4/qJ1ufCU4DfD3GUUxUm4K3YyKRqBxTCHP+g 4N5FBwS1iKVK9DP1NvBOhLQT2l3X3gHgvi8ICa4MPi/OOTSQx8rlAnPAs2Mq2JS0 FlrTYjHoWpQvT7+46m7Yvz/nqtHOHScrGvbebVB/l8iuDdbtrCJutoHUTPtPH4IP 8Rqx9pMKRBiQ5jFWGQsSqTpveHFXw7d58hjOOQrWSUiz6U+ZinVtbZucpkFFs2WG QZbgNKkeF2rqXvbP/+EPtaTbJ+fQJnrU9c5kNDmZPmDfp2C2qxq6vvZWZcEcE96w D5GzGU64cc1RkqxS2T0NqUDbBWDM+hF1Smxxy1zMo+JDNz3rtouvuXQrQi1U5KRl JUMpbRDI1QOZFlmz/ps0wyq5lDYUFNlOlwDAj1vXFsIw9kROMfZmIQ0M35gnWIEv AyR6RmxPcbpRqouil1lmzDhfNY2z6HG0W5XKQGRULZWB+6dSX05VSXUR7sQiJFiu 7izQ3BdFcG9aL85m/toH8c1qPu/UoZ9rAQ6+gnSNT0eoPXy7bWnciSvlNg9GfpC/ a9XwixLCggI4fV+T+yzFbzUe2PzSBEwx4k1/XO3VDLtY/NUTmiZsIZYySelvkOWq 1CySClbtRbT+AtlDdCfQ =6zOm -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 09:32:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BA6F27F; Sat, 15 Mar 2014 09:32:02 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id EE4DC2E9; Sat, 15 Mar 2014 09:32:01 +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 DAA29130; Sat, 15 Mar 2014 03:31:39 -0600 (MDT) Message-Id: <201403150931.DAA29130@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 15 Mar 2014 03:30:41 -0600 To: d@delphij.net, d@delphij.net, Fabian Wenk , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <5323E670.5020905@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323AF47.9080107@delphij.net> <201403150343.VAA27172@mail.lariat.net> <5323E670.5020905@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 09:32:02 -0000 At 11:34 PM 3/14/2014, Xin Li wrote: >I can't reproduce with fresh install. How did you tested it (or what >is missing in the default ntp.conf), can you elaborate? I have tested it under actual attack. Without the lines I mentioned in /etc/ntp.conf, the server will respond to monitor queries with rejection packets of the same size as the attack packets. If the source addresses of the attack packets are spoofed, the attack is relayed. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 17:18:03 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D816F3D; Sat, 15 Mar 2014 17:18:03 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D2B7EF0; Sat, 15 Mar 2014 17:18:03 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id A509B1ED9E; Sat, 15 Mar 2014 10:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1394903882; bh=a9ohnwa2smmgDUliYu6yqix4grKodmeZNkBOAaqj3Qo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=K2vmddoegEr8TUZ6XneBJjNt12w3PtPOkSPGJduWV1Yr2G+KcW7JUzE+QIss5aVX/ AlQAZrRGNehfmpg4zYMWoBc8wymmi+SzpwxXgkXs29IMaxElp3cMVy/gpD7d9mZJqB cHCgGghV5MiHNojKjZ+sWonlUK1SZPSPqGwqktU4= Message-ID: <53248B48.5040108@delphij.net> Date: Sat, 15 Mar 2014 10:18:00 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Brett Glass , d@delphij.net, Fabian Wenk , freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323AF47.9080107@delphij.net> <201403150343.VAA27172@mail.lariat.net> <5323E670.5020905@delphij.net> <201403150931.DAA29130@mail.lariat.net> In-Reply-To: <201403150931.DAA29130@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 17:18:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/15/14, 2:30 AM, Brett Glass wrote: > At 11:34 PM 3/14/2014, Xin Li wrote: > >> I can't reproduce with fresh install. How did you tested it (or >> what is missing in the default ntp.conf), can you elaborate? > > I have tested it under actual attack. > > Without the lines I mentioned in /etc/ntp.conf, the server will > respond to monitor queries with rejection packets of the same size > as the attack Either it wouldn't or my test was wrong. My test was 'ntpdc -c monlist' and tcpdump. > packets. If the source addresses of the attack packets are spoofed, > the attack is relayed. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTJItIAAoJEJW2GBstM+nsSAAP/3L0Z+c+rd5HLDjtVZ2zvjMD rziFxOUDgIqXv/Ph6vxPwgwYQhXWf6/I6Um/Upacb5AiVWffHyogkuBBGuxvGu1T k2Vz0HzCY3HBMJvO/spQ2vbkfKYLuyrZtKJQMuB7B+wO7wdeKX2hAUDoHN4pKPTt uul5B3cUwZmlAa8kyblWSJHf6bmINKjRZ+R+oKQpYwBBm0JaPWxZgKOCceHWrVTy YhK+IcEtosq5Fw5QS17+J3Qh++evyjVtGP0CeanxLsH108aAPU4WJ6yfzynUQeeX B3U8dviQXsT0XrH5U+ADoF0Y+ypUmyRNLtJShkgQhsqTME2iTOYZcotDj1Ads0Tm kgogo21vTfYW5DT9BCqrDyhba2RVdGHrl9VytyLDws6lDbbFllG0J9nrvrh8O+Ow 8VSb/ENePAMuRlYGxsZ9kob436+/sBT4E7TIVuQM0DwVs6dR16tiVxTCdGnFKe1D BYcwEYE9oGUeGXo/S6VMyO8qDtHGHIFomO8o8LXL6EB2dIUAoWlFZsre+HInDOkn TlTaMcOmemS3ylwpoOoaggSV/6JV+k9ks41WHLy2UjEBHM+Ur9DsRgVhNY513Ouj TuNEiBBwZOj3Y7bAOfKAOyKcKRVcY7CeYz1cq/VgLRbiw/pmHMu1TqRafKF0RHi7 Lhu+UUAIZMtHiDms52UZ =xChL -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 18:33:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77B7197D; Sat, 15 Mar 2014 18:33:49 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 15E84852; Sat, 15 Mar 2014 18:33:48 +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 MAA04912; Sat, 15 Mar 2014 12:33:31 -0600 (MDT) Message-Id: <201403151833.MAA04912@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 15 Mar 2014 12:32:37 -0600 To: d@delphij.net, d@delphij.net, Fabian Wenk , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <53248B48.5040108@delphij.net> References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323AF47.9080107@delphij.net> <201403150343.VAA27172@mail.lariat.net> <5323E670.5020905@delphij.net> <201403150931.DAA29130@mail.lariat.net> <53248B48.5040108@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ollivier Robert , hackers@lists.ntp.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 18:33:49 -0000 At 11:18 AM 3/15/2014, Xin Li wrote: >Either it wouldn't or my test was wrong. My test was 'ntpdc -c >monlist' and tcpdump. My test was to actually expose the server to the attack I was experiencing. Note that these packets might not have been exactly the same ones that are sent by ntpdc. For every packet it received, the server sent a rejection to the source IP, which was spoofed. The relaying stopped when I added the lines I mentioned in my previous message to the configuration file. It is good practice to have those lines in the file anyway, to provide effective access control. If one does not intend to be running a public NTP server, the server should not be open to the world; in fact, it should probably be behind a stateful firewall that does not accept packets destined for UDP port 123 from the Internet at large unless they are known to be responses to queries. I've implemented this in the IPFW rules of all of my servers. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sat Mar 15 22:34:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C40F6C9E for ; Sat, 15 Mar 2014 22:34:38 +0000 (UTC) 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 8F628CB7 for ; Sat, 15 Mar 2014 22:34:38 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2F30PRD073448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 14 Mar 2014 20:00:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5323C244.8050101@freebsd.org> Date: Fri, 14 Mar 2014 20:00:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Brett Glass , Fabian Wenk , freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> In-Reply-To: <201403141700.LAA21140@mail.lariat.net> Content-Type: multipart/mixed; boundary="------------010709070803080609010703" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 22:34:38 -0000 This is a multi-part message in MIME format. --------------010709070803080609010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/14/14, 8:38 AM, Brett Glass wrote: > Everyone: > > Two months after this vulnerability was announced, we're still > seeing attempts to use the NTP "monitor" query to execute and > amplify DDoS attacks. Unfortunately, FreeBSD, in its default > configuration, will amplify the attacks if not patched and will > still relay them (by sending "rejection" packets), obfuscating the > source of the attack, if the system is patched using freebsd-update > but the default ntp.conf file is not changed. > > To avoid this, it's necessary to change /etc/ntp.conf to include the > following lines: > > # Stop amplification attacks via NTP servers > disable monitor > restrict default kod nomodify notrap nopeer noquery > restrict 127.0.0.1 > restrict 127.127.1.0 > # Note: Comment out these lines on machines without IPv6 > restrict -6 default kod nomodify notrap nopeer noquery > restrict -6 ::1 > > We've tested this configuration on our servers and it successfully > prevents the latest patches of FreeBSD 9.x and 10.0 from > participating in a DDoS attack, either as a relay or as an amplifier. the best solution is to add a firewall stateful rule so that the ONLY port 123 udp packet that gets in is one that is a response to one you sent out first. I include for fun my ipfw script. (slightly anonimised.. hope I didn't break it doing so, last i checked the average packet only hit about 6 rules in this set. and interface and local address are only checked once. it's about as efficient as one can get on an ipfw firewall. beware the script puts the rules in out of order.. > > Some of our own systems which were probed prior to the time we > secured them are still receiving a large stream of attack packets, > apparently from a botnet. yeah me too.. 500 pps up until a few ours ago.. then it stopped > > I'd recommend that the lines above be included in the default > /etc/ntp.conf in all future releases, and that all systems that use > the default ntp.conf without modification be patched automatically > via freebsd-update. it already is. > > --Brett Glass > > _______________________________________________ > 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" > --------------010709070803080609010703 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="rc.firewall.jre" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rc.firewall.jre" #!/bin/sh IPFW=/sbin/ipfw SYSCTL=/sbin/sysctl set -x #Here is a revised version fo hte firewall rules. # includes the fib fix and the NAT rules integrated. # ipfw and sysctl defiend tp "echo" so that the script does nothing. # run as "sh firewall3.sh |sort -n -k 4 >/tmp/xx" to see the output as injected. # rules are not injected in order so for debug output # the sort is needed to see output in final form. # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi INCLUDE_COMMENTS="YES" HAVE_TUNNEL="NO" # nets of form a.b.c.d/xx from rc.conf iif=${firewall_simple_iif} iip=${firewall_simple_inet%%/[0-9]*} oif=${firewall_simple_oif} oip=${firewall_simple_onet%%/[0-9]*} DEFAULT_SET=0 APP_SET=1 APP_BLOCK_SET=2 NAT_SET=3 ${IPFW} disable firewall sleep 1 ${IPFW} -q -f flush # For each interface set up 4 sets of rules # # rules incoming to that interface to us # rules incoming to that interface not for us (for routing) # rules outgoing on that interface from us # rules outgoing on that interface not from us # # Allow 200 numbers for each rule set and 1000 for each interface OUR_INCOMING=0 OUR_OUTGOING=0 OTHER_INCOMING=0 OTHER_OUTGOING=0 NEXTRULE=0 #decide how many number between rules and keep the kernel in sync with this RULESKIP=2 ${SYSCTL} net.inet.ip.fw.autoinc_step=$RULESKIP # Make sure that pipes and NAT return to processing at the next rule number ${SYSCTL} net.inet.ip.fw.one_pass=0 ################################################################# ################################################################# # special values to set up pre-processing for a NAT'd tunnel # e.g. from home to office. not fully set up yet... ignore ################################################################# ################################################################# TUN_REMOTE=10.0.1.2 VPN_SRC=18.0.0.1 VPN_NET=18.0.0.0/24 TUN=tun0 ############################################################## # N.B. port lists must contain 30 elements or less. # These are for SESSIONS. stateful behaviour is expected # to keep these sessions alive. # We may have to tune dynamic timeouts ############################################################## # Expected services handled, (inwards): # # == udp == UDP_INPORTS_SYS=53 # We will serve dns so we need this # === tcp === # TCP ports we enable as soon as possible #----------------------------------------------------- TCP_INPORTS_SYS=1234 # admin ssh $IPFW table add 2 $SECONDARY1 # dns secondary $IPFW table add 2 $SECONDARY2 ${IPFW} table add 13 10.0.0.0/8 ${IPFW} table add 13 172.16.0.0/12j ${IPFW} table add 13 192.168.0.0/16 ${IPFW} table add 13 0.0.0.0/8 ${IPFW} table add 13 169.254.0.0/16 ${IPFW} table add 13 192.0.2.0/24 ${IPFW} table add 13 224.0.0.0/4 ${IPFW} table add 13 240.0.0.0/4 TCP_DNS_ZONE=53 # DNS ZONES to secondaries # TCP ports we only enable when we turn on client services #----------------------------------------------------- TCP_INPORTS_APP=25 # Mail inwards TCP_INPORTS_APP=$TCP_INPORTS_APP,993 TCP_INPORTS_APP=$TCP_INPORTS_APP,995 TCP_INPORTS_APP=$TCP_INPORTS_APP,597 TCP_INPORTS_APP=$TCP_INPORTS_APP,514 TCP_INPORTS_APP=$TCP_INPORTS_APP,80 TCP_INPORTS_APP=$TCP_INPORTS_APP,443 ############################################################## # Known remote services we use are: # We initiate these sessions.. # ======= udp ======= UDP_REMPORTS_SYS=53 # DNS 53 UDP_REMPORTS_SYS=$UDP_REMPORTS_SYS,67 # DHCP 67 UDP_REMPORTS_SYS=$UDP_REMPORTS_SYS,123 # NTP 123 # ======= tcp ======= TCP_REMPORTS_SYS=53 # DNS 53 .. actually I probably don't need this #------------------------------------------------------- TCP_REMPORTS_BACKUP=22 # ports used out the internal interface. # Machine does not route. just has 2 interfaces. # ===== ICMP ======= ############################################################## # add $NEXTRULE set {setnumber} {rule} writerule () { SET=$1 shift ${IPFW} -q add $NEXTRULE set $SET $@ NEXTRULE=$(($NEXTRULE + $RULESKIP)) } # skipto {setnumber} {rules-to-skip} rulebody skipcount () { SET=$1 shift SKIPDIST=$(($RULESKIP * $1)) shift ${IPFW} -q add $NEXTRULE set $SET skipto $(($NEXTRULE + $SKIPDIST )) $@ NEXTRULE=$(($NEXTRULE + $RULESKIP)) } if [ "$INCLUDE_COMMENTS" = "YES" ] then # set {setnumber} // {commnet} writecomment () { SET=$1 shift ${IPFW} -q add $NEXTRULE set $SET "//" $@ NEXTRULE=$(($NEXTRULE + $RULESKIP)) } else writecomment() { } fi # writefilter baserule ifname # sets up a filter set as: # YY00 skipto X000 inward # YY10 skipto X500 outward # # and then adds the base filter sections further down. # you should set up one of these per interface. # # [...] # X000 skipto X200 to us # [...] # routed packet rules go here # X200 # [...] # rules for our packets go here # X500 skipto X700 from us # [...] # routed packet rules go here # X700 # [...] # rules for our packets go here # # Leaves OUR_INCOMING OUR_OUTGOING OTHER_INCOMING OTHER_OUTGOING # set up to where more rules should go to writefilter () { # rule number, interface name, interface address # Write an interface filter in the filters section # splitting into two sectins (in and out) local TARGET_RULE=$1 local IFACE=$2 local IPADDR=$3 local INCOMING=${TARGET_RULE} local OUTGOING=$(( ${TARGET_RULE} + 500 )) if [ ${IFACE} = "lo0" ] # Optimise for lo0 then writecomment ${DEFAULT_SET} "filter out packets on ${IFACE}" writerule ${DEFAULT_SET} skipto ${INCOMING} ip from any to any in recv ${IFACE} writerule ${DEFAULT_SET} skipto ${OUTGOING} ip from any to any out xmit ${IFACE} #just have two simple sections this is already probably too much OUR_INCOMING=${INCOMING} OUR_OUTGOING=${OUTGOING} else NEXTRULE=${NEXTFILTER} writecomment ${DEFAULT_SET} "filter out packets on ${IFACE}" writerule ${DEFAULT_SET} skipto ${INCOMING} ip from any to any in recv ${IFACE} writerule ${DEFAULT_SET} skipto ${OUTGOING} ip from any to any out xmit ${IFACE} NEXTFILTER=${NEXTRULE} # then further split those sections into "ours and other" NEXTRULE=${INCOMING} OUR_INCOMING=$(( ${INCOMING} + 200 )) writerule ${DEFAULT_SET} skipto $OUR_INCOMING ip from any to ${IPADDR} writecomment ${DEFAULT_SET} "packets not addressed to us coming in on ${IFACE}" OTHER_INCOMING=$NEXTRULE NEXTRULE=${OUR_INCOMING} writecomment ${DEFAULT_SET} "packets addressed to US comin in on ${IFACE}" OUR_INCOMING=$NEXTRULE NEXTRULE=${OUTGOING} OUR_OUTGOING=$(( ${OUTGOING} + 200 )) writerule ${DEFAULT_SET} skipto ${OUR_OUTGOING} ip from ${IPADDR} to any writecomment ${DEFAULT_SET} "Packets NOT from us, going out on ${IFACE}" OTHER_OUTGOING=$NEXTRULE NEXTRULE=$OUR_OUTGOING writecomment ${DEFAULT_SET} "packets from us, going out ${IFACE}" OUR_OUTGOING=$NEXTRULE fi } if [ ${HAVE_TUNNEL} = "YES" ] then if ${IPFW} nat 123 config if ${iif} log reset same_ports then NAT_OP="nat 123" else NAT_OP="count" # for testing when we don't have NAT loaded echo "Need to load NAT kernel module" echo "adding dummy rules for NAT" fi fi ############################################################## ############################################################## # Special initial rules # # Leave space at front for manually debugging etc. # ############################################################## ############################################################## NEXTRULE=400 # should put standard non spoofing rules from rc.firewal here (except better ones) NEXTFILTER=1000 ############################################################## ############################################################## # loopback # # This is optimised a bit. (see above) # ############################################################## ############################################################## # First for efficiency put Loopback spoofing test in right # after the lo0 filter. Packets to or from 127.0.0.1 die right here # if they didn't get sent to lo0 procesing writefilter 2000 "lo0" "127.0.0.1" NEXTRULE=${NEXTFILTER} writerule ${DEFAULT_SET} deny all from 127.0.0.1 to any writerule ${DEFAULT_SET} deny all from any to 127.0.0.1 NEXTFILTER=$NEXTRULE NEXTRULE=$OUR_INCOMING writerule ${DEFAULT_SET} allow all from any to any NEXTRULE=$OUR_OUTGOING writerule ${DEFAULT_SET} allow all from any to any ############################################################## ############################################################## # Interface 0 # ############################################################## ############################################################## writefilter 3000 ${oif} ${oip} ############################################################## # INCOMING packets ADDRESSED TO US # # We should only accept them if we export a known service # # or they are a response to an outgoing packet of our own. # ############################################################## NEXTRULE=$OUR_INCOMING # we will only have dynamic rules for locally connected sessions # that do not do rate control or NAT, so we can skip these expensive # operations by utilising this fact. writerule ${DEFAULT_SET} check-state writerule ${DEFAULT_SET} reject ip from table\(13\) to any writerule ${DEFAULT_SET} reject ip from any to table\(13\) if [ ${HAVE_TUNNEL} = "YES" ] then # check incoming packets against known NAT sessions writecomment ${NAT_SET} "check incoming packets against known NAT sessions and dispatch them." writerule ${NAT_SET} ${NAT_OP} ip from any to ${VPN_SRC} # A NAT'd packet will now look like this: accept it. We're done. writerule ${NAT_SET} accept ip from any to ${TUN_REMOTE} # Because we set one_pass to 0, packets that are NOT NAT'd # will be left untouched and will be for us. # We need to handle these when they return to us # along with any that were not sent for NATing. fi #================================================================ # set keep-state for these to skip future NAT and pipe calls. writerule ${DEFAULT_SET} allow tcp from any to any ${TCP_INPORTS_SYS} setup keep-state writerule ${DEFAULT_SET} allow udp from any to any ${UDP_INPORTS_SYS} keep-state writerule ${DEFAULT_SET} allow tcp from table\(2\) to any ${TCP_DNS_ZONE} keep_state writerule ${APP_SET} allow tcp from any to any ${TCP_INPORTS_APP} setup keep-state writerule ${APP_SET} allow udp from any to any ${UDP_INPORTS_APP} keep-state # IP fragments for UDP NFS # check the safety of this writerule ${DEFAULT_SET} allow udp from any to any frag # ICMP # there are some one might want to stop writerule ${DEFAULT_SET} allow icmp from any to any keep-state # an alternative... (thought we probably want more) # writerule ${DEFAULT_SET} allow icmp from any to any icmptype 0,8 keep-state writerule ${DEFAULT_SET} drop ip from any to any ################################################################# # Incoming packets not for us. # # There is just no excuse for any incoming packet not for us. # # Throw it away. hmm only exception.. dhcp broadcast? # ################################################################# NEXTRULE=$OTHER_INCOMING writerule ${DEFAULT_SET} drop ip from any to any ################################################################# # OUTGOING packets FROM US # # these should either be reponses to incoming service requests # # or our own service requests going out. Either way, we should # # let them go and make a rule for the return packet. # ################################################################# NEXTRULE=$OUR_OUTGOING writecomment ${DEFAULT_SET} "outgoing packets from sesions we have already aproved are ok" writerule ${DEFAULT_SET} check-state # writecomment ${DEFAULT_SET} "remember any outgoing session we initiate" # writerule ${DEFAULT_SET} allow tcp from any to any setup keep-state # This is redundant if we allow the above rule. writecomment ${DEFAULT_SET} "remeber any outgoing session we allow" writerule ${DEFAULT_SET} allow tcp from any to any ${TCP_REMPORTS_SYS} setup keep-state writerule ${DEFAULT_SET} allow udp from any to any ${UDP_REMPORTS_SYS} keep-state # when we turn on, allow already running sessiosn to continue if we know about them (and send a packet). writerule ${DEFAULT_SET} allow tcp from any to any established keep-state writerule ${DEFAULT_SET} allow icmp from any to any keep-state writerule ${DEFAULT_SET} drop ip from any to any ################################################################# # Outgoing packets not from us. # # If it's not from us it must be from the tunnel in which case # # it is a NAT candidate. If not then throw it away. # ################################################################# NEXTRULE=$OTHER_OUTGOING if [ ${HAVE_TUNNEL} = "YES" ] then # only NAT packets we need to. Why waste time with others? writerule ${NAT_SET} ${NAT_OP} all from ${TUN_REMOTE} to any recv ${TUN} # successfully NAT'd packets will look like this. writerule ${NAT_SET} accept all from ${VPN_SRC} to any fi writerule ${DEFAULT_SET} drop ip from any to any if [ "$iif" != "$oif" ] then ############################################################## ############################################################## # Interface 1 In INLINE mode this goes to the cloud # ############################################################## ############################################################## writefilter 4000 ${iif} ${iip} NEXTRULE=$OUR_INCOMING writerule ${DEFAULT_SET} check-state # Only allow incoming packets on sessions we initiated. writerule ${DEFAULT_SET} allow icmp from any to any icmptype 0,3,8 keep-state writerule ${DEFAULT_SET} deny log ip from any to any # Packets coming in here that are not for us? drop them. NEXTRULE=$OTHER_INCOMING writerule ${DEFAULT_SET} deny log ip from any to any # packets FROM US going out this interface NEXTRULE=$OUR_OUTGOING writerule ${DEFAULT_SET} check-state # may be redundant due to the "keep-state" in the next rule writerule ${DEFAULT_SET} allow tcp from any to any ${TCP_REMPORTS_BACKUP} setup keep-state writerule ${DEFAULT_SET} deny ip from any to any # packets NOT FROM US going out this interface,.. there shoudn't be any. NEXTRULE=$OTHER_OUTGOING writerule ${DEFAULT_SET} deny log ip from any to any fi ############################################################## ############################################################## # Tunnel interface # ############################################################## ############################################################## if [ ${HAVE_TUNNEL} = "YES" ] then writefilter 5000 tun0 me # punt on addr.. we have no idea NEXTRULE=$OUR_INCOMING writerule ${DEFAULT_SET} allow ip from any to any NEXTRULE=$OTHER_INCOMING writerule ${DEFAULT_SET} allow ip from any to any NEXTRULE=$OUR_OUTGOING writerule ${DEFAULT_SET} allow ip from any to any NEXTRULE=$OTHER_OUTGOING writerule ${DEFAULT_SET} allow ip from any to any fi ############################################################## ############################################################## # Any other interfaces not mentioned # ############################################################## ############################################################## NEXTRULE=${NEXTFILTER} writecomment ${DEFAULT_SET} "handle other intefaces" writerule ${DEFAULT_SET} deny ip from any to any # post rule stuff ${IPFW} set enable $DEFAULT_SET ${IPFW} set disable $APP_SET ${IPFW} set disable $APP_BLOCK_SET # not written yet ${IPFW} set disable $NAT_SET # nat rules disabled if written. not ready.. ${IPFW} enable firewall # ---- EOF ---- --------------010709070803080609010703-- From owner-freebsd-security@FreeBSD.ORG Sun Mar 16 07:21:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4FA8177; Sun, 16 Mar 2014 07:21:38 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A45F29DD; Sun, 16 Mar 2014 07:21:38 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 93C6B3EB45; Sun, 16 Mar 2014 07:21:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s2G7LTQk034940; Sun, 16 Mar 2014 07:21:29 GMT (envelope-from phk@phk.freebsd.dk) To: Julian Elischer Subject: Re: NTP security hole CVE-2013-5211? In-reply-to: <5323C244.8050101@freebsd.org> From: "Poul-Henning Kamp" References: <52CEAD69.6090000@grosbein.net> <81785015-5083-451C-AC0B-4333CE766618@FreeBSD.org> <52CF82C0.9040708@delphij.net> <86d2jud85v.fsf@nine.des.no> <52D7A944.70604@wenks.ch> <201403141700.LAA21140@mail.lariat.net> <5323C244.8050101@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 16 Mar 2014 07:21:28 +0000 Message-ID: <34939.1394954488@critter.freebsd.dk> Cc: freebsd-security@freebsd.org, Fabian Wenk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 07:21:39 -0000 In message <5323C244.8050101@freebsd.org>, Julian Elischer writes: >the best solution is to add a firewall stateful rule so that the ONLY >port 123 udp packet that gets in is one that is a response to one you >sent out first. And to deny any packet which is too short: deny udp from any to any dst-port 123 iplen 0-75 -- 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 Sun Mar 16 15:19:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF0D3678 for ; Sun, 16 Mar 2014 15:19:54 +0000 (UTC) Received: from r2d2.bromirski.net (r2d2.bromirski.net [IPv6:2001:470:d067:bad::f00d]) by mx1.freebsd.org (Postfix) with ESMTP id 70E212AB for ; Sun, 16 Mar 2014 15:19:54 +0000 (UTC) Received: from [192.168.33.128] (unknown [193.19.143.146]) by r2d2.bromirski.net (Postfix) with ESMTPSA id 28F1C3360AF for ; Sun, 16 Mar 2014 16:19:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1875\)) Subject: Re: freebsd-security Digest, Vol 478, Issue 3 From: =?utf-8?Q?=C5=81ukasz_Bromirski?= In-Reply-To: Date: Sun, 16 Mar 2014 16:18:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1875) X-Mailman-Approved-At: Sun, 16 Mar 2014 21:28:08 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 15:19:54 -0000 On 16 Mar 2014, at 13:00, freebsd-security-request@freebsd.org wrote: > Message: 3 > From: Julian Elischer > Subject: Re: NTP security hole CVE-2013-5211? > Message-ID: <5323C244.8050101@freebsd.org> > Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"flowed" >=20 > the best solution is to add a firewall stateful rule so that the ONLY=20= > port 123 udp packet that gets in is one that is a response to one you=20= > sent out first. No. This is adding compexity to things which shouldn=E2=80=99t be complex. Of course multiple of layers defend better than single one, but not all FreeBSD boxes run with firewall turned on, and we shouldn=E2=80=99= t require people to have it on for =E2=80=98secure=E2=80=99 ntp operation. /etc/ntp.conf should by default have secure posture and shouldn=E2=80=99t require any additional firewalling to remain so. --=20 "There's no sense in being precise when | =C5=81ukasz = Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net= From owner-freebsd-security@FreeBSD.ORG Mon Mar 17 09:24:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97B7D545 for ; Mon, 17 Mar 2014 09:24:45 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7B1888 for ; Mon, 17 Mar 2014 09:24:44 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id A3396298; Mon, 17 Mar 2014 10:24:36 +0100 (CET) Date: Mon, 17 Mar 2014 10:26:37 +0100 From: Pawel Jakub Dawidek To: d@delphij.net Subject: Re: [PATCH] casperd should detach from controlling session Message-ID: <20140317092635.GA1645@garage.freebsd.pl> References: <53221E54.1030600@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <53221E54.1030600@delphij.net> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 09:24:45 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2014 at 02:08:36PM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi, Pawel, >=20 > I have noticed that casperd's child (zygote) would still use > controlling session from parent. This can be observed by running ps > - -ax on systems running casperd, where the child have a spurious > console associated. >=20 > The attached patch would fix it. May I commit it against -HEAD? Hmm, daemon(3) does call setsid(2) already... Are you sure casperd wasn't running with -F? > By the way, the zygote child also closes file descriptor 4 twice > (harmless; it's either sp[0] or the /dev/null which is closed before > starting zygote_main, or before returning from stdnull(). Based on > the construct of the code, I believe both close() can be omitted. If > this makes sense I'll submit a new patch. I'd prefer to leave stdnull() as-is. I open /dev/null there and I close it in the same function. Not closing it there would make it confusing and would make function reuse error-prone. If 'sock' has even higher number we will call close(2) on non-open descriptors, but this is because there is no closerange(from, to) syscall. If you meant something else, do send me the patch and I can comment further. > Index: sbin/casperd/zygote.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sbin/casperd/zygote.c (revision 263112) > +++ sbin/casperd/zygote.c (working copy) > @@ -63,6 +63,9 @@ stdnull(void) > if (fd =3D=3D -1) > errx(1, "Unable to open %s", _PATH_DEVNULL); > =20 > + if (setsid() =3D=3D -1) > + errx(1, "Unable to detach from session"); > + > if (dup2(fd, STDIN_FILENO) =3D=3D -1) > errx(1, "Unable to cover stdin"); > if (dup2(fd, STDOUT_FILENO) =3D=3D -1) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --wac7ysb48OaltWcw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlMmv8sACgkQForvXbEpPzRIBQCgx+4s/vLHhrWq1ljSWmpN9+w3 A+EAniOzeuOJh/G97lJdUiUBpriD4ZQa =h4VG -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-security@FreeBSD.ORG Tue Mar 18 01:09:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ED4A148; Tue, 18 Mar 2014 01:09:06 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 518EA24D; Tue, 18 Mar 2014 01:09:06 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 60FCC20459; Mon, 17 Mar 2014 18:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1395104945; bh=wArmkiKpeT3j0sqH0/BlFkBNGANorqx8bxDKkzRu0fE=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=f/UvFF6QXQ1ZbuYiW1K3va7S9MFkPIGDhANkwtr9GrwnQKSKMx4xGtZA1WQKYMyU2 IeURQsMiiIgb1eA+vDu4icIVQnTfEhVaZLG9K4drs+ZSU/0QEtzoXWqr08KpiX7yNe eOH1IqElWFRBfSiuycvXDuOFVnSmKiNd85aKVsIE= Message-ID: <53279CB0.1020409@delphij.net> Date: Mon, 17 Mar 2014 18:09:04 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Pawel Jakub Dawidek , d@delphij.net Subject: Re: [PATCH] casperd should detach from controlling session References: <53221E54.1030600@delphij.net> <20140317092635.GA1645@garage.freebsd.pl> In-Reply-To: <20140317092635.GA1645@garage.freebsd.pl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 01:09:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/17/14 02:26, Pawel Jakub Dawidek wrote: > On Thu, Mar 13, 2014 at 02:08:36PM -0700, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Hi, Pawel, >> >> I have noticed that casperd's child (zygote) would still use >> controlling session from parent. This can be observed by running >> ps - -ax on systems running casperd, where the child have a >> spurious console associated. >> >> The attached patch would fix it. May I commit it against -HEAD? > > Hmm, daemon(3) does call setsid(2) already... Are you sure casperd > wasn't running with -F? Oh, sure daemon(3) indeed does setsid(2) but casperd calls it after zygote_init() so it has no effect to the zygote process, maybe something like this instead? Index: sbin/casperd/casperd.c =================================================================== - --- sbin/casperd/casperd.c (revision 263272) +++ sbin/casperd/casperd.c (working copy) @@ -671,9 +671,6 @@ main(int argc, char *argv[]) pjdlog_prefix_set("(casperd) "); pjdlog_debug_set(debug); - - if (zygote_init() < 0) - - pjdlog_exit(1, "Unable to create zygote process"); - - pfh = pidfile_open(pidfile, 0600, &otherpid); if (pfh == NULL) { if (errno == EEXIST) { @@ -699,6 +696,9 @@ main(int argc, char *argv[]) pjdlog_debug(1, "PID stored in %s.", pidfile); } + if (zygote_init() < 0) + pjdlog_exit(1, "Unable to create zygote process"); + /* * Register core services. */ >> By the way, the zygote child also closes file descriptor 4 twice >> (harmless; it's either sp[0] or the /dev/null which is closed >> before starting zygote_main, or before returning from stdnull(). >> Based on the construct of the code, I believe both close() can be >> omitted. If this makes sense I'll submit a new patch. > > I'd prefer to leave stdnull() as-is. I open /dev/null there and I > close it in the same function. Not closing it there would make it > confusing and would make function reuse error-prone. > > If 'sock' has even higher number we will call close(2) on non-open > descriptors, but this is because there is no closerange(from, to) > syscall. > > If you meant something else, do send me the patch and I can > comment further. > >> Index: sbin/casperd/zygote.c >> =================================================================== >> >> - --- sbin/casperd/zygote.c (revision 263112) >> +++ sbin/casperd/zygote.c (working copy) @@ -63,6 +63,9 @@ >> stdnull(void) if (fd == -1) errx(1, "Unable to open %s", >> _PATH_DEVNULL); >> >> + if (setsid() == -1) + errx(1, "Unable to detach from >> session"); + if (dup2(fd, STDIN_FILENO) == -1) errx(1, "Unable to >> cover stdin"); if (dup2(fd, STDOUT_FILENO) == -1) > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTJ5ywAAoJEJW2GBstM+nshbgP/iRGivWPqnhjQPKbCNSGuG0Z KZ3BKwD5rOt2DPMUxUd6fx9GJxaGZ6jM1NZGJko8wjwNHqBqShHNErJw19MhdTs/ x+2ROnLYf1RLgpwrLG8u50y4FU2MWViizw23foJksnu/pcdkLLo7pWzKOphabBZC 1N2EnM9E4M/iIMJyLH0dl9r4chLQqj6+KeKB2HX5It+HnRcuV/07Ut0aGomQaaNn vZ+pwTAppXbgC//OYFoTYzaeaXfOCuHe+UtBsjAHMsQiDpG0ITCzae4MYcVwQeVc w7DPIVJtUQ1efLc91dbqbHpSh8mymkOKV3EKsFG012RMzBZmksBD7CfexV8pAHr3 /l1sZCbqfg/siUVoU4lrpIOJz4/BeeWUNahYv8DCneQneIi9gH0SPnI8DKR3Zu9b cp0VwsxFLtdyW15m6+lTyna286HQWhhZrfoogGvrLji/rZTWD7e/UTxLC7aV4MHK sV/wAEMOVLnNv9h3FZdAtxTNYsj5QNfGjaRCBNfbZq1WGxnf27kHZJBQVKkOt8bq CzCFmwVlkD4kPNMbY3WLL4oWbKVzmzE4yO/w6imSW3mmSCsNdNkA09zimOxD5ENh Bkhr97P/2b10ftpBeckMuVweTdCNemlMu4YrlodeKP337qYJW1zPcWyH6/tVBvtw Npm65R1ePctDfdjzePrG =hyg9 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Mar 18 04:04:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F34AF37 for ; Tue, 18 Mar 2014 04:04:10 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6B941379 for ; Tue, 18 Mar 2014 04:04:10 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 144EA3AE6E for ; Mon, 17 Mar 2014 20:56:27 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <5323C244.8050101@freebsd.org> Date: Mon, 17 Mar 2014 20:56:27 -0700 Message-ID: <29310.1395114987@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 04:04:10 -0000 In message <5323C244.8050101@freebsd.org>, Julian Elischer wrote: >the best solution is to add a firewall stateful rule so that the ONLY >port 123 udp packet that gets in is one that is a response to one you >sent out first. Point of order Mr. Chaiman... Two or three weeks ago, I woke up one day and found that (for no immediately obvious reason) I had essentially zero outbound bandwidth... a fact which distressed me greatly. In short order I was able, on my own, to determine that the problem was a relatively large outflow of packets from my server, all originating from UDP port 123. Several kind persons on the freebsd-questions mailing list advised me at that time that I was being used/abused as an NTP attack amplifier, and that the simple and easy solution was to block all inbound (from other than my local network) packets directed at my UDP port 123, which I did, immediately, with a new ipfw rule. The problem then ceased. (The evil perpetrators _do_ seem to be continuing to try to see if my server can be used & abused by them however. But fortunately, now they are going away empty-handed.) So anyway, I just want to be sure that I am clear about one thing. My server is not actually supplying NTP information to any other systems, either on my network or elsewhere. Nobody is "syncing" time with my server. Given that, may I safely assume... as I have been doing... that 100% of the _inbound_ packets directed at my UDP port 123 are in fact nefarious in nature and that they thus can and should all be blocked, e.g. via the one simple ipfw rule that I now have in place? (It was explained to me at the time that NTP operates a bit like DNS... with which I am more familiar... i.e. that all outbound requests originate on high numbered ports, well and truly away from all low numbered ports, including, in particular, 123. I am just re-verifying that my understanding in this regard is correct, and that my current blanket firewall rule is fine as it stands.) Regards, rfg P.S. The brief period of time during which I was being used & abused as an NTP attack reflector was attributable largely if not entirely to my own earlier ignorance of the NTP protocol, and to the mistake in my personal hand-crafted firewall rules which arose from that. I take responsibility for that, and apologize, as I should, to the entire Internet community for my lapse. That all having been said however, I personally do and will support any appropriate adjustments to FreeBSD config files that might in future making it less likely that ignorant people... like me... might in- advertantly hurt themsevles on this particular sharp object. From owner-freebsd-security@FreeBSD.ORG Tue Mar 18 07:41:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FD4BBA4 for ; Tue, 18 Mar 2014 07:41:21 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (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 030547A9 for ; Tue, 18 Mar 2014 07:41:20 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s2I7fG8h023648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 18 Mar 2014 07:41:16 GMT (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s2I7fG8h023648 Authentication-Results: smtp.infracaninophile.co.uk/s2I7fG8h023648; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <5327F89C.60606@FreeBSD.org> Date: Tue, 18 Mar 2014 07:41:16 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <29310.1395114987@server1.tristatelogic.com> In-Reply-To: <29310.1395114987@server1.tristatelogic.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nJbI9T20nskbMJvo0DOFr0iOjOFM1ED0r" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-Mailman-Approved-At: Tue, 18 Mar 2014 11:34:52 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:41:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nJbI9T20nskbMJvo0DOFr0iOjOFM1ED0r Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18/03/2014 03:56, Ronald F. Guilmette wrote: > (It was explained to me at the time that NTP operates a bit like DNS...= > with which I am more familiar... i.e. that all outbound requests origin= ate > on high numbered ports, well and truly away from all low numbered ports= , > including, in particular, 123. I am just re-verifying that my understa= nding > in this regard is correct, and that my current blanket firewall rule is= > fine as it stands.) It's not uncommon for NTP to have both source and destination ports set to 123. This was the standard some years back, but such things as NAT always meant that couldn't be relied on. I don't know if this is still seen as a normal practice, but all the NTP related entries sockstat shows me are bound to port 123 on the local side. Unlike DNS, I don't think there are any particular security penalties to not using a wide range of UDP source ports for NTP. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --nJbI9T20nskbMJvo0DOFr0iOjOFM1ED0r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTJ/icXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATqTUP/jpOcovOIrK+52MZgjZiBw93 6doxctuJa8pcBR6Hj7x76uO0tOYfzOS95RP3SWnEGpmsYJ7HDV6inMQSKc/RmmQA 4Gxs0/HRfE3bZ1DLfWUH7fZQZAVDgl/a7rn5cgr+kXfM27Qdekn5VFiAkT3ALthU mjIcMSVEN2z0SPjIu9gp50lTcGiIlHfneyc74Fia2xUvOYjwv8inqiYm6V6h8AKu dyquDrQdAAsg9bmjhuMZyMhwaZaSlIe7LpVFN17eCT9wbb46QEnR1IKbbxG4LWqH H6NYFiHzy8EK7DTAbYFbynVfK+nPT15gLwDlJEq0TkjwYmjhqFsy7FW5oMBhq9f0 jLKOuU3NAw/tRgZAUuPohJr98WQcvA1DdI0i3GgYYCr64QvJqg/dgChb+B/7eEiQ YkhciLBmgwNP/hI5RtTTmo78XIG28lXgDrHKu+5qdhdJt/v8zoR6c3ML4selfz5A kR4Z8xEEtnSSVQSdXwFBuKbC8skdWk9Il0+jeImduxuOzR8PiaAGbPWVmHygabQt MmlMSHwYiDZ6Wh+7Ua8kgwmpWuabMLaoLN3sUPHku8L9JD1qbLAsiWLUFyAgGHXF nprLPPPCZSmRf+CuMZE8lewM16rtvMeTTzT8yzNeguzoWy8m5uN9LwcXdg2JaFuq ejgaH41VwCvd9HpQzQt9 =VNFS -----END PGP SIGNATURE----- --nJbI9T20nskbMJvo0DOFr0iOjOFM1ED0r-- From owner-freebsd-security@FreeBSD.ORG Tue Mar 18 18:24:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BB76A93; Tue, 18 Mar 2014 18:24:50 +0000 (UTC) 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 F3520A30; Tue, 18 Mar 2014 18:24:49 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2IIOmwP086094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 11:24:49 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53288F6C.4030604@freebsd.org> Date: Tue, 18 Mar 2014 11:24:44 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matthew Seaman , freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? References: <29310.1395114987@server1.tristatelogic.com> <5327F89C.60606@FreeBSD.org> In-Reply-To: <5327F89C.60606@FreeBSD.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 18:24:50 -0000 On 3/18/14, 12:41 AM, Matthew Seaman wrote: > On 18/03/2014 03:56, Ronald F. Guilmette wrote: >> (It was explained to me at the time that NTP operates a bit like DNS... >> with which I am more familiar... i.e. that all outbound requests originate >> on high numbered ports, well and truly away from all low numbered ports, >> including, in particular, 123. I am just re-verifying that my understanding >> in this regard is correct, and that my current blanket firewall rule is >> fine as it stands.) > It's not uncommon for NTP to have both source and destination ports set > to 123. This was the standard some years back, but such things as NAT > always meant that couldn't be relied on. I don't know if this is still > seen as a normal practice, but all the NTP related entries sockstat > shows me are bound to port 123 on the local side. > > Unlike DNS, I don't think there are any particular security penalties to > not using a wide range of UDP source ports for NTP. yes, you are correct.. in fact what I have is a rule that only allows ANY udp packets if they are responses to something I sent. I have an exception rule for DNS which I do serve. I have an option in my firewall that further narrows that down to only allow ME to send udp (other than dns) packets to my own ntp sources. so even if my ntpd were somehow comromised it couldnt reach anyone else. > > Cheers, > > Matthew > From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 12:36:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43CC87D; Thu, 20 Mar 2014 12:36:49 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 008B0DE8; Thu, 20 Mar 2014 12:36:48 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id A9DE66E3B; Thu, 20 Mar 2014 12:36:47 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2BB23C79; Thu, 20 Mar 2014 13:36:40 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net Subject: Re: misc/187307: Security vulnerability with FreeBSD Jail References: <201403052307.s25N7NoD045308@cgiserv.freebsd.org> <5317B597.5050900@delphij.net> Date: Thu, 20 Mar 2014 13:36:40 +0100 In-Reply-To: <5317B597.5050900@delphij.net> (Xin Li's message of "Wed, 05 Mar 2014 15:39:03 -0800") Message-ID: <86fvmdrqqv.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" , freebsd-gnats-submit@FreeBSD.org, "secteam@FreeBSD.org" , jamie@FreeBSD.org, Nicola Galante X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 12:36:49 -0000 Xin Li writes: > a) you have account on *both* jail and host system. > b) you attempted to log in into jail's IP, which is also bound to host > system; > c) your configuration didn't explicitly specify SSH's listening > address on host, so it's a wildcard (Listen 22 instead of Listen > hostip:22, where you can see in sockstat -4l as *:22 for sshd). > d) when jail is shut down, when you connect to the jail's IP, you > connected into the host. I would like to point out that if you follow the documented procedure for configuring and managing jails, the jail's IP goes away when the jail shuts down. This has been the case since at least 8.x using the old-style rc.conf variables (jail_foo_interface, jail_foo_ip), and it is still the case in 10.0 using the new-style jail.conf. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 17:19:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D5327A for ; Thu, 20 Mar 2014 17:19:32 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id BDF93257 for ; Thu, 20 Mar 2014 17:19:31 +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 LAA29331; Thu, 20 Mar 2014 11:19:27 -0600 (MDT) Message-Id: <201403201719.LAA29331@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Mar 2014 11:19:17 -0600 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:19:32 -0000 At 09:56 PM 3/17/2014, Ronald F. Guilmette wrote: >(It was explained to me at the time that NTP operates a bit like DNS... >with which I am more familiar... i.e. that all outbound requests originate >on high numbered ports, well and truly away from all low numbered ports, >including, in particular, 123. I am just re-verifying that my understanding >in this regard is correct, and that my current blanket firewall rule is >fine as it stands.) Different implementations do different things in this regard. Alas, newer versions of ntpd seem to use UDP port 123 as the originating port when synchronizing with outside servers while older versions did it right and used high, ephemeral ports. This means that stateful firewalling is required for security, and even with it spoofing is still possible if the attacker can guess which servers you query. (The ones in the default FreeBSD ntp.conf file are likely to work most of the time.) We should definitely patch the ntpd that's shipped with FreeBSD to issue queries on randomly chosen ephemeral ports, as well as changing the default ntp.conf file to prevent relaying. As we've seen with DNS, UDP-based services are so ripe for attacks (due to the lack of a 3-way handshake) that they need to be protected in every way possible. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 19:35:37 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77DF2906 for ; Thu, 20 Mar 2014 19:35:37 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 375B77ED for ; Thu, 20 Mar 2014 19:35:36 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5E6EA3AE6E for ; Thu, 20 Mar 2014 12:33:03 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <201403201719.LAA29320@mail.lariat.net> Date: Thu, 20 Mar 2014 12:33:03 -0700 Message-ID: <44680.1395343983@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:35:37 -0000 In message <201403201719.LAA29320@mail.lariat.net>, Brett Glass wrote: >At 09:56 PM 3/17/2014, Ronald F. Guilmette wrote: > >>(It was explained to me at the time that NTP operates a bit like DNS... >>with which I am more familiar... i.e. that all outbound requests originate >>on high numbered ports, well and truly away from all low numbered ports, >>including, in particular, 123. I am just re-verifying that my understanding >>in this regard is correct, and that my current blanket firewall rule is >>fine as it stands.) > >Different implementations do different things in this regard. Alas, newer >versions of ntpd seem to use UDP port 123 as the originating port when >synchronizing with outside servers while older versions did it right and >used high, ephemeral ports. This means that stateful firewalling is >required for security, and even with it spoofing is still possible if the >attacker can guess which servers you query. (The ones in the default FreeBSD >ntp.conf file are likely to work most of the time.) > >We should definitely patch the ntpd that's shipped with FreeBSD to issue >queries on randomly chosen ephemeral ports... I agree entirely with every part of that statement except one. In the immortal words of the Lone Ranger's trusted sidekick (Tonto)... "What do you mean WE kimo sabe?" I personally don't have commit privledges for any part of FreeBSD. Other than that, yes, all outbound NTP queries really should be sent out on high numbered ports, well and truly away from 123. (And also, the outbound port number should be well and truly randomized, I should think. If it's good for the goose, i.e. DNS, then it's probably good for the gander too.) Humm... Uh oh! Oh s**t! When I woke up one day and found all of my bandwidth gone... as a result of being & abused as an NTP reflector... I had rather blithely assumed that the solution that someone offered to me at that time, i.e. just simply blocking all inbound UDP to port 123, was the "right" answer. (It sure did give me my bandwidth back!) It never occured to me... until now... to go back after I made that firewall change and check to see if my local ntpd was still properly able to receive time from any of the servers it was querying. Now that I'm looking at it, it appears that maybe it isn't. If true, that is quite obviously a major bummer. I have a little clock/thermometer thingy in the other room that allegedly picks up and displays the NIST time signal that is broadcast from Colorado. Checking now, I see that the time on my server is slightly more than three full minutes off, relative to that clock/thermometer thingy. (Yikes!) Here is what I am seeing now in response to an ntpdc "peers" query. I am not really all that familiar with this stuff, so if anybody else here can tell me if this looks messed up or not, I'd sure appreciate it. remote local st poll reach delay offset disp ======================================================================= =nist.netservice 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 =rook.slash31.co 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 =96.44.142.5 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 Of course, if this *is* messed up, then I guess that I'll have to remove my firewall rule, and diddle my /etc/ntp.conf file at the same time, in order to make sure that the Evil Ones don't come back and use & abuse me again. And if _that_ is true, then it certainly does underscore the need for changes to the default /etc/ntp.conf file that has been distributed with FreeBSD. From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 20:19:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3DBE52D for ; Thu, 20 Mar 2014 20:19:55 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 65E20CAA for ; Thu, 20 Mar 2014 20:19:55 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id A5E9064CA; Thu, 20 Mar 2014 20:19:54 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 35D9DF30; Thu, 20 Mar 2014 21:19:42 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: =?utf-8?Q?=C5=81ukasz?= Bromirski Subject: Re: freebsd-security Digest, Vol 478, Issue 3 References: Date: Thu, 20 Mar 2014 21:19:42 +0100 In-Reply-To: (=?utf-8?Q?=22=C5=81ukasz?= Bromirski"'s message of "Sun, 16 Mar 2014 16:18:53 +0100") Message-ID: <86vbv8r5b5.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:19:55 -0000 =C5=81ukasz Bromirski writes: > /etc/ntp.conf should by default have secure posture and shouldn=E2=80=99t > require any additional firewalling to remain so. It does, and does not: % grep \^restrict stable/9/etc/ntp.conf=20=20=20=20 restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 127.127.1.0 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 20:26:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F5AE77D for ; Thu, 20 Mar 2014 20:26:56 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 1F13BDAF for ; Thu, 20 Mar 2014 20:26:55 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id A4AB63ADFA for ; Thu, 20 Mar 2014 13:24:30 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <742A1A10-15BF-433A-8693-CA2DD1DE0501@mac.com> Date: Thu, 20 Mar 2014 13:24:30 -0700 Message-ID: <45066.1395347070@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:26:56 -0000 In message <742A1A10-15BF-433A-8693-CA2DD1DE0501@mac.com>, Charles Swiger wrote: >> Of course, if this *is* messed up, then I guess that I'll have to remove >> my firewall rule, and diddle my /etc/ntp.conf file at the same time, in >> order to make sure that the Evil Ones don't come back and use & abuse me >> again. > >OK, although you're making this more complicated than it needs to be. > >If you don't want to provide NTP service to the outside world, leave your exis >ting >deny rule in place but add permit rules to allow UDP traffic to and from the >NTP servers which you want to sync time from. OK, but I wonder what the best way to do that is. Here are some lines from my /etc/ntp.conf file that would seem to be relevant: server 0.freebsd.pool.ntp.org iburst server 1.freebsd.pool.ntp.org iburst server 2.freebsd.pool.ntp.org iburst Is it possible that the three host names given in these lines may possibly become associated with various *different* IPv4 addresses, over time? I would guess so, else why use host names, rather than fixed IPv4 dotted quad addresses? I may be wrong, but as far as I know, ipfw rules need to be written with fixed IPv4 addresses (or fixed CIDRs). So what happens if I hard-code the IPv4 addresses associated with the above three host names into my ipfw rule set, and then, sometime later on, the relevant NTP servers get relocated to new addresses within the IPv4 address space? From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 20:28:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5010AA0F for ; Thu, 20 Mar 2014 20:28:29 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 07F6EDDD for ; Thu, 20 Mar 2014 20:28:28 +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 OAA01351; Thu, 20 Mar 2014 14:28:23 -0600 (MDT) Message-Id: <201403202028.OAA01351@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Mar 2014 14:28:10 -0600 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <44680.1395343983@server1.tristatelogic.com> References: <201403201719.LAA29320@mail.lariat.net> <44680.1395343983@server1.tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:28:29 -0000 At 01:33 PM 3/20/2014, Ronald F. Guilmette wrote: >I agree entirely with every part of that statement except one. > >In the immortal words of the Lone Ranger's trusted sidekick (Tonto)... >"What do you mean WE kimo sabe?" > >I personally don't have commit privledges for any part of FreeBSD. > >Other than that, yes, all outbound NTP queries really should be sent out >on high numbered ports, well and truly away from 123. (And also, the >outbound port number should be well and truly randomized, I should think. >If it's good for the goose, i.e. DNS, then it's probably good for the >gander too.) Well, I'm afraid that I do not have a commit bit either (I've been sending contributions of code and patches to those who do), so all I can do is suggest that the community do it. Hence the "we." And the need to do so is becoming more urgent. Just over the past 24 hours, I am seeing attempted attacks on our servers in which the forged packets have source port 123. Obviously, they're counting on users having "secured" their systems with firewall rules that this will bypass. >Of course, if this *is* messed up, then I guess that I'll have to remove >my firewall rule, and diddle my /etc/ntp.conf file at the same time, in >order to make sure that the Evil Ones don't come back and use & abuse me >again. IMHO, you should diddle /etc/ntp.conf as I mentioned in my earlier message AND use stateful firewall rules (IPFW works fine for this) to ensure that you only accept incoming NTP packets which are answers to your own queries. And, as you state above, outbound queries should use randomized ephemeral source ports as with DNS. This involves a patch to the ntpd that's shipped with FreeBSD, because it is currently compiled to use source port 123. (Back in the days of FreeBSD 5.x and 6.x, it used ephemeral source ports, but not now.) --Brett Glass From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 20:43:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C52018E for ; Thu, 20 Mar 2014 20:43:32 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id F0A63FD5 for ; Thu, 20 Mar 2014 20:43:31 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 3D9643ADFA for ; Thu, 20 Mar 2014 13:41:06 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <201403202028.OAA01351@mail.lariat.net> Date: Thu, 20 Mar 2014 13:41:06 -0700 Message-ID: <45158.1395348066@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 20:43:32 -0000 In message <201403202028.OAA01351@mail.lariat.net>, Brett Glass wrote: >... >And the need to do so is becoming more urgent. Just over the past 24 hours, >I am seeing attempted attacks on our servers in which the forged packets >have source port 123. Obviously, they're counting on users having "secured" >their systems with firewall rules that this will bypass. >... >And, as you state above, outbound queries should use randomized ephemeral >source ports as with DNS. This involves a patch to the ntpd that's shipped >with FreeBSD, because it is currently compiled to use source port 123. I'm no expert, but I'll go out on a limb here anyway and say that the choice to make NTP outbound queries always use source port 123 is, as far as I can see, really really ill-advised. Did we learn nothing from all of the bruhaha a couple of years ago about DNS amplification attacks and the ways that were finally settled on to effectively thwart them (most specifically the randomization of query source ports)? I dearly hope that someone on this list who does in fact have commit privs will jump on this Right Away. I'm not persuaded that running a perfectly configured ipfw... statefully, no less... should be an absolute prerequsite for running any Internet-connected FreeBSD-based device that simply wishes to always know the correct time. From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 21:04:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5A2ABC1 for ; Thu, 20 Mar 2014 21:04:42 +0000 (UTC) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97FEB274 for ; Thu, 20 Mar 2014 21:04:42 +0000 (UTC) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N2R00DXA3RE3F60@mail-out.apple.com> for freebsd-security@freebsd.org; Thu, 20 Mar 2014 13:04:35 -0700 (PDT) X-AuditID: 11807143-f79f66d0000015d3-27-532b49d3cb98 Received: from [17.149.233.107] (Unknown_Domain [17.149.233.107]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 6E.BF.05587.3D94B235; Thu, 20 Mar 2014 13:04:35 -0700 (PDT) Subject: Re: NTP security hole CVE-2013-5211? From: Charles Swiger In-reply-to: <44680.1395343983@server1.tristatelogic.com> Date: Thu, 20 Mar 2014 13:04:35 -0700 Message-id: <742A1A10-15BF-433A-8693-CA2DD1DE0501@mac.com> References: <44680.1395343983@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUiOPVltu5lT+1gg8PbLS16Nj1hs3h1+RWb A5PHjE/zWTzub2pkDmCK4rJJSc3JLEst0rdL4MrY8OckW8Gcworjn7ayNzD+Tupi5OSQEDCR WP1iNxuELSZx4d56IJuLQ0ign0lidXc7YxcjBwezQILE/zdFICavgJ7E9l9yIOXCAroSzUcP sIOE2QTUJCZM5AEJcwpYSizf08cKYrMIqEqcurmEGcRmFlCQmDz/O5jNK2Al8XvJKnYQW0jA QmLqvqOMILaIgL7E0r1PGSGukZU4fe45ywRGvlkIN8xCuGEW2FBtiWULXzNDVOhITF7IiCoM YX88f4RpASPbKkaBotScxEojvcSCgpxUveT83E2MoMBsKHTewXhsmdUhRgEORiUe3gpO7WAh 1sSy4srcQ4wSHMxKIrzXdIFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ8aAaUE0hNLUrNTUwtS i2CyTBycUg2MZh9lKpk/68t6FfYu9jo4Oy3a3KJ0sk78mSUvw6SPtV6fuq9ygadgpe3yLc9j SiQyGnV7nS0W3Wt+bPohcSVbkNBW646aCb3+aR+Vyl28/1/JfLy26odfxbTrUtXiHP638u37 5ypf8ls59cjFJPuNj9caL9c8qOfVoH5vZ0nr0wsTL3Y9PsKjxFKckWioxVxUnAgAoq5+MUgC AAA= Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 21:04:42 -0000 Hi-- On Mar 20, 2014, at 12:33 PM, Ronald F. Guilmette wrote: > Here is what I am seeing now in response to an ntpdc "peers" query. I am > not really all that familiar with this stuff, so if anybody else here can > tell me if this looks messed up or not, I'd sure appreciate it. > > > remote local st poll reach delay offset disp > ======================================================================= > =nist.netservice 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 > =rook.slash31.co 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 > =96.44.142.5 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 Reachability score of 0 means you've blocked the communications. > Of course, if this *is* messed up, then I guess that I'll have to remove > my firewall rule, and diddle my /etc/ntp.conf file at the same time, in > order to make sure that the Evil Ones don't come back and use & abuse me > again. OK, although you're making this more complicated than it needs to be. If you don't want to provide NTP service to the outside world, leave your existing deny rule in place but add permit rules to allow UDP traffic to and from the NTP servers which you want to sync time from. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Thu Mar 20 21:37:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA2D2AF0 for ; Thu, 20 Mar 2014 21:37:55 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 768F6823 for ; Thu, 20 Mar 2014 21:37:55 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id EE16E3ADFA for ; Thu, 20 Mar 2014 14:37:54 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <742A1A10-15BF-433A-8693-CA2DD1DE0501@mac.com> Date: Thu, 20 Mar 2014 14:37:54 -0700 Message-ID: <45647.1395351474@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 21:37:55 -0000 In message <742A1A10-15BF-433A-8693-CA2DD1DE0501@mac.com>, Charles Swiger wrote: >If you don't want to provide NTP service to the outside world, leave your existing >deny rule in place but add permit rules to allow UDP traffic to and from the >NTP servers which you want to sync time from. I just now tried doing that, but what I tried doesn't seem to be working at all as expected. My effort has however releaved more of my ignorance about ntpd and ntpdc. Starting from these lines in my /etc/ntp.conf file: server 0.freebsd.pool.ntp.org iburst server 1.freebsd.pool.ntp.org iburst server 2.freebsd.pool.ntp.org iburst I resolved each of those three host names to _all_ of its associated IPv4 addresses. This yielded me the following list: 50.116.38.157 69.50.219.51 69.55.54.17 69.167.160.102 108.61.73.244 129.250.35.251 149.20.68.17 169.229.70.183 192.241.167.38 199.7.177.206 209.114.111.1 209.118.204.201 So I added the following new ipfw rules, just above the deny rule that I currently have protecting my UDP port 123: add pass udp from 50.116.38.157 123 to any in add pass udp from 69.50.219.51 123 to any in add pass udp from 69.55.54.17 123 to any in add pass udp from 69.167.160.102 123 to any in add pass udp from 108.61.73.244 123 to any in add pass udp from 129.250.35.251 123 to any in add pass udp from 149.20.68.17 123 to any in add pass udp from 169.229.70.183 123 to any in add pass udp from 192.241.167.38 123 to any in add pass udp from 199.7.177.206 123 to any in add pass udp from 209.114.111.1 123 to any in add pass udp from 209.118.204.201 123 to any in I then cd'd into /etc/rc.conf and executed the following (as root): ./ntpd stop ./ntpd start Then, after a short while, I ran ntpdc again and executed the "peers" query again. Now I get this: remote local st poll reach delay offset disp ======================================================================= =cheezum.mattnor 69.62.255.118 16 64 0 0.00000 0.000000 3.99217 *server2.shellva 69.62.255.118 2 64 377 0.09827 0.021492 0.05600 =li506-17.member 69.62.255.118 16 64 0 0.00000 0.000000 3.99217 Obviously, this is better than before... I am now syncing with at least one server (specifically 69.55.54.17 server2.shellvatore.us), *however* I have checked the reverse DNS names associated with all 12 of the above listed IPv4 addresses and none of those reverse DNS names begin with either "cheezum.mattnor..." or "li506-17.member...". So um, color me preplexed! It appears that ntpdc is telling me that my local ntpd daemon is attempting to query a couple of remote time servers that I never asked it to consult! What's up with that? Furthermore, and consistant with what ntpdc is telling me, only one of my new firewall rules is even succeeding at letting any useful NTP packets through, specifically ones being sent to me from server2.shellvatore.us: 01605 0 0 allow udp from 50.116.38.157 123 to any in 01610 0 0 allow udp from 69.50.219.51 123 to any in 01615 20 1520 allow udp from 69.55.54.17 123 to any in 01620 0 0 allow udp from 69.167.160.102 123 to any in 01625 0 0 allow udp from 108.61.73.244 123 to any in 01630 0 0 allow udp from 129.250.35.251 123 to any in 01635 0 0 allow udp from 149.20.68.17 123 to any in 01640 0 0 allow udp from 169.229.70.183 123 to any in 01645 0 0 allow udp from 192.241.167.38 123 to any in 01650 0 0 allow udp from 199.7.177.206 123 to any in 01655 0 0 allow udp from 209.114.111.1 123 to any in 01660 0 0 allow udp from 209.118.204.201 123 to any in So, um, what the bleep goes on here? Why is my ntpd only querying one of the 12 possible IPv4 addresses it should be querying? And why is it sending queries to two servers that, as far as I can tell, I never told it to send queries to, specifically: 67.18.187.111 cheezum.mattnordhoff.net 66.175.209.17 li506-17.members.linode.com Is there some secret extra .conf file for ntpd that I don't know about? For reference, my own complete & current /etc/ntp.conf file is attached below: cut here ============================================================================= # # $FreeBSD: release/9.1.0/etc/ntp.conf 239608 2012-08-23 04:57:56Z delphij $ # # Default NTP servers for the FreeBSD operating system. # # Don't forget to enable ntpd in /etc/rc.conf with: # ntpd_enable="YES" # # The driftfile is by default /var/db/ntpd.drift, check # /etc/defaults/rc.conf on how to change the location. # # # The following three servers will give you a random set of three # NTP servers geographically close to you. # See http://www.pool.ntp.org/ for details. Note, the pool encourages # users with a static IP and good upstream NTP servers to add a server # to the pool. See http://www.pool.ntp.org/join.html if you are interested. # # The option `iburst' is used for faster initial synchronisation. # server 0.freebsd.pool.ntp.org iburst server 1.freebsd.pool.ntp.org iburst server 2.freebsd.pool.ntp.org iburst #server 3.freebsd.pool.ntp.org iburst # # If you want to pick yourself which country's public NTP server # you want sync against, comment out the above servers, uncomment # the next ones and replace CC with the country's abbreviation. # Make sure that the hostnames resolve to a proper IP address! # # server 0.CC.pool.ntp.org iburst # server 1.CC.pool.ntp.org iburst # server 2.CC.pool.ntp.org iburst # # Security: Only accept NTP traffic from the following hosts. # The following configuration example only accepts traffic from the # above defined servers. # # Please note that this example doesn't work for the servers in # the pool.ntp.org domain since they return multiple A records. # (This is the reason that by default they are commented out) # #restrict default ignore #restrict 0.pool.ntp.org nomodify nopeer noquery notrap #restrict 1.pool.ntp.org nomodify nopeer noquery notrap #restrict 2.pool.ntp.org nomodify nopeer noquery notrap #restrict 127.0.0.1 #restrict -6 ::1 #restrict 127.127.1.0 # # If a server loses sync with all upstream servers, NTP clients # no longer follow that server. The local clock can be configured # to provide a time source when this happens, but it should usually # be configured on just one server on a network. For more details see # http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock # The use of Orphan Mode may be preferable. # #server 127.127.1.0 #fudge 127.127.1.0 stratum 10 From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 00:50:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D903EB05 for ; Fri, 21 Mar 2014 00:50:33 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FDBCE54 for ; Fri, 21 Mar 2014 00:50:33 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so1160225wes.3 for ; Thu, 20 Mar 2014 17:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=Rq8IfcNmmHdXJXMkdYYNtojH2ABPlRaHRKjhULb+T2E=; b=XwssXA65ULEimlz7wfXQ2QtgaSt4g1hCXiJ3PD1HktGH5B49/gW5CbZfH1O8yh9vAm UgmcYM5y+GZo15l9Tva1zHiRpnpK2XAKdBlBWy/tSfpTDrBy6YoZM46hjpiq91f9Hp2z M34WLp6trJUeXtcLAZbzt+1inVWZ5zDaFMJD8ntx5aBl8NvnD77U22tgY3L2bMNkLFCs S1GNMoFshVPokPV1NMyLDqaxWUe9D92x/Y1JJyDr2kLPY1Wle5+3OasjXdHsCWwVdHZM 4EVD0HcyQsCo76F08ZCHpeYHwTeEFX4i6AgCprabEUbKtImD9shopdUQTDvDrn6Od6hb jz3A== X-Received: by 10.180.12.115 with SMTP id x19mr5807984wib.19.1395363031798; Thu, 20 Mar 2014 17:50:31 -0700 (PDT) Received: from gumby.homeunix.com ([94.195.197.72]) by mx.google.com with ESMTPSA id rx9sm3086556wjb.20.2014.03.20.17.50.30 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 20 Mar 2014 17:50:30 -0700 (PDT) Date: Fri, 21 Mar 2014 00:50:28 +0000 From: RW To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <20140321005028.5c51faf4@gumby.homeunix.com> In-Reply-To: <45647.1395351474@server1.tristatelogic.com> References: <742A1A10-15BF-433A-8693-CA2DD1DE0501@mac.com> <45647.1395351474@server1.tristatelogic.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 00:50:33 -0000 On Thu, 20 Mar 2014 14:37:54 -0700 Ronald F. Guilmette wrote: > I resolved each of those three host names to _all_ of its associated > IPv4 addresses. This yielded me the following list: > > 50.116.38.157 > ... > It's a pool, if you try it a few minutes later you will probably get a different 16 addresses. Depending on what precisely you are trying to do, you probably need a stateful rule for outgoing connections. From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 04:21:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 125E9F51 for ; Fri, 21 Mar 2014 04:21:08 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id AA4BB19B for ; Fri, 21 Mar 2014 04:21:06 +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 WAA05406; Thu, 20 Mar 2014 22:21:00 -0600 (MDT) Message-Id: <201403210421.WAA05406@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Mar 2014 22:20:52 -0600 To: "Ronald F. Guilmette" From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 04:21:08 -0000 At 03:37 PM 3/20/2014, Ronald F. Guilmette wrote: >Starting from these lines in my /etc/ntp.conf file: > >server 0.freebsd.pool.ntp.org iburst >server 1.freebsd.pool.ntp.org iburst >server 2.freebsd.pool.ntp.org iburst > >I resolved each of those three host names to _all_ of its associated >IPv4 addresses. This yielded me the following list: > >50.116.38.157 >69.50.219.51 >69.55.54.17 >69.167.160.102 >108.61.73.244 >129.250.35.251 >149.20.68.17 >169.229.70.183 >192.241.167.38 >199.7.177.206 >209.114.111.1 >209.118.204.201 [Snip] All of this is good. However, remember that anyone who can spoof IPs will know that the above addresses are the defaults for any FreeBSD machine and can take advantage of these "holes" in your firewall. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 04:39:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C92129D for ; Fri, 21 Mar 2014 04:39:04 +0000 (UTC) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0BEAE2F4 for ; Fri, 21 Mar 2014 04:39:03 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id i50so5596609qgf.0 for ; Thu, 20 Mar 2014 21:38:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Ktci5MfdPLeqi7EMjjB/jOrjnvbg5qvx3l+XAQZeRd4=; b=G9dz+KJ3LbbxoruBvmp7TkZbyfsD/Pdmh0uRMNAq+SCQ/A8l4vbNSdbghRyKmNsZk/ 0o/2jCEGBmyCAjXHB050IFpCR6oguX9BGLEQbCIjHOKwWrKmcE8sdGe1nOv3priz2G+q gptWFg74EbPQtbEmPlb9w0/jFe4jvjl7cBX8RCfW/FUjXRdx/w8ZJ5uSiTPADwNNwSEJ w6IQBzvCvvunb3JeIvWNVJ1usEBhImcueP4G4JVl3pbjafB8cGrRqV8hloRbKb+6DeT6 30nlgQhwkjKDdBhcQAKz7ni1hY3q0KgOcq+R42O4dGYTc9PvRdUHmzIr3bJvunvg7kwV wDUw== X-Gm-Message-State: ALoCoQn7WAjRi8dao725QLtHC+O/k7BP7iBn/O9haruTu758RonczaSmNZ0o6uWLCeKFVWuNN2gA MIME-Version: 1.0 X-Received: by 10.140.43.228 with SMTP id e91mr20241182qga.35.1395376737462; Thu, 20 Mar 2014 21:38:57 -0700 (PDT) Received: by 10.140.49.104 with HTTP; Thu, 20 Mar 2014 21:38:57 -0700 (PDT) Received: by 10.140.49.104 with HTTP; Thu, 20 Mar 2014 21:38:57 -0700 (PDT) In-Reply-To: <201403210421.WAA05406@mail.lariat.net> References: <201403210421.WAA05406@mail.lariat.net> Date: Thu, 20 Mar 2014 21:38:57 -0700 Message-ID: Subject: Re: NTP security hole CVE-2013-5211? From: Micheas Herman To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 04:39:04 -0000 On Mar 20, 2014 9:21 PM, "Brett Glass" wrote: > > At 03:37 PM 3/20/2014, Ronald F. Guilmette wrote: > >> Starting from these lines in my /etc/ntp.conf file: >> >> server 0.freebsd.pool.ntp.org iburst >> server 1.freebsd.pool.ntp.org iburst >> server 2.freebsd.pool.ntp.org iburst >> >> I resolved each of those three host names to _all_ of its associated >> IPv4 addresses. This yielded me the following list: >> >> 50.116.38.157 >> 69.50.219.51 >> 69.55.54.17 >> 69.167.160.102 >> 108.61.73.244 >> 129.250.35.251 >> 149.20.68.17 >> 169.229.70.183 >> 192.241.167.38 >> 199.7.177.206 >> 209.114.111.1 >> 209.118.204.201 > > > [Snip] > > All of this is good. However, remember that anyone who can spoof IPs will know > that the above addresses are the defaults for any FreeBSD machine and can > take advantage of these "holes" in your firewall. While true, that does mean that amplification attacks are limited to being able to attack those ten machines. A not insignificant reduction in hosts vulnerable to attack. > > --Brett Glass > > _______________________________________________ > 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 Mar 21 04:44:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3218406 for ; Fri, 21 Mar 2014 04:44:12 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7410D39A for ; Fri, 21 Mar 2014 04:44:12 +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 WAA05541; Thu, 20 Mar 2014 22:44:07 -0600 (MDT) Message-Id: <201403210444.WAA05541@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Mar 2014 22:44:01 -0600 To: Micheas Herman , freebsd-security@freebsd.org From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: References: <201403210421.WAA05406@mail.lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 04:44:12 -0000 At 10:38 PM 3/20/2014, Micheas Herman wrote: >While true, that does mean that amplification attacks are limited to being >able to attack those ten machines. The amplifier/relay is also a victim, and can be completely disabled by the attack if its link to the Net becomes saturated. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 10:41:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7547748 for ; Fri, 21 Mar 2014 10:41:52 +0000 (UTC) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13A29855 for ; Fri, 21 Mar 2014 10:41:51 +0000 (UTC) Received: from DBXPR06MB318.eurprd06.prod.outlook.com (10.141.11.143) by DBXPR06MB320.eurprd06.prod.outlook.com (10.141.11.148) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 10:41:42 +0000 Received: from DBXPR06MB318.eurprd06.prod.outlook.com ([10.141.11.143]) by DBXPR06MB318.eurprd06.prod.outlook.com ([10.141.11.143]) with mapi id 15.00.0898.005; Fri, 21 Mar 2014 10:41:41 +0000 From: Info / RIT.lt To: Brett Glass , Micheas Herman , "freebsd-security@freebsd.org" Subject: RE: NTP security hole CVE-2013-5211? Thread-Topic: NTP security hole CVE-2013-5211? Thread-Index: AQHPRLzx0AtnaDAcB0K/rmYpZWvx2Jrq9XeAgAABh3mAAGLHFA== Date: Fri, 21 Mar 2014 10:41:41 +0000 Message-ID: References: <201403210421.WAA05406@mail.lariat.net> , <201403210444.WAA05541@mail.lariat.net> In-Reply-To: <201403210444.WAA05541@mail.lariat.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.247.103.146] x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(24454002)(479174003)(377454003)(74706001)(74316001)(95416001)(95666003)(74366001)(83322001)(19580395003)(74876001)(97336001)(97186001)(94946001)(92566001)(83072002)(76576001)(81816001)(81686001)(76796001)(76786001)(93516002)(15975445006)(80976001)(86362001)(85306002)(85852003)(93136001)(50986001)(33646001)(19580405001)(59766001)(47736001)(47976001)(51856001)(4396001)(90146001)(56816005)(87266001)(2656002)(87936001)(46102001)(15202345003)(80022001)(66066001)(65816001)(54356001)(56776001)(20776003)(77982001)(94316002)(63696002)(49866001)(76482001)(53806001)(54316002)(79102001)(35302001)(69226001)(31966008)(74662001)(74482001)(74502001)(47446002)(81542001)(81342001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR06MB320; H:DBXPR06MB318.eurprd06.prod.outlook.com; FPR:A583659A.941487A9.60E83048.52EAD908.2025B; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: rit.lt does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rit.lt X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 10:41:52 -0000 Dear FreeBSD users, my first experience with FreeBSD was 14 years ago, but = due to hardware problems I chose Linux. After working with Linux for 14 yea= rs, I decided to give a shot to FreeBSD again. After setting up FreeBSD ser= ver with jails, I became a victim of DDoS which was launched from my dedica= ted server, investigation led to NTP server, this misconfiguration left wit= h default settings shocked me, please fix this configuration bug.=0A= =0A= Firewall is for filtering traffic, but not for hiding buggy configs.=0A= =0A= Regards,=0A= Mindaugas Bubelis=0A= ________________________________________=0A= From: owner-freebsd-security@freebsd.org on behalf of Brett Glass =0A= Sent: Friday, March 21, 2014 6:44 AM=0A= To: Micheas Herman; freebsd-security@freebsd.org=0A= Subject: Re: NTP security hole CVE-2013-5211?=0A= =0A= At 10:38 PM 3/20/2014, Micheas Herman wrote:=0A= =0A= >While true, that does mean that amplification attacks are limited to being= =0A= >able to attack those ten machines.=0A= =0A= The amplifier/relay is also a victim, and can be completely disabled by the= attack=0A= if its link to the Net becomes saturated.=0A= =0A= --Brett Glass=0A= =0A= _______________________________________________=0A= freebsd-security@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-security=0A= To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"= =0A= From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 11:08:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38EF1D63 for ; Fri, 21 Mar 2014 11:08:45 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [78.47.69.234]) by mx1.freebsd.org (Postfix) with ESMTP id B4223A5E for ; Fri, 21 Mar 2014 11:08:44 +0000 (UTC) Received: from [IPv6:2001:470:d701::807:3495:fd4c:6be8] (unknown [IPv6:2001:470:d701:0:807:3495:fd4c:6be8]) by mail.jr-hosting.nl (Postfix) with ESMTPSA id A76FD3F4A0; Fri, 21 Mar 2014 12:08:42 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_20AE229B-882B-44AF-BA93-4919477E8D81"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: NTP security hole CVE-2013-5211? From: Remko Lodder In-Reply-To: Date: Fri, 21 Mar 2014 12:08:40 +0100 Message-Id: References: <201403210421.WAA05406@mail.lariat.net> , <201403210444.WAA05541@mail.lariat.net> To: "Info / RIT.lt" X-Mailer: Apple Mail (2.1874) Cc: "freebsd-security@freebsd.org" , Micheas Herman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 11:08:45 -0000 --Apple-Mail=_20AE229B-882B-44AF-BA93-4919477E8D81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Mar 2014, at 11:41, Info / RIT.lt wrote: > Dear FreeBSD users, my first experience with FreeBSD was 14 years ago, = but due to hardware problems I chose Linux. After working with Linux for = 14 years, I decided to give a shot to FreeBSD again. After setting up = FreeBSD server with jails, I became a victim of DDoS which was launched = from my dedicated server, investigation led to NTP server, this = misconfiguration left with default settings shocked me, please fix this = configuration bug. >=20 > Firewall is for filtering traffic, but not for hiding buggy configs. >=20 > Regards, > Mindaugas Bubelis I kept silent so far, but this lets me frown a bit. We all know that there are people on the internet that try to hurt our = businesses, 24*7*365. All unprotected networks and hosts are targeted, 24*7*365. It is -very- common practise to setup a security perimeter, to only = allow traffic you want to have to your machine(s) and only let out traffic you want from your machine(s). I worked for = large scale ISP=92s, and we all did the same. Reading the mails from this thread leads me to believe that there is no = stateful firewall concept in place? Only allow the network you want to your NTP server(s) and deny the = others. Only let our your NTP server=92s to the internet to retrieve the date. Do that statefully and only traffic you send out should come back with = the last line mentioned, it is hard from the internet seen to hijack such a session and fool the firewall from letting the packet = back in to your NTP server. In my believing it is so that if you do not filter traffic, you are = making a deliberate choice to let everyone smack your service(s). That is not a problem but you also need to modify your configuration(s) = to make sure it is as safe as it gets. We (FreeBSD) updated the ntpd.conf file that is shipped as a Security Patch so that users = running our update facilities have that in place. However since people also change their configurations on their own or do not use that, = they need to be aware that they need to update the rules as well! We do not want to enforce our configuration changes to users who = might have a good reason for having an alternative setup! The only thing I saw from Brett that might need investigation is the = additional 'disable monitor=92, though would that break people=92s setup ? are people using that on purpose for some reason? Then we cannot = enforce it, just advice that this might be an solution to prevent issues. In my understanding and believing, stateful firewalling your networks is = the best option, making sure that only your own machines or a selected set of machines can access NTP resources on your network = (or the internet, whatever you prefer) and that traffic leaving your borders can only return if the firewall sees that you setup = the communication in the first place. In the above case: did you install the FreeBSD-release and never = updated? Then that is something -you- should have done. Installing something via delivered media is always out of date and needs to be = updated before first use. Thank you. Remko > ________________________________________ > From: owner-freebsd-security@freebsd.org = on behalf of Brett Glass = > Sent: Friday, March 21, 2014 6:44 AM > To: Micheas Herman; freebsd-security@freebsd.org > Subject: Re: NTP security hole CVE-2013-5211? >=20 > At 10:38 PM 3/20/2014, Micheas Herman wrote: >=20 >> While true, that does mean that amplification attacks are limited to = being >> able to attack those ten machines. >=20 > The amplifier/relay is also a victim, and can be completely disabled = by the attack > if its link to the Net becomes saturated. >=20 > --Brett Glass >=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" > _______________________________________________ > 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 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News --Apple-Mail=_20AE229B-882B-44AF-BA93-4919477E8D81 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTLB24AAoJEKjD27JZ84ywn1QP/1S8TeNgFM/WUKAtMVhcO7ij f6U4Dch4fEW+Z5xj9vWqL2rQ7spACWXDYGYa5EtdNMWNBUOtDAoqHPp6jkZdg9wq i5ZMj5N6NAKRt2lP48fzHqjNW8OM7ZHShzb+7azwZvoILBNXnS+l1iRljz7/+xL/ 4vGaj07H+Cbd8kh2A69BvXEmnDq7GKEPl1DDUe3L/LK1QckXIbe759Q+5Fq5/lC/ PdNqUOfseMNKAeZ4KVYqdoWPtCBQDy6Jt9x+m/8yfq3IOkAZp9AtGb1VPpiMcCEn yrwis/H6XGB0AlYt9VyXoQSFRHVN5V1q/SOWzPwaQ28xzHkZ5gV5uzPj9xMu8BQc kxJxDQ6T2Md3nUug/pW9YMMz7uJT0Lsaw2hjsko5r1dUzfGY7QZKciP5Hyix7FGS nK7W99GhTWzGqCVkdx0q+Yf6a8xMT8sUEk+IoOU55RJ3zyhrJgAtl1Zv/3IfJE+i GRV5RzH37aHyk6TjuJk5T2mYckqdKFvNRdaY5CV+l9tEogVKo6z6aW9g8tTYJRkk DeHd1jZpVKhjFiwg6epIeh4GW3ijK+Rp/vyGm6i/OheG62j3Y+Kuus87OMb3+7m9 cKwhfzbKNMVjmWKOprKYP47Wi+BZmqvr2e+A96iWxSFIjV17w59VcrYNGxVrDIFe l3EiqWYCuA0Iz6YHob4E =2fay -----END PGP SIGNATURE----- --Apple-Mail=_20AE229B-882B-44AF-BA93-4919477E8D81-- From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 12:27:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78B94562 for ; Fri, 21 Mar 2014 12:27:20 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14F7E1E1 for ; Fri, 21 Mar 2014 12:27:20 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id B69142383C8; Fri, 21 Mar 2014 12:27:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6BD70160068; Fri, 21 Mar 2014 12:28:07 +0000 (UTC) Received: from rock.dv.isc.org (dsl092-002-166.sfo1.dsl.speakeasy.net [66.92.2.166]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F378160067; Fri, 21 Mar 2014 12:28:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AC6D411A9DE6; Fri, 21 Mar 2014 23:27:01 +1100 (EST) To: "Ronald F. Guilmette" From: Mark Andrews References: <45158.1395348066@server1.tristatelogic.com> Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-reply-to: Your message of "Thu, 20 Mar 2014 13:41:06 -0700." <45158.1395348066@server1.tristatelogic.com> Date: Fri, 21 Mar 2014 23:27:01 +1100 Message-Id: <20140321122701.AC6D411A9DE6@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 12:27:20 -0000 In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <201403202028.OAA01351@mail.lariat.net>, > Brett Glass wrote: > > >... > >And the need to do so is becoming more urgent. Just over the past 24 hours, > >I am seeing attempted attacks on our servers in which the forged packets > >have source port 123. Obviously, they're counting on users having "secured" > >their systems with firewall rules that this will bypass. > >... > >And, as you state above, outbound queries should use randomized ephemeral > >source ports as with DNS. This involves a patch to the ntpd that's shipped > >with FreeBSD, because it is currently compiled to use source port 123. > > I'm no expert, but I'll go out on a limb here anyway and say that the choice > to make NTP outbound queries always use source port 123 is, as far as I can > see, really really ill-advised. Did we learn nothing from all of the bruhaha > a couple of years ago about DNS amplification attacks and the ways that > were finally settled on to effectively thwart them (most specifically the > randomization of query source ports)? Well for DNS the source port randomisation was to prevent cache poisoning so no *you* didn't learn anything from port randomisation in DNS. For time you want to reduce the variabilty in code paths taken as much as posible so no you don't want to be opening up a new socket every time. Now if you are not running as a server or peer you can use a different port but that prevents local tools reaching ntpd to find out how ntpd is doing. NTP does have the ability to work out which commands it will accept and from whom. This stops NTP being used as a amplifier. The built in configuration has already been changed to make this the default behaviour. Now one can change the code to drop the negative packet but that also stops you tell legitimate NTP clients to stop using you. Reflection really isn't a big help and as has been seen in the DNS stopping the ability to be used as a amplifier does stop lead to you being removed from the lists of reflectors. This is no immediate but it does happen. > I dearly hope that someone on this list who does in fact have commit privs > will jump on this Right Away. I'm not persuaded that running a perfectly > configured ipfw... statefully, no less... should be an absolute prerequsite > for running any Internet-connected FreeBSD-based device that simply wishes > to always know the correct time. You can run a stateless firewall with on a NTP client and it is no longer a reflector which can be directed at any ip address in the world if you care to. > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 15:25:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD860FA1 for ; Fri, 21 Mar 2014 15:25:29 +0000 (UTC) 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 5CE54955 for ; Fri, 21 Mar 2014 15:25:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s2LFPKlZ052479; Sat, 22 Mar 2014 02:25:20 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 22 Mar 2014 02:25:19 +1100 (EST) From: Ian Smith To: "Ronald F. Guilmette" Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <45158.1395348066@server1.tristatelogic.com> Message-ID: <20140322000445.C31989@sola.nimnet.asn.au> References: <45158.1395348066@server1.tristatelogic.com> 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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 15:25:29 -0000 On Thu, 20 Mar 2014 13:41:06 -0700, Ronald F. Guilmette wrote: [..] > I dearly hope that someone on this list who does in fact have commit privs > will jump on this Right Away. I'm not persuaded that running a perfectly > configured ipfw... statefully, no less... should be an absolute prerequsite > for running any Internet-connected FreeBSD-based device that simply wishes > to always know the correct time. Just on your last point: if your internet-connected device is providing any services whatsoever on its outside interface (netstat -finet -an) then unless you're literally offering those services unrestricted to the planet at large, you need a firewall - or to be relying on one upstream. As assorted experts have suggested, you need a stateful rule. It's really not that hard; if you _only_ needed to protect ntp on udp: kldload ipfw && add 65000 allow ip from any to any # load null fw ipfw add allow udp from me to any ntp out xmit $outsideif keep-state ipfw add deny udp from any to me ntp in recv $outsideif Done. Perfectly configured for this one purpose, statefully no less .. Protect sshd likewise, if enabled. Or use pf, as you prefer. Going a bit further and dropping everything you didn't ask for makes more sense, and stats (eg ipfw -t show) may surprise re how much you're deflecting. cheers, Ian From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 16:23:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62154CEB for ; Fri, 21 Mar 2014 16:23:21 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED8ACF7D for ; Fri, 21 Mar 2014 16:23:20 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id k14so1748830wgh.23 for ; Fri, 21 Mar 2014 09:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=bW0bSOv7StoDIV9CDZZW/q/8nwGV+sftgDnvXyltHLg=; b=0pMjrUPMnfeWpvpgDYJZIvVHHI9qgxEbUw5Y1e1hPJjLiZA6GDbTvofQNCeC6eihRL nDaD8kOK0TQrvAlC3cP2FtA4EqPamPAmeUSiFI3Yb9oa3SOxL1Oz4IknxNGUpBnyb6Om qgFxyPN2rB4rRfjKRI2yCGY+Uftlr3Jsl+tgxXt2c3Zcwq9aJHZYWXokVlsrUNTExhnt phYIG9Z36GoNPPWnA8EHVv1i7bfsRkO331oNwVhPIcZZ6X1l50flBRZAXUUK53MPNfAb 65xmbvxwbM+KPZ7LuHmI/gBDpBAGmUrKsKrkH6j6LO5NaYVqbm+JdyaqunhJ8Ggh5HAp hLPg== X-Received: by 10.180.164.69 with SMTP id yo5mr3496392wib.55.1395418979935; Fri, 21 Mar 2014 09:22:59 -0700 (PDT) Received: from gumby.homeunix.com ([94.195.197.72]) by mx.google.com with ESMTPSA id qg3sm6231930wic.10.2014.03.21.09.22.58 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 21 Mar 2014 09:22:59 -0700 (PDT) Date: Fri, 21 Mar 2014 16:22:57 +0000 From: RW To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <20140321162257.1213a670@gumby.homeunix.com> In-Reply-To: <201403210421.WAA05406@mail.lariat.net> References: <201403210421.WAA05406@mail.lariat.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:23:21 -0000 On Thu, 20 Mar 2014 22:20:52 -0600 Brett Glass wrote: > At 03:37 PM 3/20/2014, Ronald F. Guilmette wrote: > > >Starting from these lines in my /etc/ntp.conf file: > > > >server 0.freebsd.pool.ntp.org iburst > >server 1.freebsd.pool.ntp.org iburst > >server 2.freebsd.pool.ntp.org iburst > > > >I resolved each of those three host names to _all_ of its associated > >IPv4 addresses. This yielded me the following list: > > > >50.116.38.157 > >69.50.219.51 > >69.55.54.17 > >69.167.160.102 > >108.61.73.244 > >129.250.35.251 > >149.20.68.17 > >169.229.70.183 > >192.241.167.38 > >199.7.177.206 > >209.114.111.1 > >209.118.204.201 > > [Snip] > > All of this is good. When you use a vendor pool or pool.ntp.org, you get a random selection of servers in your local region. According to www.pool.ntp.org that's 869 for North America, and 2495 for Europe. From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 16:42:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A90B9A48 for ; Fri, 21 Mar 2014 16:42:44 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 694B31FD for ; Fri, 21 Mar 2014 16: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 288258CD6; Fri, 21 Mar 2014 16:42:43 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 74A19940; Fri, 21 Mar 2014 17:42:35 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ian Smith Subject: Re: URGENT? References: <45158.1395348066@server1.tristatelogic.com> <20140322000445.C31989@sola.nimnet.asn.au> Date: Fri, 21 Mar 2014 17:42:35 +0100 In-Reply-To: <20140322000445.C31989@sola.nimnet.asn.au> (Ian Smith's message of "Sat, 22 Mar 2014 02:25:19 +1100 (EST)") Message-ID: <86r45v7bb8.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, "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:42:44 -0000 Ian Smith writes: > Just on your last point: if your internet-connected device is providing > any services whatsoever on its outside interface (netstat -finet -an)=20 Or sockstat -4l, which is far more readable. > As assorted experts have suggested, you need a stateful rule. It's=20 > really not that hard; if you _only_ needed to protect ntp on udp: > > kldload ipfw && add 65000 allow ip from any to any # load null fw > ipfw add allow udp from me to any ntp out xmit $outsideif keep-state > ipfw add deny udp from any to me ntp in recv $outsideif > > Done. Perfectly configured for this one purpose, statefully no less .. Wrong, wrong, wrong. Whitelist, not blacklist. I haven't used ipfw in years, but with pf: | set block-policy return | set skip on lo0 | scrub in all | block quick inet6 | block log all |=20 | # allow ping | pass inet proto icmp all icmp-type echoreq |=20 | # allow incoming ssh | pass in inet proto tcp from any to self port ssh |=20 | # allow outgoing tcp | pass out on proto tcp from self to any |=20 | # allow outgoing DNS and NTP | pass out inet proto udp from self to any port { domain, ntp } Unlike ipfw, pf keeps state by default and retains it when you reload the ruleset, so you can safely do "sudo service pf reload" over ssh. Note that I didn't include echoresp in the list of allowed ICMP types, because an incoming or outgoing echoreq packet will create a state rule which allows the corresponding echoresp. I have the following rule at on at least one machine: | # Allow outgoing TCP RST packets | pass out proto tcp from any to any flags R/R no state but I don't remember the exact circumstances in which outgoing RST packets were being blocked. Try connecting to a TCP port other than ssh from outside, and if the connection times out instead of immediately failing, you need the RST rule. This ruleset blocks UDP traceroute. Use TCP ('traceroute -P TCP host') instead. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 19:20:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68C8C2D0 for ; Fri, 21 Mar 2014 19:20:44 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4915F6C2 for ; Fri, 21 Mar 2014 19:20:43 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0C2B53AD93 for ; Fri, 21 Mar 2014 12:20:37 -0700 (PDT) From: "Ronald F. Guilmette" cc: "freebsd-security@freebsd.org" Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: Date: Fri, 21 Mar 2014 12:20:37 -0700 Message-ID: <51381.1395429637@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 19:20:44 -0000 In message , Remko Lodder wrote: >Reading the mails from this thread leads me to believe that there is no >stateful firewall concept in place? I am not the poster to whom you were responding (info@rit.lt), however speaking only for myself I will confess that yes, in my case at least, although I have used ipfw for many years, I have never (until now) found any compelling need to either understand or make use of any of ipfw's stateful capabilities. >In my believing it is so that if you do not filter traffic, you are >making a deliberate choice to let everyone smack your service(s). I personally *do* most certainly filter traffic, and have done, since I first connected *any* machine of mine to the Internet. I can assure yoy that I never made any deliberate choice to let everyone smack me around. Nontheless, that clearly did happen, eventually, when evil-doers decided, relatively recently, to use & abuse me as an NTP reflector, but my participation in this was not in any sense deliberate on my part, and arose strictly out of ignorance, for which I am suitably humbled and apologetic. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 19:34:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FC45F9B for ; Fri, 21 Mar 2014 19:34:41 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 3B52090D for ; Fri, 21 Mar 2014 19:34:40 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 1167C3ADFA for ; Fri, 21 Mar 2014 12:34:36 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <20140321122701.AC6D411A9DE6@rock.dv.isc.org> Date: Fri, 21 Mar 2014 12:34:36 -0700 Message-ID: <51444.1395430476@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 19:34:41 -0000 In message <20140321122701.AC6D411A9DE6@rock.dv.isc.org>, Mark Andrews wrote: >In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmette" >writes: >> I'm no expert, but I'll go out on a limb here anyway and say that the choice >> to make NTP outbound queries always use source port 123 is, as far as I can >> see, really really ill-advised. Did we learn nothing from all of the bruhaha >> a couple of years ago about DNS amplification attacks and the ways that >> were finally settled on to effectively thwart them (most specifically the >> randomization of query source ports)? > >Well for DNS the source port randomisation was to prevent cache >poisoning so no *you* didn't learn anything from port randomisation >in DNS. OK. You're right. I stand corrected and retract my earlier ill-considered comment. >For time you want to reduce the variabilty in code paths taken as >much as posible so no you don't want to be opening up a new socket >every time. Perhaps you and I could debate this specific argument at greater length off-list. For the moment I'll just say that, for me at least, it doesn't seem like a terribly compelling argument. (Obviously, and as I'm sure you well know, BIND has made this work for some time now, and doesn't seem particularly the worse for it.) >Now if you are not running as a server or peer you can >use a different port but that prevents local tools reaching ntpd >to find out how ntpd is doing. There is no other way via which local tools could communicate with a local ntpd?? I may be mis-remembering, but isn't there a sort-of (entirely separate) control port for BIND that is implemented via a local UNIX domain socket? >NTP does have the ability to work out which commands it will accept >and from whom. This stops NTP being used as a amplifier. The built >in configuration has already been changed to make this the default >behaviour. OK, please bear with me...I just want to verify... I have just added the following single line to the end of my /etc/ntp.conf file: disable monitor That's all there is to it? >You can run a stateless firewall with on a NTP client and it is no >longer a reflector which can be directed at any ip address in the >world if you care to. Could you elaborate please? I -believe- that I understand what you just said, but I'd like to be 100% sure that I did. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 20:01:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2AABACC for ; Fri, 21 Mar 2014 20:01:35 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id AD334BCE for ; Fri, 21 Mar 2014 20:01:35 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 068A63ADFA for ; Fri, 21 Mar 2014 13:01:25 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-security@freebsd.org Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <20140322000445.C31989@sola.nimnet.asn.au> Date: Fri, 21 Mar 2014 13:01:25 -0700 Message-ID: <51546.1395432085@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 20:01:35 -0000 In message <20140322000445.C31989@sola.nimnet.asn.au>, Ian Smith wrote: >As assorted experts have suggested, you need a stateful rule. It's >really not that hard; if you _only_ needed to protect ntp on udp: > > kldload ipfw && add 65000 allow ip from any to any # load null fw > ipfw add allow udp from me to any ntp out xmit $outsideif keep-state > ipfw add deny udp from any to me ntp in recv $outsideif > >Done. Perfectly configured for this one purpose, statefully no less .. Sounds great to me! However I've never really used any of the stateful ipfw stuff, so I'm venturing out into what, for me, are unfamiliar waters. So I hope you'll be kind and entertain a question or two, to help me understand exactly what I'm supposed to do. I've just skimmed over the page here: https://www.freebsd.org/doc/handbook/firewalls-ipfw.html and my questions are based on the tutorial information I've found there. First question: In addition to what you have written above, may I safely assume that I also need an additional rule, somewhere early in my entire (numbered) list of rules, that just simply says "check-state"? Second question: In the example text given just about half-way down on the web page cited above, within part of a big block of example rules I see this: # Allow outbound NTP $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state This is more than a little befuddling to me, for one simple reason... I had no idea until now that NTP could even make use of TCP, rather than, or in addition to UDP. But I did look in my /etc/services file and saw this: ntp 123/tcp #Network Time Protocol ntp 123/udp #Network Time Protocol so obviously, yes, both UDP and TCP can be used for the NTP protocol, rather like DNS, I gather. But the example, noted above, as given within the FreeBSD Handbook appears to make the assumption that NTP is using TCP. That still leaves me a bit befuddled, because I had assumed... until now... that tcpd would be doing all of its communicating strictly via UDP. (I mean ntpd's use of UDP, rather than TCP, is _the_ essential thing that has given rise to all of these NTP reflection attacks, no? The IP address spoofing of the intended vctim becomes one helluva lot harder if it has to be done within the context of TCP, rather than UDP, yes?) So, um, when, if ever, does ntpd use TCP, rather than UDP, and how would a sysadmin running ntpd tell it to use either UDP or TCP? (My apologies if this is stuff that everybody else already knows. I sure don't.) Last question: Assuming that my local ntpd is strictly and only using UDP for all communication, would something like the following be a proper set of additions to my current ipfw rules? add 00101 check-state add 00500 pass udp from 123 to any 123 out via $pif keep-state If not, what should I use instead? Thanks in advance for all help & understanding. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 21:28:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F12751D8 for ; Fri, 21 Mar 2014 21:28:27 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [IPv6:2a01:4f8:141:5ffd::25]) by mx1.freebsd.org (Postfix) with ESMTP id 99A7E395 for ; Fri, 21 Mar 2014 21:28:27 +0000 (UTC) Received: from [IPv6:2001:470:d701::e1fc:8948:56ee:29ea] (unknown [IPv6:2001:470:d701:0:e1fc:8948:56ee:29ea]) by mail.jr-hosting.nl (Postfix) with ESMTPSA id 337793F492; Fri, 21 Mar 2014 22:28:25 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_7154F1F9-7C28-40EA-BF8B-62041B9AE070"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: NTP security hole CVE-2013-5211? From: Remko Lodder In-Reply-To: <51381.1395429637@server1.tristatelogic.com> Date: Fri, 21 Mar 2014 22:28:23 +0100 Message-Id: <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org> References: <51381.1395429637@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.1874) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 21:28:28 -0000 --Apple-Mail=_7154F1F9-7C28-40EA-BF8B-62041B9AE070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Mar 2014, at 20:20, Ronald F. Guilmette = wrote: >=20 > In message ,=20 > Remko Lodder wrote: >=20 >> Reading the mails from this thread leads me to believe that there is = no >> stateful firewall concept in place? >=20 > I am not the poster to whom you were responding (info@rit.lt), however > speaking only for myself I will confess that yes, in my case at least, > although I have used ipfw for many years, I have never (until now) = found > any compelling need to either understand or make use of any of ipfw's > stateful capabilities. Hi Ronald, That is =91fine=92 ofcourse but makes you vulnerable to the =91crap=92 = that is hitting your doorway now. Rest assured that you are already doing a great step = in at least filtering your machines and as you demonstrate you are active on the internet to get the information you need to do it properly. That is = already way better then a lot of other people. A question that pops my mind: Do you think we (security people) needed = to be more verbose about why this might have been a good idea? or could we = have done a better job in reasoning why stateful has it=92s advantages? >=20 >> In my believing it is so that if you do not filter traffic, you are >> making a deliberate choice to let everyone smack your service(s). >=20 > I personally *do* most certainly filter traffic, and have done, since > I first connected *any* machine of mine to the Internet. I can assure > yoy that I never made any deliberate choice to let everyone smack me > around. Nontheless, that clearly did happen, eventually, when = evil-doers > decided, relatively recently, to use & abuse me as an NTP reflector, = but > my participation in this was not in any sense deliberate on my part, = and > arose strictly out of ignorance, for which I am suitably humbled and > apologetic. Let me offer my apologies, I did not want to make you feel ignorant or = anything. What I meant is that everyone should filter on their machines, or if = possible even ahead of their machines at the gateways. Stopping traffic you do = not want should occur at the border so that it never ever reaches the machines it = is not supposed to reach. People do make a living in =91pestering=92 you and I (and many others) = and now smacking your NTP server(s) is gaining them something, or they wouldn=92t = just do it. My best advice in this case might be that only allowing in the networks = you want to have in on your NTP server (Stateful) prevents people that you = do not want to have their in the first place. Only letting out the traffic you = want (also stateful) prevents bogus replies because they most likely are = caught at the firewall already. Ofcourse the software should be well protected as well, and secteam@ did = his best to offer the best solution possible. Though as mentioned by Brett = for example we just cannot force the update of ntpd.conf on user machines = because every admin could have legitimate reasons for having a configuration in = place they decided to have. It=92s risky to change those things and especially = enforce them on running machines. Most of his ideas were in the advisory already except for the =91disable monitor=92 part, which might be reason to = discuss whether that makes sense or not. Thank you, Remko >=20 >=20 > Regards, > rfg > _______________________________________________ > 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 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News --Apple-Mail=_7154F1F9-7C28-40EA-BF8B-62041B9AE070 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJTLK73AAoJEKjD27JZ84ywMpcQAKINH2ZhAOthD+12a6acMRG4 5cDfWQb//28/2Brzxx7O7V/VANxW2gkd+FU+nNP8jaE0yQYfWufEPz4u8ZHqgfJy hPDCenASgYUJ189vJBODl7WMJw0vpr0mHnK9LEf9VXAX6Y/KhdL5kYxeHSL3qhOk um72FOqXRry10XttgIIu3aNToNqkV6rbfQp7eHmbsCl/eetN5XDAGnqmr5DKBeLq WUcwqhuzGPpPQtINH7+sQ24PFE8YtRUP7nIVhIXgffIy+iBMP6J4JY2SUIvyRxtk SeaLyMhXHW26e3SRTkC6gHhOgS3BsMeOhmSB7OMG3sLPOBw0m4bw1tVAK35nMMws CqCACV2O3JYr3u9ThlNl7Hke6oCl8P4f3N8LKaWjrH5KLvR6ci9ApLKv2lhFWAzQ eJN5Xr9ghEzqctsIEeKXgeh+tIqMSDTSsmVrIwV3lgK9tLLtTcnOQ+NouC7IdJa+ 5bu8kqfir1/Ih8A9Dh93IKFodzoNGQgN4j0HGtceqWig6BDxopcpycaANYZm/qLw v9xxsWzuuwuaALfJv1Z/I5EEsjn59UaF8AM0jiE4L8piTq70Zc19KLUTA496zX5/ +8q5jQN9yLxfMkXyjrWSZq0lJGGH8/LLMuCvyXZOdnLuiYSVr6O+qz0DlzxSIJ4g SjAbXlt1cFY3V+mxIgvV =nHAw -----END PGP SIGNATURE----- --Apple-Mail=_7154F1F9-7C28-40EA-BF8B-62041B9AE070-- From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:07:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA5469BD for ; Sat, 22 Mar 2014 00:07:01 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id AA6273D9 for ; Sat, 22 Mar 2014 00:07:01 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id E222A3AD93 for ; Fri, 21 Mar 2014 17:07:00 -0700 (PDT) From: "Ronald F. Guilmette" cc: "freebsd-security@freebsd.org" Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org> Date: Fri, 21 Mar 2014 17:07:00 -0700 Message-ID: <52999.1395446820@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:07:02 -0000 In message <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org>, Remko Lodder wrote: >Rest assured that you are already doing a great step in at >least filtering your machines and as you demonstrate you are active on >the internet to get the information you need to do it properly. Well, one tries. But it is clear that I could have done better. >A question that pops my mind: Do you think we (security people) needed >to be more verbose about why this might have been a good idea? This what? >or could we have >done a better job in reasoning why stateful has it=92s advantages? I can only speak for myself. For me personally, because I already had a fair amount of knowledge about IP protocols generally (e.g. TCP & UDP), even before I encountered this one specific (ntp) problem, it was not at all difficult to understand... once I was told that the FreeBSD ntpd always originates its queries from 123... why stateful firewall rules would be spectacularly helpful, at least within this one specific context. So my personal answer is "No, there is no need for anyone to write more than is already readily available on the net to explain why stateful rules can sometimes be a very exacting, scalple-like solution for certain problems, like, in particular, this one. And my own ipfw rules set _does_ now include a stateful rule for NTP traffic. I am pleased to say it seems to be working perfectly so far. >Let me offer my apologies, I did not want to make you feel ignorant >or anything. No no! Don't worry. I did that all by myself. I *was* in fact ignorant of a number of things at the outset of this recent unfortunate exploitation episode, in particular (a) that ntpd originates outbound queries from port 123 and also (b) how to actually make use of the stateful features of ipfw. But thanks to the kind help I've received here I am no longer ignorant of these things. (Ignorance is only a cause for minimal shame. Actual stupidity is a rather less excusable sin... one which I hope I am only rarely guilty of.) >What I meant is that everyone should filter on their machines, or if >possible >even ahead of their machines at the gateways. Stopping traffic you do >not want >should occur at the border so that it never ever reaches the machines it >is not >supposed to reach. Of course! When I spoke earlier, and with rather sweeping generalities, about "FreeBSD-based devices" I was thinking about some of the several home entertainment gadgets that I've acquired recently (even though probably all of those are actually running some flavor of Linux). At least a couple of those need to know what time it is. I have been quite deliberate in keeping all of those new gadgets well and truly behind my Linksys E2000 (and thus NAT) which I believe is protecting them from essentially all outside hostilities. My server however is a different matter. It's direct-connected to the net, via my ISP. So it needs to protect itself, without expecting any help from any other boxes. And until this whole recent NTP ruckus, I belived that I had it set up properly to do exactly that, and perfectly. Well, as the old saying goes, "Close only counts in horse-shoes and atom bombs." >Ofcourse the software should be well protected as well... Yes. When it comes to security, I, for one, am very much a "belt and suspenders" kind of guy. So I now have _both_ a stateful firewall rule for my NTP traffic _and_ also I've added "disable monitor" to my ntp.conf file. That ought to do it, I think. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:10:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75A99ADA for ; Sat, 22 Mar 2014 00:10:47 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 584655F9 for ; Sat, 22 Mar 2014 00:10:47 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 09C363AD93 for ; Fri, 21 Mar 2014 17:10:47 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <532CC8CF.4030508@elischer.org> Date: Fri, 21 Mar 2014 17:10:47 -0700 Message-ID: <53019.1395447047@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:10:47 -0000 In message <532CC8CF.4030508@elischer.org>, Julian Elischer wrote: >>> 50.116.38.157 >>> 69.50.219.51 >>> 69.55.54.17 >>> 69.167.160.102 >>> 108.61.73.244 >>> 129.250.35.251 >>> 149.20.68.17 >>> 169.229.70.183 >>> 192.241.167.38 >>> 199.7.177.206 >>> 209.114.111.1 >>> 209.118.204.201 > >You can't use this list because the members of the pool change over time. Yes. I've understood that now. Thank you. >you need the following rules placed in the correct places in your ruleset. > >check-state > and >allow udp from me to any 123 out via ${oif} keep-state. I've implemented this now, and it seems to be working great. My sincere thanks to everyone who stepped forward to help. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:13:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60829BD3; Sat, 22 Mar 2014 00:13:31 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 07F6E69F; Sat, 22 Mar 2014 00:13:30 +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 SAA15675; Fri, 21 Mar 2014 18:13:22 -0600 (MDT) Message-Id: <201403220013.SAA15675@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Mar 2014 18:13:10 -0600 To: Remko Lodder , "Ronald F. Guilmette" From: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? In-Reply-To: <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org> References: <51381.1395429637@server1.tristatelogic.com> <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:13:31 -0000 At 03:28 PM 3/21/2014, Remko Lodder wrote: >Ofcourse the software should be well protected as well, and secteam@ did his >best to offer the best solution possible. Though as mentioned by Brett for >example we just cannot force the update of ntpd.conf on user machines because >every admin could have legitimate reasons for having a configuration in place >they decided to have. It's risky to change those things and especially enforce >them on running machines. Most of his ideas were in the advisory already >except for the 'disable monitor' part, which might be reason to discuss >whether that makes sense or not. I've suggested one other thing, and still think it would be a good idea to thwart attacks: that we compile ntpd to source outgoing queries from randomly selected ephemeral UDP ports rather than UDP port 123. (This was, in fact, done in earlier releases of FreeBSD and I'm unsure why it was changed.) This makes stateful firewalling less necessary and improves its performance if it is done. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:14:46 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98D3BCB2 for ; Sat, 22 Mar 2014 00:14:46 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79B206B6 for ; Sat, 22 Mar 2014 00:14:46 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s2M0EVRZ094760; Fri, 21 Mar 2014 16:14:35 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201403220014.s2M0EVRZ094760@gw.catspoiler.org> Date: Fri, 21 Mar 2014 17:14:31 -0700 (PDT) From: Don Lewis Subject: Re: NTP security hole CVE-2013-5211? To: brett@lariat.org In-Reply-To: <201403202028.OAA01351@mail.lariat.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-security@FreeBSD.org, rfg@tristatelogic.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:14:46 -0000 On 20 Mar, Brett Glass wrote: > IMHO, you should diddle /etc/ntp.conf as I mentioned in my earlier message > AND use stateful firewall rules (IPFW works fine for this) to ensure that > you only accept incoming NTP packets which are answers to your own queries. > And, as you state above, outbound queries should use randomized ephemeral > source ports as with DNS. This involves a patch to the ntpd that's shipped > with FreeBSD, because it is currently compiled to use source port 123. > (Back in the days of FreeBSD 5.x and 6.x, it used ephemeral source ports, > but not now.) So far as I know, ntpd on FreeBSD has never used ephemeral source ports for queries. Neither does ntpdate, unless it is run as non-root or with the -u option. If you use symmetric mode (with the peer keyword instead of server in ntp.conf) then the protocol requires port 123 on both ends. In addition to locking down the outside interface of my firewall box with ipfw, I also lock down the inside interface. I greatly restrict the UDP packets between the firewall and inside network. For NTP, I constrain it to only using port 123 on the firewall and port 123 on the inside hosts. I've been using that configuration since the 4.x days and both ntpd and ntpdate have functioned without issue. I can't query ntpd on the firewall from the inside network with ntpq, which uses a high numbered port. I actually have to log on to the firewall and run ntpq there. From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:18:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 764CEE53 for ; Sat, 22 Mar 2014 00:18:02 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 101706EB for ; Sat, 22 Mar 2014 00:18:02 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id A125823841F; Sat, 22 Mar 2014 00:17:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AFF66160060; Sat, 22 Mar 2014 00:18:52 +0000 (UTC) Received: from rock.dv.isc.org (unknown [216.9.110.12]) by zmx1.isc.org (Postfix) with ESMTPSA id A2BD716005B; Sat, 22 Mar 2014 00:18:52 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C296311AF38F; Sat, 22 Mar 2014 11:17:45 +1100 (EST) To: "Ronald F. Guilmette" From: Mark Andrews References: <51546.1395432085@server1.tristatelogic.com> Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-reply-to: Your message of "Fri, 21 Mar 2014 13:01:25 -0700." <51546.1395432085@server1.tristatelogic.com> Date: Sat, 22 Mar 2014 11:17:45 +1100 Message-Id: <20140322001745.C296311AF38F@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:18:02 -0000 In message <51546.1395432085@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <20140322000445.C31989@sola.nimnet.asn.au>, > Ian Smith wrote: > > >As assorted experts have suggested, you need a stateful rule. It's > >really not that hard; if you _only_ needed to protect ntp on udp: > > > > kldload ipfw && add 65000 allow ip from any to any # load null fw > > ipfw add allow udp from me to any ntp out xmit $outsideif keep-state > > ipfw add deny udp from any to me ntp in recv $outsideif > > > >Done. Perfectly configured for this one purpose, statefully no less .. > > Sounds great to me! However I've never really used any of the stateful > ipfw stuff, so I'm venturing out into what, for me, are unfamiliar waters. > So I hope you'll be kind and entertain a question or two, to help me > understand exactly what I'm supposed to do. > > I've just skimmed over the page here: > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html > > and my questions are based on the tutorial information I've found there. > > First question: In addition to what you have written above, may I safely > assume that I also need an additional rule, somewhere early in my entire > (numbered) list of rules, that just simply says "check-state"? > > Second question: In the example text given just about half-way down on > the web page cited above, within part of a big block of example rules I > see this: > > # Allow outbound NTP > $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state > > This is more than a little befuddling to me, for one simple reason... I had > no idea until now that NTP could even make use of TCP, rather than, or in > addition to UDP. But I did look in my /etc/services file and saw this: > > ntp 123/tcp #Network Time Protocol > ntp 123/udp #Network Time Protocol > > so obviously, yes, both UDP and TCP can be used for the NTP protocol, > rather like DNS, I gather. No. IANA (Jon) just assigned/reserved both UDP and TCP for all protocols at the time. HTTP is also listed as UDP and TCP but it is only TCP with UDP reserved. > But the example, noted above, as given > within the FreeBSD Handbook appears to make the assumption that NTP is > using TCP. That still leaves me a bit befuddled, because I had assumed... > until now... that tcpd would be doing all of its communicating strictly > via UDP. (I mean ntpd's use of UDP, rather than TCP, is _the_ essential > thing that has given rise to all of these NTP reflection attacks, no? > The IP address spoofing of the intended vctim becomes one helluva lot > harder if it has to be done within the context of TCP, rather than UDP, > yes?) > > So, um, when, if ever, does ntpd use TCP, rather than UDP, and how would > a sysadmin running ntpd tell it to use either UDP or TCP? NTP uses UDP. Period. > (My apologies if this is stuff that everybody else already knows. I sure > don't.) > > Last question: Assuming that my local ntpd is strictly and only using > UDP for all communication, would something like the following be a proper > set of additions to my current ipfw rules? > > add 00101 check-state > add 00500 pass udp from 123 to any 123 out via $pif keep-stat > e > > If not, what should I use instead? > > Thanks in advance for all help & understanding. > > > Regards, > rfg > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:24:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 841194B2 for ; Sat, 22 Mar 2014 00:24:27 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EB7A814 for ; Sat, 22 Mar 2014 00:24:27 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id AC20C238411; Sat, 22 Mar 2014 00:24:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ACE60160066; Sat, 22 Mar 2014 00:25:13 +0000 (UTC) Received: from rock.dv.isc.org (unknown [216.9.110.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A922D16005B; Sat, 22 Mar 2014 00:25:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A27F311AF3F5; Sat, 22 Mar 2014 11:24:06 +1100 (EST) To: "Ronald F. Guilmette" From: Mark Andrews References: <51444.1395430476@server1.tristatelogic.com> Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-reply-to: Your message of "Fri, 21 Mar 2014 12:34:36 -0700." <51444.1395430476@server1.tristatelogic.com> Date: Sat, 22 Mar 2014 11:24:06 +1100 Message-Id: <20140322002406.A27F311AF3F5@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:24:27 -0000 In message <51444.1395430476@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <20140321122701.AC6D411A9DE6@rock.dv.isc.org>, > Mark Andrews wrote: > > >In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmett > e" > >writes: > >> I'm no expert, but I'll go out on a limb here anyway and say that the choi > ce > >> to make NTP outbound queries always use source port 123 is, as far as I ca > n > >> see, really really ill-advised. Did we learn nothing from all of the bruh > aha > >> a couple of years ago about DNS amplification attacks and the ways that > >> were finally settled on to effectively thwart them (most specifically the > >> randomization of query source ports)? > > > >Well for DNS the source port randomisation was to prevent cache > >poisoning so no *you* didn't learn anything from port randomisation > >in DNS. > > OK. You're right. I stand corrected and retract my earlier ill-considered > comment. > > >For time you want to reduce the variabilty in code paths taken as > >much as posible so no you don't want to be opening up a new socket > >every time. > > Perhaps you and I could debate this specific argument at greater length > off-list. For the moment I'll just say that, for me at least, it doesn't > seem like a terribly compelling argument. (Obviously, and as I'm sure you > well know, BIND has made this work for some time now, and doesn't seem > particularly the worse for it.) When you are trying to keep and serve accurate time it is very much a argument. Opening new sockets is expensive for BIND. It significantly affects the number of recursive requests a server can make. It requires lots of extra management. > >Now if you are not running as a server or peer you can > >use a different port but that prevents local tools reaching ntpd > >to find out how ntpd is doing. > > There is no other way via which local tools could communicate with a local > ntpd?? > > I may be mis-remembering, but isn't there a sort-of (entirely separate) > control port for BIND that is implemented via a local UNIX domain socket? > > >NTP does have the ability to work out which commands it will accept > >and from whom. This stops NTP being used as a amplifier. The built > >in configuration has already been changed to make this the default > >behaviour. > > OK, please bear with me...I just want to verify... > > I have just added the following single line to the end of my /etc/ntp.conf > file: > > disable monitor > > That's all there is to it? > > >You can run a stateless firewall with on a NTP client and it is no > >longer a reflector which can be directed at any ip address in the > >world if you care to. > > Could you elaborate please? > > I -believe- that I understand what you just said, but I'd like to be 100% > sure that I did. > > > Regards, > rfg > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 23:19:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1A0CD3A for ; Fri, 21 Mar 2014 23:19:00 +0000 (UTC) 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 C5BA9F18 for ; Fri, 21 Mar 2014 23:19:00 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2LNIn0F097778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Mar 2014 16:18:50 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <532CC8CF.4030508@elischer.org> Date: Fri, 21 Mar 2014 16:18:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brett Glass , "Ronald F. Guilmette" Subject: Re: NTP security hole CVE-2013-5211? References: <201403210421.WAA05406@mail.lariat.net> In-Reply-To: <201403210421.WAA05406@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 22 Mar 2014 00:43:26 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 23:19:01 -0000 On 3/20/14, 9:20 PM, Brett Glass wrote: > At 03:37 PM 3/20/2014, Ronald F. Guilmette wrote: > >> Starting from these lines in my /etc/ntp.conf file: >> >> server 0.freebsd.pool.ntp.org iburst >> server 1.freebsd.pool.ntp.org iburst >> server 2.freebsd.pool.ntp.org iburst >> >> I resolved each of those three host names to _all_ of its associated >> IPv4 addresses. This yielded me the following list: >> >> 50.116.38.157 >> 69.50.219.51 >> 69.55.54.17 >> 69.167.160.102 >> 108.61.73.244 >> 129.250.35.251 >> 149.20.68.17 >> 169.229.70.183 >> 192.241.167.38 >> 199.7.177.206 >> 209.114.111.1 >> 209.118.204.201 You can't use this list because the members of the pool change over time. you need the following rules placed in the correct places in your ruleset. check-state and allow udp from me to any 123 out via ${oif} keep-state. unless a udp packet first exits via the second rule, the first will not match and will continue on to further rules (which should throw it away one hopes). Once an outgoing udp packet to 123 has been seen on the second rule, any response will be allowed for the next N seconds. (it's some small integer from memory) any copy o fhtat packet that comes after the timeout will be dropped again. > > [Snip] > > All of this is good. However, remember that anyone who can spoof IPs > will know > that the above addresses are the defaults for any FreeBSD machine > and can > take advantage of these "holes" in your firewall. > > --Brett Glass > _______________________________________________ > 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 Mar 22 08:34:53 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97BBCC0D for ; Sat, 22 Mar 2014 08:34:53 +0000 (UTC) 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 EAE9925B for ; Sat, 22 Mar 2014 08:34:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s2M8YmDq088694; Sat, 22 Mar 2014 19:34:49 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 22 Mar 2014 19:34:48 +1100 (EST) From: Ian Smith To: "Ronald F. Guilmette" Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <51546.1395432085@server1.tristatelogic.com> Message-ID: <20140322182402.Q83569@sola.nimnet.asn.au> References: <51546.1395432085@server1.tristatelogic.com> 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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 08:34:53 -0000 On Fri, 21 Mar 2014 13:01:25 -0700, Ronald F. Guilmette wrote: > In message <20140322000445.C31989@sola.nimnet.asn.au>, > Ian Smith wrote: > > >As assorted experts have suggested, you need a stateful rule. It's > >really not that hard; if you _only_ needed to protect ntp on udp: > > > > kldload ipfw && add 65000 allow ip from any to any # load null fw > > ipfw add allow udp from me to any ntp out xmit $outsideif keep-state > > ipfw add deny udp from any to me ntp in recv $outsideif > > > >Done. Perfectly configured for this one purpose, statefully no less .. > > Sounds great to me! However I've never really used any of the stateful > ipfw stuff, so I'm venturing out into what, for me, are unfamiliar waters. So I gathered from earlier posts, which is why I thought to spell it out - as did Julian more succinctly, I see - as not being too scary :) > So I hope you'll be kind and entertain a question or two, to help me > understand exactly what I'm supposed to do. > > I've just skimmed over the page here: > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html > > and my questions are based on the tutorial information I've found there. Firstly, that's the one page in the handbook (that I know of) that needs completely nuking. It contains many factual errors as well as weird notions, and will only tend to mislead you; consult ipfw(8) and prosper. I'd say refer to the examples in rc.firewall but it too is in disrepair. > First question: In addition to what you have written above, may I safely > assume that I also need an additional rule, somewhere early in my entire > (numbered) list of rules, that just simply says "check-state"? In that specific ruleset - for one specific purpose, remember - no. In general yes; in a ruleset containing other rules, check-state should be placed where you want packets tested against all active dynamic rules. ipfw checks and acts upon state at the first check-state OR keep-state rule encountered - which is why it was refundant in the example above. > Second question: In the example text given just about half-way down on > the web page cited above, within part of a big block of example rules I > see this: > > # Allow outbound NTP > $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state time 37/tcp timserver time 37/udp timserver I know nothing about that protocol; it's not NTP anyway, but is yet another great example of why that handbook page should be avoided. Thanks to Mark for explaining that NTP only works over UDP, so .. [..] > Last question: Assuming that my local ntpd is strictly and only using > UDP for all communication, would something like the following be a proper > set of additions to my current ipfw rules? > > add 00101 check-state > add 00500 pass udp from 123 to any 123 out via $pif keep-state > > If not, what should I use instead? Sure. You don't need to specify 123 as source port, in case Brett gets his wish for NTP to change to random source ports - good luck with that! - or if this were a router for a local LAN where clients - I notice OS/X boxes regularly - do use a random high source port for NTP queries. cheers, Ian From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 14:54:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63AF5E4A for ; Sat, 22 Mar 2014 14:54:29 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1A76E601 for ; Sat, 22 Mar 2014 14:54:28 +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 IAA22021; Sat, 22 Mar 2014 08:54:13 -0600 (MDT) Message-Id: <201403221454.IAA22021@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 22 Mar 2014 08:48:40 -0600 To: Ian Smith , "Ronald F. Guilmette" From: Brett Glass Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <20140322182402.Q83569@sola.nimnet.asn.au> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> 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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 14:54:29 -0000 At 02:34 AM 3/22/2014, Ian Smith wrote: >In that specific ruleset - for one specific purpose, remember - no. In >general yes; in a ruleset containing other rules, check-state should be >placed where you want packets tested against all active dynamic rules. This is correct. And that's awkward, because you might not want all of these checks in one place. Also, if there are many dynamic rules this will slow traffic down quite a bit. It's a general security principle that the daemons included with an OS should be secure on their own; they shouldn't, by default, require protection by a firewall. This is certainly true of ntpd, which is part of the base FreeBSD distribution. The FreeBSD Project should set a good example, and conform to industry best practices, by making the system secure by default. This means including a default daemon configuration that is resistant to relaying and amplification of attacks. Adding the "disable monitor" and "kod" options to ntp.conf is a start, but sourcing queries from random source ports is much more important. It would create negligible overhead (because NTP queries have much lower volume than DNS) and would allow the daemon to defend ITSELF from abuse rather than relying on a stateful firewall. As you've mentioned, Apple already does this in Darwin, a FreeBSD derivative. I haven't checked the latest releases of OpenBSD and NetBSD, but the older machines I have running these OSes appear to use randomized high ports for queries. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 15:12:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B908E4E6 for ; Sat, 22 Mar 2014 15:12:02 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 513927F3 for ; Sat, 22 Mar 2014 15:12:02 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so2311352wes.20 for ; Sat, 22 Mar 2014 08:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=L4d6NAlMX/o4eegDTUiaKixXUkxnbzp8RL0bRq8UBE0=; b=htFZhkUXis2ODvv+6BuJ8B4OY9VPbIqDSyocNgO10Zj1xiStizLryzqiJ6o3yLBFEk wuTc2DLRaoAveajFNPejzxjy/Uw9I5l3x4bfFmiMVFsXJCA32g2Aj/SJsZAPR2iWfsC4 g0D67X8fR3vKiClP7jgM0u3Kms0VAHG0fP4cLPwxeU8QcuZnNz49d9c/mfPqsIUhQW1n a1Mw8/IBggasGoliOALpRfcYTCFoCxADaPZvsD3EL/5SrFuScRxAq8E1Mt2TPM0fhJmc 5gYkNX0o5yPDiqTvp1WyQyOSRjcINH3OsfUJ3RkZSye3N7YizezX1d79AeASc4T2Fd6F EHyg== X-Received: by 10.180.185.232 with SMTP id ff8mr3960386wic.25.1395501120232; Sat, 22 Mar 2014 08:12:00 -0700 (PDT) Received: from gumby.homeunix.com ([94.195.197.72]) by mx.google.com with ESMTPSA id hp5sm18024393wjb.0.2014.03.22.08.11.58 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 22 Mar 2014 08:11:59 -0700 (PDT) Date: Sat, 22 Mar 2014 15:11:55 +0000 From: RW To: freebsd-security@freebsd.org Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) Message-ID: <20140322151155.184d5229@gumby.homeunix.com> In-Reply-To: <201403221454.IAA22021@mail.lariat.net> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 15:12:02 -0000 On Sat, 22 Mar 2014 08:48:40 -0600 Brett Glass wrote: > This is correct. And that's awkward, because you might not want all of > these checks in one place. Also, if there are many dynamic rules this > will slow traffic down quite a bit. It should be the other way around. Once a flow has been learned it's just a simple hash-table lookup once you hit the first stateful rule. In pf most packets bypass the rules altogether. From owner-freebsd-security@FreeBSD.ORG Sun Mar 23 05:34:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49A35808; Sun, 23 Mar 2014 05:34:04 +0000 (UTC) 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 1882B9; Sun, 23 Mar 2014 05:34:03 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2N5XtLT002560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 22:33:56 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532E723C.2090109@freebsd.org> Date: Sat, 22 Mar 2014 22:33:48 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: RW , freebsd-security@freebsd.org, ipfw@FreeBSD.org Subject: Re: URGENT? References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> In-Reply-To: <20140322151155.184d5229@gumby.homeunix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 05:34:04 -0000 On 3/22/14, 8:11 AM, RW wrote: > On Sat, 22 Mar 2014 08:48:40 -0600 > Brett Glass wrote: > >> This is correct. And that's awkward, because you might not want all of >> these checks in one place. Also, if there are many dynamic rules this >> will slow traffic down quite a bit. in ipfw that's up to you.. but I usually put the check-state quite early in my rule sets. I am working on a new rc.firewall that is much more efficient. the trouble is that the script to make it do what I want is a bit more complicated. I'll put it out for discussion later. maybe tonight. > It should be the other way around. Once a flow has been learned it's > just a simple hash-table lookup once you hit the first stateful rule. > In pf most packets bypass the rules altogether. > _______________________________________________ > 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 Sun Mar 23 05:39:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C62AAA58; Sun, 23 Mar 2014 05:39:44 +0000 (UTC) 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 9963AFC; Sun, 23 Mar 2014 05:39:44 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2N5dhC8002575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 22:39:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532E7398.5090607@freebsd.org> Date: Sat, 22 Mar 2014 22:39:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: RW , freebsd-security@freebsd.org, ipfw@FreeBSD.org Subject: Re: ipfw dynamic rules References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> In-Reply-To: <532E723C.2090109@freebsd.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 05:39:44 -0000 reposting with a useful subject line and more comments On 3/22/14, 10:33 PM, Julian Elischer wrote: > > in ipfw that's up to you.. > but I usually put the check-state quite early in my rule sets. > On 3/22/14, 1:34 AM, Ian Smith wrote: > Firstly, that's the one page in the handbook (that I know of) that needs > completely nuking. It contains many factual errors as well as weird > notions, and will only tend to mislead you; consult ipfw(8) and prosper. > I'd say refer to the examples in rc.firewall but it too is in disrepair. I am working on a new rc.firewall that is much more efficient. the trouble is that the script to make it do what I want is a bit more complicated. I'll put it out for discussion later. maybe tonight. as for the handbook pages.. after we see how the new firewall rules work we can see about rewriting the page. From owner-freebsd-security@FreeBSD.ORG Sun Mar 23 13:16:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A44FECD; Sun, 23 Mar 2014 13:16:29 +0000 (UTC) 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 E7CE08C6; Sun, 23 Mar 2014 13:16:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s2NDGQr2048012; Mon, 24 Mar 2014 00:16:26 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Mar 2014 00:16:26 +1100 (EST) From: Ian Smith To: Julian Elischer Subject: Re: ipfw dynamic rules In-Reply-To: <532E7398.5090607@freebsd.org> Message-ID: <20140324000439.F87212@sola.nimnet.asn.au> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <532E7398.5090607@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org, RW , ipfw@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 13:16:29 -0000 On Sat, 22 Mar 2014 22:39:36 -0700, Julian Elischer wrote: > reposting with a useful subject line and more comments > > On 3/22/14, 10:33 PM, Julian Elischer wrote: > > > > in ipfw that's up to you.. > > but I usually put the check-state quite early in my rule sets. > > > On 3/22/14, 1:34 AM, Ian Smith wrote: > > Firstly, that's the one page in the handbook (that I know of) that needs > > completely nuking. It contains many factual errors as well as weird > > notions, and will only tend to mislead you; consult ipfw(8) and prosper. > > I'd say refer to the examples in rc.firewall but it too is in disrepair. Firstly, I owe an apology to the doc crew, one of whom contacted me privately to point out that the ipfw page has had quite a massaging lately, and work is ongoing. I'm sorry for not checking again first. > I am working on a new rc.firewall that is much more efficient. > the trouble is that the script to make it do what I want is a bit more > complicated. > I'll put it out for discussion later. maybe tonight. Great. Maybe my failed rc.firewall patch from '11 can still be useful. > as for the handbook pages.. after we see how the new firewall rules work > we can see about rewriting the page. Yes, well it seems there's a newer framework worth hanging it on now. I guess we should drop freebsd-security@ until there's some news? cheers, Ian From owner-freebsd-security@FreeBSD.ORG Sun Mar 23 15:00:19 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BA5F71C; Sun, 23 Mar 2014 15:00:19 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id C611E186; Sun, 23 Mar 2014 15:00:18 +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 JAA00968; Sun, 23 Mar 2014 09:00:11 -0600 (MDT) Message-Id: <201403231500.JAA00968@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 23 Mar 2014 08:56:07 -0600 To: Julian Elischer , RW , freebsd-security@freebsd.org, ipfw@freebsd.org From: Brett Glass Subject: Re: URGENT? In-Reply-To: <532E723C.2090109@freebsd.org> References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:00:19 -0000 At 11:33 PM 3/22/2014, Julian Elischer wrote: >in ipfw that's up to you.. >but I usually put the check-state quite early in my rule sets. I don't, because I want packets to touch as few rules as possible for the sake of efficiency. One "check state" can cause an awful lot of work to be done! In my IPFW rule sets, I divide the work up by interface, and so there's a "check-state" only for interfaces and directions (in vs. out) to which automatically generated rules will apply. The problem is that this is still inefficient, because there's only one batch of automatically generated rules, containing some that will never apply in certain situations. My rule sets would be more efficient if I could divide the automatically created rules into multiple batches, and do "keep-state N" and "check-state N" to check only the batch that needed to be tested in a particular spot. This ought to be a relatively easy patch, and I've thought many times about coding and submitting it. "N" would default to zero, so the old behavior would be preserved if there was no "N" at the end so as not to violate POLA. >I am working on a new rc.firewall that is much more efficient. >the trouble is that the script to make it do what I want is a bit >more complicated. >I'll put it out for discussion later. maybe tonight. Would like to see it! --Brett Glass From owner-freebsd-security@FreeBSD.ORG Sun Mar 23 15:47:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFA0198A; Sun, 23 Mar 2014 15:47:44 +0000 (UTC) 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 96CD17E6; Sun, 23 Mar 2014 15:47:44 +0000 (UTC) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s2NFlgbD004437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 08:47:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <532F0217.6050507@freebsd.org> Date: Sun, 23 Mar 2014 08:47:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Brett Glass , RW , freebsd-security@freebsd.org, ipfw@freebsd.org Subject: Re: URGENT? References: <51546.1395432085@server1.tristatelogic.com> <20140322182402.Q83569@sola.nimnet.asn.au> <201403221454.IAA22021@mail.lariat.net> <20140322151155.184d5229@gumby.homeunix.com> <532E723C.2090109@freebsd.org> <201403231500.JAA00968@mail.lariat.net> In-Reply-To: <201403231500.JAA00968@mail.lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:47:44 -0000 On 3/23/14, 7:56 AM, Brett Glass wrote: > At 11:33 PM 3/22/2014, Julian Elischer wrote: > >> in ipfw that's up to you.. >> but I usually put the check-state quite early in my rule sets. > > I don't, because I want packets to touch as few rules as possible > for the sake of > efficiency. One "check state" can cause an awful lot of work to be > done! check state is a hash ;ookup and generally doesn't cause a lot of work. it's about the equivalent of 2 simple rules I would guess so if you save two rules by using check state, then you win. > > In my IPFW rule sets, I divide the work up by interface, and so > there's a > "check-state" only for interfaces and directions (in vs. out) to > which automatically > generated rules will apply. I do the same. first thing my rule set does is break the packet flow into N*4 separate sets of rules, where N is the number of interfaces. Each interface gets two sets of rules.. one for incoming and one for outgoing. each of these it further divided into two smaller sets. One for packets that are for or from THIS machine, and one that is for packets no for or from this machine) incoming, for me incoming NOT for me outgoing from me outgoing NOT from me each of these sets can then have rules. however since we know some of the information already it doesn't need to be tested again so the rules there tend to be "from any to any" because we already know who it's for (or from, depedning on the direction) > The problem is that this is still inefficient, because there's only > one batch of > automatically generated rules, containing some that will never apply > in certain > situations. My rule sets would be more efficient if I could divide > the automatically > created rules into multiple batches, and do "keep-state N" and > "check-state N" to check > only the batch that needed to be tested in a particular spot. This > ought to be a relatively > easy patch, and I've thought many times about coding and submitting > it. "N" would default > to zero, so the old behavior would be preserved if there was no "N" > at the end so as not > to violate POLA. > >> I am working on a new rc.firewall that is much more efficient. >> the trouble is that the script to make it do what I want is a bit >> more complicated. >> I'll put it out for discussion later. maybe tonight. > > Would like to see it! see other emails for sample output. > > --Brett Glass > > From owner-freebsd-security@FreeBSD.ORG Mon Mar 24 15:51:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D152CA94; Mon, 24 Mar 2014 15:51:57 +0000 (UTC) Received: from mail.in-addr.com (noop.in-addr.com [208.58.23.51]) (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 A14BC69C; Mon, 24 Mar 2014 15:51:57 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WS6O8-0002rK-Nw; Mon, 24 Mar 2014 11:02:08 -0400 Date: Mon, 24 Mar 2014 11:02:08 -0400 From: Gary Palmer To: Brett Glass Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <20140324150208.GA5238@in-addr.com> References: <51381.1395429637@server1.tristatelogic.com> <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org> <201403220013.SAA15675@mail.lariat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201403220013.SAA15675@mail.lariat.net> 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" , Remko Lodder , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:51:57 -0000 On Fri, Mar 21, 2014 at 06:13:10PM -0600, Brett Glass wrote: > At 03:28 PM 3/21/2014, Remko Lodder wrote: > > >Ofcourse the software should be well protected as well, and secteam@ did his > >best to offer the best solution possible. Though as mentioned by Brett for > >example we just cannot force the update of ntpd.conf on user machines because > >every admin could have legitimate reasons for having a configuration in place > >they decided to have. It's risky to change those things and especially enforce > >them on running machines. Most of his ideas were in the advisory already > >except for the 'disable monitor' part, which might be reason to discuss > >whether that makes sense or not. > > I've suggested one other thing, and still think it would be a good idea to > thwart attacks: that we compile ntpd to source outgoing queries from randomly > selected ephemeral UDP ports rather than UDP port 123. (This was, > in fact, done > in earlier releases of FreeBSD and I'm unsure why it was changed.) This makes > stateful firewalling less necessary and improves its performance if it is done. Could you please explain how randomising the source port of NTP queries would thwart NTP monitor amplification attacks? The attack works because the NTP control port on the server is always UDP/123, and I don't see how changing the source port would fix that. Unless I'm missing something, you'd need to change the port the daemon accepts queries on, not the port it sources outbound queries on. Thanks, Gary From owner-freebsd-security@FreeBSD.ORG Tue Mar 25 13:56:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9DBBB9A for ; Tue, 25 Mar 2014 13:56:41 +0000 (UTC) Received: from smtp118.ord1c.emailsrvr.com (smtp118.ord1c.emailsrvr.com [108.166.43.118]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87A22E49 for ; Tue, 25 Mar 2014 13:56:41 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BCD3D2F009B for ; Tue, 25 Mar 2014 09:48:14 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 464DC1B95E7 for ; Tue, 25 Mar 2014 09:48:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: NTP security hole CVE-2013-5211? (Gary Palmer) From: Olafur Gudmundsson In-Reply-To: Date: Tue, 25 Mar 2014 09:48:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:56:41 -0000 On Mar 25, 2014, at 8:00 AM, freebsd-security-request@freebsd.org wrote: >=20 > Message: 1 > Date: Mon, 24 Mar 2014 11:02:08 -0400 > From: Gary Palmer > To: Brett Glass > Cc: "freebsd-security@freebsd.org" , > Remko Lodder , "Ronald F. Guilmette" > > Subject: Re: NTP security hole CVE-2013-5211? > Message-ID: <20140324150208.GA5238@in-addr.com> > Content-Type: text/plain; charset=3Dus-ascii >=20 > On Fri, Mar 21, 2014 at 06:13:10PM -0600, Brett Glass wrote: >> At 03:28 PM 3/21/2014, Remko Lodder wrote: >>=20 >>> Ofcourse the software should be well protected as well, and secteam@ = did his >>> best to offer the best solution possible. Though as mentioned by = Brett for >>> example we just cannot force the update of ntpd.conf on user = machines because >>> every admin could have legitimate reasons for having a configuration = in place >>> they decided to have. It's risky to change those things and = especially enforce >>> them on running machines. Most of his ideas were in the advisory = already >>> except for the 'disable monitor' part, which might be reason to = discuss >>> whether that makes sense or not. >>=20 >> I've suggested one other thing, and still think it would be a good = idea to >> thwart attacks: that we compile ntpd to source outgoing queries from = randomly >> selected ephemeral UDP ports rather than UDP port 123. (This was,=20 >> in fact, done >> in earlier releases of FreeBSD and I'm unsure why it was changed.) = This makes >> stateful firewalling less necessary and improves its performance if = it is done. >=20 >=20 > Could you please explain how randomising the source port of NTP = queries > would thwart NTP monitor amplification attacks? The attack works = because > the NTP control port on the server is always UDP/123, and I don't see = how > changing the source port would fix that. Unless I'm missing = something, you'd > need to change the port the daemon accepts queries on, not the port it = sources > outbound queries on. >=20 > Thanks, >=20 > Gary There are three problems=20 0. NTP can be tricked to give out big answer to forged addresses.=20 1. Some NTP servers listen on port 123 all address even when only = expecting to providing service on=20 "internal addresses", 2. NTP servers are easily discoverable due to the listening on fixed = port. =20 Moving the servers of port 123 will make the search for servers harder = but intrusion detection systems=20 will need to be modified to expect NTP traffic on any port.=20 IF and ONLY if people are willing to change how NTP servers are = discovered in DNS then servers can listen on any port.=20 Instead of loping up "A/AAAA" record for a name, the service discovery = should look up SRV record as that includes port number on each server. Even if everyone agrees to = make this change=20 there still has to be "temporarily" backwards hack to allow old software = to find the service.=20 (In the mail world MX (SRV equivalent) use is not universal after over = 25 years).=20 So while it is possible to move NTP servers off port 123 I do not think = it is worth the effort.=20 Olafur From owner-freebsd-security@FreeBSD.ORG Wed Mar 26 06:11:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDC93E93 for ; Wed, 26 Mar 2014 06:11:40 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id B3776C6D for ; Wed, 26 Mar 2014 06:11:40 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.30] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N3100ERM2F69X00@st11p09mm-asmtp002.mac.com> for freebsd-security@freebsd.org; Wed, 26 Mar 2014 05:11:34 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: NTP security hole CVE-2013-5211? (Gary Palmer) From: Kimmo Paasiala In-reply-to: Date: Wed, 26 Mar 2014 07:08:57 +0200 Message-id: References: To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1874) x-icloud-spam-score: 34444444 f=icloud.com; e=icloud.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGBEKTEMXGx0EGx0YBBIZBBscEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsbGmJCH2luHGYcGXhzB xh7Gh8bG3IbEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxwQGx4aHxsRCl5ZF2FLa3N NEQpMRhdia2sRCkNaFxISBBsTHwQbGBIEGRkRCkRYFxgRCkRJFxsRCkJFF2Z9fxNNb1xgZRoSE QpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQpCQBdpWV5 gRUFBS29SZhEKcGcXYB5ZHxJ/U0FFc38RCnBoF2VyHk8aUmwaRUdIEQpwaBdiZEkTQVxzfEhsG BEKcGgXZEF9SXIfT1hAQXARCnBoF2d6YVljWlNGQUl+EQpwaBdja0FdH0RpU0lgXxEKcGcXYn9 IRRJmTm98BU4RCnBnF2YdfWhPTkZZQBITEQpwZxdhYVhaeQFjYmdwRREKcGcXY1hCbl8ZWk9kS WcRCnBnF2NrRh4TRkN5E0hOEQpwZxdmTwVCRmsffkZbZBEKcGsXYRlCbBtISUdfUlgRCnBLF2J pchNYXVxnbVNzEQpwaxdvHmcTbX1vW08ZXREKcGwXbWduBR9hTmEcWxsRCnBMF2BvHWNiGGhQS G1kEQ== X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-03-26_01:2014-03-26,2014-03-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1403250193 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 06:11:41 -0000 --Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25.3.2014, at 15.48, Olafur Gudmundsson wrote: >=20 > On Mar 25, 2014, at 8:00 AM, freebsd-security-request@freebsd.org = wrote: >=20 >>=20 >> Message: 1 >> Date: Mon, 24 Mar 2014 11:02:08 -0400 >> From: Gary Palmer >> To: Brett Glass >> Cc: "freebsd-security@freebsd.org" , >> Remko Lodder , "Ronald F. Guilmette" >> >> Subject: Re: NTP security hole CVE-2013-5211? >> Message-ID: <20140324150208.GA5238@in-addr.com> >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >> On Fri, Mar 21, 2014 at 06:13:10PM -0600, Brett Glass wrote: >>> At 03:28 PM 3/21/2014, Remko Lodder wrote: >>>=20 >>>> Ofcourse the software should be well protected as well, and = secteam@ did his >>>> best to offer the best solution possible. Though as mentioned by = Brett for >>>> example we just cannot force the update of ntpd.conf on user = machines because >>>> every admin could have legitimate reasons for having a = configuration in place >>>> they decided to have. It's risky to change those things and = especially enforce >>>> them on running machines. Most of his ideas were in the advisory = already >>>> except for the 'disable monitor' part, which might be reason to = discuss >>>> whether that makes sense or not. >>>=20 >>> I've suggested one other thing, and still think it would be a good = idea to >>> thwart attacks: that we compile ntpd to source outgoing queries from = randomly >>> selected ephemeral UDP ports rather than UDP port 123. (This was,=20 >>> in fact, done >>> in earlier releases of FreeBSD and I'm unsure why it was changed.) = This makes >>> stateful firewalling less necessary and improves its performance if = it is done. >>=20 >>=20 >> Could you please explain how randomising the source port of NTP = queries >> would thwart NTP monitor amplification attacks? The attack works = because >> the NTP control port on the server is always UDP/123, and I don't see = how >> changing the source port would fix that. Unless I'm missing = something, you'd >> need to change the port the daemon accepts queries on, not the port = it sources >> outbound queries on. >>=20 >> Thanks, >>=20 >> Gary >=20 > There are three problems=20 > 0. NTP can be tricked to give out big answer to forged addresses.=20 > 1. Some NTP servers listen on port 123 all address even when only = expecting to providing service on=20 > "internal addresses", > 2. NTP servers are easily discoverable due to the listening on fixed = port. =20 >=20 > Moving the servers of port 123 will make the search for servers harder = but intrusion detection systems=20 > will need to be modified to expect NTP traffic on any port.=20 >=20 > IF and ONLY if people are willing to change how NTP servers are = discovered in DNS then servers > can listen on any port.=20 > Instead of loping up "A/AAAA" record for a name, the service discovery = should look up SRV record as > that includes port number on each server. Even if everyone agrees to = make this change=20 > there still has to be "temporarily" backwards hack to allow old = software to find the service.=20 > (In the mail world MX (SRV equivalent) use is not universal after over = 25 years).=20 >=20 > So while it is possible to move NTP servers off port 123 I do not = think it is worth the effort.=20 >=20 > Olafur >=20 >=20 I believe Gary was talking about changing the control/status port and = not the actual service port (UDP 123). That should be doable without = breaking compatibility with existing NTP tools. -Kimmo --Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTMmDuAAoJEFvLZC0FWRVpqYgIAKDVzHYimNLQRz5vUfbKphM/ M8PAU6gsc5d30O7td6oRqty5Z3nRT8byHCnEIJrDlDLUBK5YQ+GJdlnj06Kpysnb Tf/CbB5IcCdszhextMp2ahS4JtDJ7ubHbGq6CXp34dJXHcueLjpqAUhIOVya7r9F bmdlHGsDnmi59dIz3TJbeWbHmnkDyLWsdFFeoGSl9TRKtcTDlCLHLI7bekd5CEah /kx/iN756g7F3sEqPUXk+SQSfYeOwhp4Urhmipa6eqSO0m0R16VBW8OYFYM84n0N M54WhAz3PYXlZHYe086h/HZecwdyAVh6O23Km9Mm89LPzqL+BXC8pEQKJvBv2S0= =P4c/ -----END PGP SIGNATURE----- --Apple-Mail=_96A045FA-42E4-47B6-AD00-2F01A4CE7769-- From owner-freebsd-security@FreeBSD.ORG Wed Mar 26 06:33:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AFF132F for ; Wed, 26 Mar 2014 06:33:20 +0000 (UTC) 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 CDB11DFF for ; Wed, 26 Mar 2014 06:33:19 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s2Q6XFnb068355; Wed, 26 Mar 2014 02:33:17 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s2Q6XF5m068352; Wed, 26 Mar 2014 02:33:15 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21298.29867.672397.320969@hergotha.csail.mit.edu> Date: Wed, 26 Mar 2014 02:33:15 -0400 From: Garrett Wollman To: Kimmo Paasiala Subject: Re: NTP security hole CVE-2013-5211? (Gary Palmer) In-Reply-To: References: 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]); Wed, 26 Mar 2014 02:33: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: Wed, 26 Mar 2014 11:34:03 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 06:33:20 -0000 < said: > I believe Gary was talking about changing the control/status port > and not the actual service port (UDP 123). That should be doable > without breaking compatibility with existing NTP tools. NTP does not have a separate "control/status port"; all NTP operations that could be called "control" and "status" use the NTP protocol and the NTP port. If you configure your NTP server correctly (or start from a good default configuration), these operations will be restricted using NTP's built-in authentication and access-control mechanisms. In NTP-speak, the relevant packets are known as "mode 6" and "mode 7" messages. ntpq and ntpdc, since they run as non-root, will obviously use an ephemeral source port. Historically (not sure if it's still true), ntpd would generate a random key on startup and then fork a process to read the configuration file and handle DNS resolution; the child process would then use mode 7 messages to add associations in the main server process as each host name was resolved. -GAWollman From owner-freebsd-security@FreeBSD.ORG Wed Apr 2 11:00:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D8C91F0 for ; Wed, 2 Apr 2014 11:00:49 +0000 (UTC) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48EBADCE for ; Wed, 2 Apr 2014 11:00:49 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id i4so19036oah.10 for ; Wed, 02 Apr 2014 04:00:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=t//3L/MWlTxJuWSXmOxHKUOtWbUjsbn7Bo+EwME5zM8=; b=m5XiOHkA6dmH86rpa7s+TAK7Oj3BD79hmoWRN04FRa7B+OyKLX4userIINjbW9nY8P IYi1U4tYf/G8fOyotvtJMJswP+TwukpMd6sY2fPNBnOUPX5kSK8Y/VbeD4zdieVSQCq5 yt7T5fQVGTMewggd+LxxcwxUksRSuHSZVREziMAOcAAhlJLBJCgdNRJZBS3iMzzYJAHL mx6mOC1ye9jzdAZxn2cz0THZl+Ow4zEQuuNxzcv7ntw3ZEe4FjmANwynblG+OuFsPFLr Q+jVd3HC47iW+dubSgZ99ctN/rH06OesC2TZCts8UFNtGjlzTgC1xVbwU/HEDfUbqi+U l5Vg== X-Gm-Message-State: ALoCoQnpvwOtE9mlGjSIuCYthimnUUFPU4zRjk6jihtUMrFLunIVBbUtfOJcSmyE+PyBWcG9QKJ3 MIME-Version: 1.0 X-Received: by 10.60.226.198 with SMTP id ru6mr1595985oec.49.1396436448334; Wed, 02 Apr 2014 04:00:48 -0700 (PDT) Received: by 10.182.130.168 with HTTP; Wed, 2 Apr 2014 04:00:48 -0700 (PDT) Date: Wed, 2 Apr 2014 13:00:48 +0200 Message-ID: Subject: Adding Encryption Algorithm to Kernel From: Shady Elhamy To: freebsd-security@freebsd.org X-Mailman-Approved-At: Wed, 02 Apr 2014 11:36:32 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 11:00:49 -0000 Hi I am working on a project and i want to add an encryption algorithm to freeBSD kernel. What are the steps ? Which files should i change ? I have searched the internet and the forums and mailing lists, but couldn't find anything. I was hoping you could help me out. Thanks in advance, Shady From owner-freebsd-security@FreeBSD.ORG Thu Apr 3 14:36:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EF7CA35 for ; Thu, 3 Apr 2014 14:36:29 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 551A437F for ; Thu, 3 Apr 2014 14:36:29 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id A16ABEE3; Thu, 3 Apr 2014 16:36:17 +0200 (CEST) Date: Thu, 3 Apr 2014 16:38:29 +0200 From: Pawel Jakub Dawidek To: d@delphij.net Subject: Re: [PATCH] casperd should detach from controlling session Message-ID: <20140403143828.GA1703@garage.freebsd.pl> References: <53221E54.1030600@delphij.net> <20140317092635.GA1645@garage.freebsd.pl> <53279CB0.1020409@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <53279CB0.1020409@delphij.net> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 14:36:29 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2014 at 06:09:04PM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 03/17/14 02:26, Pawel Jakub Dawidek wrote: > > On Thu, Mar 13, 2014 at 02:08:36PM -0700, Xin Li wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > >>=20 > >> Hi, Pawel, > >>=20 > >> I have noticed that casperd's child (zygote) would still use=20 > >> controlling session from parent. This can be observed by running > >> ps - -ax on systems running casperd, where the child have a > >> spurious console associated. > >>=20 > >> The attached patch would fix it. May I commit it against -HEAD? > >=20 > > Hmm, daemon(3) does call setsid(2) already... Are you sure casperd=20 > > wasn't running with -F? >=20 > Oh, sure daemon(3) indeed does setsid(2) but casperd calls it after > zygote_init() so it has no effect to the zygote process, [...] Sorry for dropping the ball. I see the problem now, thanks. > [...] maybe something like this instead? I like the first patch better. > Index: sbin/casperd/casperd.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - --- sbin/casperd/casperd.c (revision 263272) > +++ sbin/casperd/casperd.c (working copy) > @@ -671,9 +671,6 @@ main(int argc, char *argv[]) > pjdlog_prefix_set("(casperd) "); > pjdlog_debug_set(debug); >=20 > - - if (zygote_init() < 0) > - - pjdlog_exit(1, "Unable to create zygote process"); > - - > pfh =3D pidfile_open(pidfile, 0600, &otherpid); > if (pfh =3D=3D NULL) { > if (errno =3D=3D EEXIST) { > @@ -699,6 +696,9 @@ main(int argc, char *argv[]) > pjdlog_debug(1, "PID stored in %s.", pidfile); > } >=20 > + if (zygote_init() < 0) > + pjdlog_exit(1, "Unable to create zygote process"); > + > /* > * Register core services. > */ --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --AhhlLboLdkugWU4S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlM9cmQACgkQForvXbEpPzSu4gCgttF/AdcUIS7EDhVCkngKqlnq 7+kAoL7qFJCjvyqbPGZLZU6Seum7sLOL =inxH -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-security@FreeBSD.ORG Mon Apr 7 20:50:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 453A7D05 for ; Mon, 7 Apr 2014 20:50:05 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 041CFEC for ; Mon, 7 Apr 2014 20:50:05 +0000 (UTC) Received: from [IPv6:2a01:3a0:a:15::3] (unknown [IPv6:2a01:3a0:a:15::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 2BCA41DEAD7 for ; Mon, 7 Apr 2014 20:49:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 2BCA41DEAD7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1396903794; bh=rqLKpE80Ei3074iDUa6TQyqdzEjWsJ5FQ/C+B8ChkGA=; h=Date:From:To:Subject; b=clxOSwTCbRj4bLwMOt7vhexhVYP3XuE8dHNoSsQWTHApIEzBfHHhyINUmbgHikc+C t+/KThZ2oL+FCQCandnS42ZO7LSRdiKTuD/J3DUVJA3wQDHxXm4rC8RyLerWV53KYN rWhh7EqqedWGBizRIeglpg8byciDrAKuV4MGC1jQ075tfDj+9kvq7SJ16/827GXicO xz1bweHz/o3AlaY4blh0+EBJwTn/ZrbQQoKjfsvL9WTxTscddOFt1+ReDEPE0+cuWS WS9tKidSF8hTsQ/WV8SMngzWAe6/ruSZvsvN1aPbOnV8Sh+wBJhgvwz2ngI0dy1jIT PWpoJeDIsxxHQ== Message-ID: <53430F72.1040307@gibfest.dk> Date: Mon, 07 Apr 2014 22:49:54 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: http://heartbleed.com/ X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 20:50:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, http://heartbleed.com/ describes an openssl vulnerability published today. We are going to need an advisory for the openssl in base in FreeBSD 10 and we are also going to need an updated port. The implications of this vulnerability are pretty massive, certificates will need to be replaced and so on. I don't want to repeat the page, so go read that. Best regards, /Thomas Steen Rasmussen ps. there is a bit on the openssl site too: https://www.openssl.org/news/secadv_20140407.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQw9yAAoJEHcv938JcvpYcFgP/iH3j6n7PgkCwSsN3qG9F37c A6TOGbKudIeJdO76YXiU2T+FjbMThB86KuSan2iTM4h5wTLENVLvafJmBJtIKRH8 bMZUqsUONYBSd4HpZKxbg9s8Yfy2gU0dTbs10OZ/dZw6qEr5Pd0WK6BDZ5h0ggTj 0gF4r+FHWAe/8GgxOnfVEcmyMa+VUB46ZMmpwlCC3SG0wMAs/LJHORyl283OqyT5 fwNfeDjInsPAgZORdR2+PZTgshwL0ogOINyGSKrLV1psQg2hEMgRT4GvO37IlhHS qstYleB0yLiq9ayRFyj3mg2/OMq7/26ft09fHeF19VjnysClxT7lwZEaPDkbxH7j qC1rpo1yeGuBPPdFnjbZVP5rxLR1jnQZFgTwOafjjock8ZW1ktUXOg1Upe276sv9 NrPmNzDUkuMp7tlYEuDC2MsxQNSjeCo86FdMGCH+/c+DbRqBidELFH8SYEgzK2kj TiT8tmBjdLC8PL+1SvBV4hLgapFJp2nvXsxyuJc2teRntKdgjFObQPEzb+iM/zFA mSOjuGUh28qABlqQ32B04VDBOQRUs6zWDe0cssspajqfx7T7wVaE1FGBDUUt0QkN B45cs2ql0OG5XB03GLsJv0tSdymzwohlBmoqmA08mKVWILFdkL/zzSY8Mw0oTfUa GWD5kOI/wytuF5svXFnP =gj4I -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon Apr 7 21:02:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8F9BF91 for ; Mon, 7 Apr 2014 21:02:47 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C908278 for ; Mon, 7 Apr 2014 21:02:47 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 8534313C08; Mon, 7 Apr 2014 14:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1396904566; bh=PDP9tqV96mv4PF0t6+IJFSWN1DED7YDGfOM2h3LxL8U=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=2iFl8UHc2we2us3pVp81L9/5m46F2WxDxgb9uFjVOxSpCyuYaJkcBD7dLWvOWcltD 8mgKQVuNrAls8t7V5zmCjvPMbTNG4fxUbKI+Dx8GZ4rRAtOB9RYvwlS2vB08eOUu0V Ltdisv7h3hGhiuv6BQVLWMOPP+/zyF+5seS29HSc= Message-ID: <53431275.4080906@delphij.net> Date: Mon, 07 Apr 2014 14:02:45 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Thomas Steen Rasmussen , freebsd-security@freebsd.org Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> In-Reply-To: <53430F72.1040307@gibfest.dk> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------030903090703000506070407" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 21:02:47 -0000 This is a multi-part message in MIME format. --------------030903090703000506070407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Thomas, On 04/07/14 13:49, Thomas Steen Rasmussen wrote: > Hello, > > http://heartbleed.com/ describes an openssl vulnerability > published today. We are going to need an advisory for the openssl > in base in FreeBSD 10 and we are also going to need an updated > port. > > The implications of this vulnerability are pretty massive, > certificates will need to be replaced and so on. I don't want to > repeat the page, so go read that. We are already working on this but building, reviewing, etc. would take some time. Attached is the minimal fix (extracted from upstream git repository) we are intending to use in the advisory for those who want to apply a fix now, please DO NOT use any new certificates before applying fixes. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTQxJ1AAoJEJW2GBstM+nsz6AP/2m28eIzuF/JFhyZB7rkLAZR vP9P0Tu1Vupwd6FN5X9m1O4t5ORhMfn5Y8SuxemHPg8NncaEptg43rs+TED4ucGd ulyFLJsAZtCDlTTVRAuhp3PfvNllBcoG6a+sWg0qjDqxnzWpPZShCP8ay9g/3q4W ceYJigXyi7KtKuNlc2YXlC5CA5NpKV9zsc0KhZj/PIq9qLiv+JYUriz1BRE8J+5P CusO3usNgwHFx0XppMQRXxg/iSYnqs/YM6btENgsOBlRsCJkfSPbxE1z6Vmp0h27 mOWiBLIOOR97WfYHCUHUHg+1bpJKz6VXUDHbNjjoaaLWg2D4HCkqgm45mgKZBHwh 6SZUR90WthBbbFwJ3vY+wdARBO1V3RBg64ACZfYEIimqtGKZ5VaJgmYFLZc33RQr O6Gpt7KeiwxaPYe/18zIiBULKeGBtQXettKpw4KOrkKSfnZePNxQIiqQmzLmfzXW VwgRYlAAhjmv/ROCdnQJiKQKnloo9xUEPtk1ngmw6ThJJuDGS+Mcm1pWwbvMPF5/ cWXprDXW4/Hws8GCXbZxYRrC0xQ0zDL+K589H/3pTWV5ijnI/CpM1gzvd0NH/H4+ LQNILNJ+p2Uhp3D7yoz1bQC8gV2XeXROeNGEuY3VRyNbnv3z65mjWry/4QZo+kp6 NcKVrUpKLG4odhL7BXBF =7rU5 -----END PGP SIGNATURE----- --------------030903090703000506070407 Content-Type: text/plain; charset=UTF-8; name="openssl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="openssl.patch" Index: crypto/openssl/ssl/d1_both.c =================================================================== --- crypto/openssl/ssl/d1_both.c (revision 264059) +++ crypto/openssl/ssl/d1_both.c (working copy) @@ -1458,26 +1458,36 @@ dtls1_process_heartbeat(SSL *s) unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ + if (s->msg_callback) + s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, + &s->s3->rrec.data[0], s->s3->rrec.length, + s, s->msg_callback_arg); + /* Read type and payload length first */ + if (1 + 2 + 16 > s->s3->rrec.length) + return 0; /* silently discard */ hbtype = *p++; n2s(p, payload); + if (1 + 2 + payload + 16 > s->s3->rrec.length) + return 0; /* silently discard per RFC 6520 sec. 4 */ pl = p; - if (s->msg_callback) - s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, - &s->s3->rrec.data[0], s->s3->rrec.length, - s, s->msg_callback_arg); - if (hbtype == TLS1_HB_REQUEST) { unsigned char *buffer, *bp; + unsigned int write_length = 1 /* heartbeat type */ + + 2 /* heartbeat length */ + + payload + padding; int r; + if (write_length > SSL3_RT_MAX_PLAIN_LENGTH) + return 0; + /* Allocate memory for the response, size is 1 byte * message type, plus 2 bytes payload length, plus * payload, plus padding */ - buffer = OPENSSL_malloc(1 + 2 + payload + padding); + buffer = OPENSSL_malloc(write_length); bp = buffer; /* Enter response type, length and copy payload */ @@ -1488,11 +1498,11 @@ dtls1_process_heartbeat(SSL *s) /* Random padding */ RAND_pseudo_bytes(bp, padding); - r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding); + r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, write_length); if (r >= 0 && s->msg_callback) s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT, - buffer, 3 + payload + padding, + buffer, write_length, s, s->msg_callback_arg); OPENSSL_free(buffer); Index: crypto/openssl/ssl/t1_lib.c =================================================================== --- crypto/openssl/ssl/t1_lib.c (revision 264059) +++ crypto/openssl/ssl/t1_lib.c (working copy) @@ -2486,16 +2486,20 @@ tls1_process_heartbeat(SSL *s) unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ + if (s->msg_callback) + s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, + &s->s3->rrec.data[0], s->s3->rrec.length, + s, s->msg_callback_arg); + /* Read type and payload length first */ + if (1 + 2 + 16 > s->s3->rrec.length) + return 0; /* silently discard */ hbtype = *p++; n2s(p, payload); + if (1 + 2 + payload + 16 > s->s3->rrec.length) + return 0; /* silently discard per RFC 6520 sec. 4 */ pl = p; - if (s->msg_callback) - s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, - &s->s3->rrec.data[0], s->s3->rrec.length, - s, s->msg_callback_arg); - if (hbtype == TLS1_HB_REQUEST) { unsigned char *buffer, *bp; --------------030903090703000506070407-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 02:27:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89204FAD for ; Tue, 8 Apr 2014 02:27:33 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53F9E140F for ; Tue, 8 Apr 2014 02:27:33 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s382RLQM070686; Mon, 7 Apr 2014 22:27:21 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <53435E7D.5000801@sentex.net> Date: Mon, 07 Apr 2014 22:27:09 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: d@delphij.net, freebsd-security@freebsd.org Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> In-Reply-To: <53431275.4080906@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:27:33 -0000 On 4/7/2014 5:02 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, Thomas, > > On 04/07/14 13:49, Thomas Steen Rasmussen wrote: >> Hello, >> >> http://heartbleed.com/ describes an openssl vulnerability >> published today. We are going to need an advisory for the openssl >> in base in FreeBSD 10 and we are also going to need an updated >> port. >> >> The implications of this vulnerability are pretty massive, >> certificates will need to be replaced and so on. I don't want to >> repeat the page, so go read that. > > We are already working on this but building, reviewing, etc. would > take some time. > Hi, The webpage lists FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c) I take it this is only if you installed from the ports no ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 02:29:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE8ED2D5 for ; Tue, 8 Apr 2014 02:29:21 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B492B1457 for ; Tue, 8 Apr 2014 02:29:21 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id AFC70C35A; Mon, 7 Apr 2014 19:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1396924160; bh=suRaBJoXeEZmRimw25zDOJaXEC7HsidnwgnqKfP155A=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=mK77QYDrTPIk3bqTn+JKSp+EyU/0CfZQhIxqIddN6Jd64Vp7h1CoPVYZm36hjxj7X h2uGsTu7bQrNmvLsacWikR+HPoJ/hF6KWS61/Fe0nwzL9y4VEoB7t1N19DesIPqMG4 dNPmiUGfiShFkB4FE/6TedcYb3Pcww4QeU7YNAlc= Message-ID: <53435EFE.4010103@delphij.net> Date: Mon, 07 Apr 2014 19:29:18 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Mike Tancsa , d@delphij.net, freebsd-security@freebsd.org Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <53435E7D.5000801@sentex.net> In-Reply-To: <53435E7D.5000801@sentex.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:29:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 4/7/14, 7:27 PM, Mike Tancsa wrote: > On 4/7/2014 5:02 PM, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> Hi, Thomas, >> >> On 04/07/14 13:49, Thomas Steen Rasmussen wrote: >>> Hello, >>> >>> http://heartbleed.com/ describes an openssl vulnerability >>> published today. We are going to need an advisory for the >>> openssl in base in FreeBSD 10 and we are also going to need an >>> updated port. >>> >>> The implications of this vulnerability are pretty massive, >>> certificates will need to be replaced and so on. I don't want >>> to repeat the page, so go read that. >> >> We are already working on this but building, reviewing, etc. >> would take some time. >> > > Hi, The webpage lists > > FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c) > > I take it this is only if you installed from the ports no ? That's correct. OpenSSL shipped with the base system in these two releases are not vulnerable because they don't support the extension. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTQ179AAoJEJW2GBstM+nsIa4P/RAXDidWzc01T2ghX4uNFtod C2Wd2k2B6i24LcV3PPub6dQjRI9sMxh9Q/7bIqXctThJ41U9s44P7Zvf6T7Xh/LY YM4FBAFKNiMC+WZsS78pGW6pYIULml66El7sb/G6DNOzjezWlD3MwnPo2S0nibQJ BDJ0pU3BH0A2rvyDWmF7aAveJtEuFPCCovytadStHiFZk3nKMwdN0ariLVq8JFlU s5uqf0rWRXuYIIJ2/Fv9XxUHWi0RrvyXojfdPVNIhEppmdswCzxyb+PLOBbWuZZp 9ma/ELuo8VJmmsP2A0zX2PriejfFtTR7vXP8V3VwP8RvS2YRFH44Bmyllxn2eYYI HbemABH2A5rCiMbEu32AGX7i1HikWScwKNIEJbK35BEIb9g3UGRFuxeRw9J6mTyd 44hMRO1YeyHv/nuSQ+g+d+nzB1dBYSq7YbG5UAPs0v+5fbnoPTU/28olKx1br83H BZdO+y8VUppNnRWL2wvnsbd1M8/nGABNBD9tco9ftlN0jUpFtSXkPEt20JWwZS/l HiD328EnTJKgB5nllizsCDIgaTDUYMeH6Bf8QJ54t+Cfu6sS1YYCv2/ycu5tKfqv yRU6ypV82kye/fRBkFj4JwCOXcPozm+9uPAG9bk1355w+EyKmMrba79BvwtQ+uUj PXJpfmZifPnNDBTXrg2d =FDDO -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 02:41:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91603AC8 for ; Tue, 8 Apr 2014 02:41:29 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8D615AB for ; Tue, 8 Apr 2014 02:41:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s382fTDI074592 for ; Tue, 8 Apr 2014 02:41:29 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s382fT5f074591 for freebsd-security@freebsd.org; Tue, 8 Apr 2014 02:41:29 GMT (envelope-from bdrewery) Received: (qmail 47731 invoked from network); 7 Apr 2014 21:41:27 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 7 Apr 2014 21:41:27 -0500 Message-ID: <534361D5.6070109@FreeBSD.org> Date: Mon, 07 Apr 2014 21:41:25 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> In-Reply-To: <53430F72.1040307@gibfest.dk> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UdKbaQ2b8iM932vBiR62DvitLjKEuwEur" X-Mailman-Approved-At: Tue, 08 Apr 2014 02:46:48 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 02:41:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UdKbaQ2b8iM932vBiR62DvitLjKEuwEur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/7/2014 3:49 PM, Thomas Steen Rasmussen wrote: > Hello, >=20 > http://heartbleed.com/ describes an openssl vulnerability published > today. We are going to need an advisory for the openssl in base in > FreeBSD 10 and we are also going to need an updated port. >=20 > The implications of this vulnerability are pretty massive, > certificates will need to be replaced and so on. I don't want to > repeat the page, so go read that. >=20 > Best regards, >=20 >=20 > /Thomas Steen Rasmussen >=20 > ps. there is a bit on the openssl site too: > https://www.openssl.org/news/secadv_20140407.txt The port has been updated. 1.0.1_10 has the fix. --=20 Regards, Bryan Drewery --UdKbaQ2b8iM932vBiR62DvitLjKEuwEur Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTQ2HWAAoJEDXXcbtuRpfPwlAIAKDtXjdC8TbcVGLJAC9iajLd Cc+7cc/y9Rxs0ALQlzjPrt4NwTCdoCffJkRSDpvvUL/ciIU8hEjctEDAREEqLyg7 E2dM5YlXeqNzsu7X5x5dnh1+QjKZh6/9LvRPYYtgM8mFsIA86hATxuqb1XWYB8/V k8cbPUEyVJk1LXKgh0VhTV6eqSygrhMG8cGMQ760vGG5CdXDkT+pmHFkOkH+0xMz buA2XQI3lvr3Q0CzTDMUUayNDfBZoKJj20L46PoHYsamlzOVG+g3PDuQGAMfu83A l2bzfHaehWgjyxlQev8XiXJZHbgIB9+68hO9og97XkI1750kL2HPCKJS4P2b2BM= =8iwj -----END PGP SIGNATURE----- --UdKbaQ2b8iM932vBiR62DvitLjKEuwEur-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 13:45:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CBBC7C7 for ; Tue, 8 Apr 2014 13:45:45 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05CFD1319 for ; Tue, 8 Apr 2014 13:45:44 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s38DjZJV024553; Tue, 8 Apr 2014 09:45:35 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5343FD71.6030404@sentex.net> Date: Tue, 08 Apr 2014 09:45:21 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: d@delphij.net, Thomas Steen Rasmussen , freebsd-security@freebsd.org Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> In-Reply-To: <53431275.4080906@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 13:45:45 -0000 On 4/7/2014 5:02 PM, Xin Li wrote: >> >> The implications of this vulnerability are pretty massive, >> certificates will need to be replaced and so on. I don't want to >> repeat the page, so go read that. > > We are already working on this but building, reviewing, etc. would > take some time. > > Attached is the minimal fix (extracted from upstream git repository) > we are intending to use in the advisory for those who want to apply a > fix now, please DO NOT use any new certificates before applying fixes. Hi, I am trying to understand the implications of this bug in the context of a vulnerable client, connecting to a server that does not have this extension. e.g. a client app linked against 1.xx thats vulnerable talking to a server that is running something from RELENG_8 in the base (0.9.8.x). Is the server still at risk ? Will the client still bleed information ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 14:11:46 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34649432 for ; Tue, 8 Apr 2014 14:11:46 +0000 (UTC) Received: from elektropost.org (elektropost.org [217.115.13.199]) by mx1.freebsd.org (Postfix) with ESMTP id 76A361617 for ; Tue, 8 Apr 2014 14:11:45 +0000 (UTC) Received: (qmail 12735 invoked from network); 8 Apr 2014 14:05:03 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with AES128-SHA encrypted SMTP; 8 Apr 2014 14:05:03 -0000 Message-ID: <5344020E.9080001@erdgeist.org> Date: Tue, 08 Apr 2014 16:05:02 +0200 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <5343FD71.6030404@sentex.net> In-Reply-To: <5343FD71.6030404@sentex.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:11:46 -0000 On 08.04.14 15:45, Mike Tancsa wrote: > I am trying to understand the implications of this bug in the > context of a vulnerable client, connecting to a server that does not > have this extension. e.g. a client app linked against 1.xx thats > vulnerable talking to a server that is running something from RELENG_8 > in the base (0.9.8.x). Is the server still at risk ? Will the client > still bleed information ? If the adversary is in control of the network and can MITM the connection, then yes. The client leaks random chunks of up to 64k memory, and that is for each heartbeat request the server sends. erdgeist From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 14:18:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C545A6F8 for ; Tue, 8 Apr 2014 14:18:08 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82FB21670 for ; Tue, 8 Apr 2014 14:18:08 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1A0D421053 for ; Tue, 8 Apr 2014 10:09:32 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 08 Apr 2014 10:09:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inconsistent.nl; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; s=mesmtp; bh=KHFci7VxhqC95CGnRmQi6k1G 02o=; b=b8K2J1uRWIgUcLrWr/YsY+PbE3w4u3L/1iT7EoGINrTR91kAmQqyz0HZ kROJoxiHmVjjKvGOI6Y3vkR9gl7IvUE5LUBZFYyqWyqet4UfIJzvDCjoA/2hv/Hr dx8+LoCUztx5UK9vpB+06Oc6l6DDIHPWjFy6zuTff3XhLhKRRwg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=KHF ci7VxhqC95CGnRmQi6k1G02o=; b=d4U41wYL5XVky5YseO5k06YAbQO6KM5ibVs gYu+28oBJie9ghUlGBLoFvXm9vvSPUY0BIAx4wu45HvGKzecRxQqKmvhDatwQdzO DN5dkwJJCsxcCilZ79tu3zQNLqtaxM8b0k1EREBvMMuRN2eu17jIiF9FBqFB1dth kCqe5G08= X-Sasl-enc: TbIz0j+rzpJEKLDPHZIzcEukUy5r+Hmlx3BsfMpl8A2e 1396966171 Received: from wcw-staff-145-18-163-88.wireless.uva.nl (unknown [145.18.163.88]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C905C007B4; Tue, 8 Apr 2014 10:09:31 -0400 (EDT) Subject: Re: http://heartbleed.com/ Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_6F15A066-82F5-4B0E-AD44-0F34B72C5E96"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Merijn Verstraaten In-Reply-To: <5343FD71.6030404@sentex.net> Date: Tue, 8 Apr 2014 16:09:29 +0200 Message-Id: <8F4C4FB3-2934-42BC-AC75-26FE45FEDB36@inconsistent.nl> References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <5343FD71.6030404@sentex.net> To: Mike Tancsa X-Mailer: Apple Mail (2.1283) Cc: Thomas Steen Rasmussen , freebsd-security@freebsd.org, d@delphij.net X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:18:08 -0000 --Apple-Mail=_6F15A066-82F5-4B0E-AD44-0F34B72C5E96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 8, 2014, at 15:45 , Mike Tancsa wrote: > Hi, > I am trying to understand the implications of this bug in the = context of a vulnerable client, connecting to a server that does not = have this extension. e.g. a client app linked against 1.xx thats = vulnerable talking to a server that is running something from RELENG_8 = in the base (0.9.8.x). Is the server still at risk ? Will the client = still bleed information ? >=20 > ---Mike Information can be bled from a vulnerable OpenSSL talking to a malicious = peer (i.e. malicious peer forces heartbeat and bleeds info from the = vulnerable app). So no, vulnerable clients can't bleed info from safe = servers. More importantly, since the leak only occurs when talking to = malicious peers, your clients should be safe if they only communicate = with trusted servers (since, presumably, your own servers don't = maliciously enable heartbeat and leak info from clients). Of course it's still recommended to update your clients and renew keys, = but in practice the risk should be minor for clients that only talk to = secure servers. Cheers, Merijn --Apple-Mail=_6F15A066-82F5-4B0E-AD44-0F34B72C5E96 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTRAMZAAoJECV7trmhY/MQnx0P/iuaiIztA9pOnCcLOArii0wK A2doesMjvDAXQZrcs85K98YcG6YVpamNfmsaqwAXO/625S1eF97hjQ83C3Bq/qib +UjG6MpNbb8QuJs52FgcnWiMcGsM9n2zUCEJO0Pi3yyZ+1q2NIKGt0swaz4L+MBI z40o7ce4h9GAuQWcy707M3iaz5LdPti7CXPz39PAOHLYW2oSLrznCL+oQCiVQeub nCq6ekDVr9zfz0pQ9ml9yX//hICIoHeQDj4TfbKBMNjrK+Po4k5LCouiswFFjuse kqp1PSaoBY76JB7EzmdakYTVQ6UkcmCFldlZ3V1CE+0/IOU16OfMMYe2+DC/i5EJ oCLG6nYLGZNYDcOT1Xrv6jm6mCMw/UuYXCZWghtwKlIwihWDEUqVF9RIZvxXL+j7 FVKPAHNOPjUOiVBfTGKOpWjWuqH3zqCCF34lbT2xKNZFEjh7z6MEXl4eHxoBKUd2 zA41TU0y9hZWdiaMTqhpqcUFc8U1s+PDYooT3v/83VISSAenOpOPiMT5KPZqASAJ C9TpaQbCrgoe4IxSs3SYeYD2kR7Th0ADBqfWwv/y7bYPLKC515POaRXgEWZYm2jJ aoO7jYiNVju9b0FiEQO6aOn3JsDNMiuZ1mtozZSE++0+/3tP9fzsbHdpqmncdIqd FVyzIwbXO3W8jBka9/oN =DIDh -----END PGP SIGNATURE----- --Apple-Mail=_6F15A066-82F5-4B0E-AD44-0F34B72C5E96-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 14:28:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD1F8CF4 for ; Tue, 8 Apr 2014 14:28:49 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 86A5B1794 for ; Tue, 8 Apr 2014 14:28:49 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s38ESeXC033064; Tue, 8 Apr 2014 10:28:41 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5344078B.7030307@sentex.net> Date: Tue, 08 Apr 2014 10:28:27 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Merijn Verstraaten Subject: Re: http://heartbleed.com/ References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <5343FD71.6030404@sentex.net> <8F4C4FB3-2934-42BC-AC75-26FE45FEDB36@inconsistent.nl> In-Reply-To: <8F4C4FB3-2934-42BC-AC75-26FE45FEDB36@inconsistent.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 Cc: Thomas Steen Rasmussen , freebsd-security@freebsd.org, d@delphij.net X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:28:49 -0000 On 4/8/2014 10:09 AM, Merijn Verstraaten wrote: > > On Apr 8, 2014, at 15:45 , Mike Tancsa wrote: >> Hi, >> I am trying to understand the implications of this bug in the context of a vulnerable client, connecting to a server that does not have this extension. e.g. a client app linked against 1.xx thats vulnerable talking to a server that is running something from RELENG_8 in the base (0.9.8.x). Is the server still at risk ? Will the client still bleed information ? >> >> ---Mike > > Information can be bled from a vulnerable OpenSSL talking to a malicious peer (i.e. malicious peer forces heartbeat and bleeds info from the vulnerable app). So no, vulnerable clients can't bleed info from safe servers. More importantly, since the leak only occurs when talking to malicious peers, your clients should be safe if they only communicate with trusted servers (since, presumably, your own servers don't maliciously enable heartbeat and leak info from clients). > > Of course it's still recommended to update your clients and renew keys, but in practice the risk should be minor for clients that only talk to secure servers. Thanks! Although we are certainly planing to update the vulnerable clients, this is not quite as dire and urgent as first described in the popular press-- at least as it applies to my client base. We also use IP addresses for the target servers in the client configs, so DNS poisoning does not apply to my scenario to trick the clients through that vector. Still, there are other ways, but this reduces the risk somewhat for my scenario at least. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 17:42:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21460F96 for ; Tue, 8 Apr 2014 17:42:21 +0000 (UTC) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id D14A01C27 for ; Tue, 8 Apr 2014 17:42:20 +0000 (UTC) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id DEDE179E5D for ; Tue, 8 Apr 2014 13:42:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:mime-version:content-type; s=sasl; bh=CvyjL4 ECO4KnQeW2/xArRCWm6bw=; b=eccpqjxbQo/6upCgoBgEREnmxnvIaYMz2tVAIh IVrx8PvthlYiXb/JZTN00PKZxyRbZYN9Bp86f73kd0WXLZsV8bHjT6DvO2+W5IsI U44YhB+7XzfXh/tRJDXTJyTmBadKueBLEQLXoMUaNUVhhOlseinz2yGMBSkSMrYf J1bqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:mime-version:content-type; q=dns; s=sasl; b= XJnHmDaNTNZXTnzOApmoyKwGxKHy5kKjm2Eiqi9R7tkrXtkQPmA8mrvWDveeqHI6 6CBo4qx3Z/g+64p30S0WVgP2L6Qwp0RJy3W6vf2Zywg7Mr2/7oP50hEHgsgal98a 0eo6h0ig7R1258WPOkcQEZh5dcRaeSw9gNODbMSF1Ps= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id CF60B79E5A for ; Tue, 8 Apr 2014 13:42:12 -0400 (EDT) Received: from localhost (unknown [76.99.50.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 8ACD879E59 for ; Tue, 8 Apr 2014 13:42:11 -0400 (EDT) Date: Tue, 8 Apr 2014 13:42:10 -0400 From: Chris Nehren To: freebsd-security@freebsd.org Subject: FreeBSD's heartbleed response Message-ID: <20140408174210.GA5433@behemoth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 1D424684-BF45-11E3-9916-8D19802839F8-49531120!b-pb-sasl-quonix.pobox.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:42:21 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First, please let me say that I understand that FreeBSD is a volunteer project. I know that most everyone is using donated time and donated hardware. You'll find some old email addresses of mine in the ports collection, in fact, and it's in the spirit of volunteering that I write today. The Heartbleed vulnerability is probably the highest priority, farthest-reaching vulnerability I've ever seen. Yet nearly a day later, FreeBSD remains unpatched. There are many worried sysadmins and other users in #freebsd and elsewhere wondering what's going on and when their systems will be patched. So far all we have is an unofficial gist on github and some discussion here (which most users don't see) with no further information. More transparency is needed. Given the above, I come with a request to help: how can the userbase at large help with getting these sorts of fixes out more quickly? I and others have hardware and time we'd be glad to donate if it would help resolve these sorts of critical issues more quickly. I'm sorry if I sound impatient. I want to help, but don't know how, so I'm asking here.=20 --=20 Chris Nehren --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJdBAABAgBHBQJTRDTyQBSAAAAAABUAInBrYS1hZGRyZXNzQGdudXBnLm9yZ2Nu ZWhyZW4rZnJlZWJzZC1zZWN1cml0eUBwb2JveC5jb20ACgkQHo59aFf/oVPwBQ/+ KNZ9XVIq2Yon3T/jHMM+nKJAsaztrkv1uWTj5RNl2a+qUJRkfPoS8bFvF12WTO9B zqlr1faxXPsm6uZ5qFyNYZCzQJJq3QpQpVhK3lgqLLUukJRaVmwPleI0OstkrYmX ZNfdvghFtDM5eYmXaJpbrNFoEF8Akh9jtKXti+LIHdL7A2FIOKJIoEcA5Yo5F4p4 iTW/2qAsj0xWHtTmAwcwZCp5d+b2nsPODUlXPAFvtsb5A6oMx/zcN3gHDgIAfvD6 4zba1YDPKfptzgJQOPxHBC6SI9YVb8H3vS25SAGZF/i0REBfuUXMnkaMdTPWYhoK RazFWBSkBW+/YnjP9qUxZ//uJxiZcUtA89c3x9SxcgjKiwD7uwLdVFxgUfcEma4b LLvtGGep8lPZIpEoM7tFe5QeW0dasgAuRIttYdRbkIq/qs837u9FWPkovEGOAejY fyn10ggqkSZxQnpjKLpuWvMx19JjGqLxlKJQPOeCiKBAOhpq5xX1NTKGM+ayUdwu 7e1zjvKBH1nGETGA+WgbHN3geBBDEMgFzVXUpFqHsZwOT/4aieMK2YhsNycdNTBn Olka6hSnnSI+QpFG2sqfPyjivKiFus4cmroEDIgTVdYKfcAyJXwz8k19eWiVYHYs M4GK3UvNYYqR5CWZ3u93qW2bzwYuPU23wiIbWfVSa4A= =etNK -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 17:46:13 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C294E169 for ; Tue, 8 Apr 2014 17:46:13 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EDED1C60 for ; Tue, 8 Apr 2014 17:46:13 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id q108so1134193qgd.10 for ; Tue, 08 Apr 2014 10:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucsc.edu; s=ucsc-google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2pOyeuwtNAm+QyPHbaYbDfEXp+DUQsUUQKwXyVDM2gQ=; b=Y2MToNmxnUGq8l3NThwU0LyNTguYGKbU79YgG7XnQgQnEYisczBSi2Za450LozLpMS yfCzwn7xPbw+zwLc7S4UoAeBmW0Pye+JIfeAqIr3Ey4c8ah9BvtCfd04PMKLNh7IPu48 T5HJCv4kGh+32NCsot1m9Owv3+peO1xkMfJp0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2pOyeuwtNAm+QyPHbaYbDfEXp+DUQsUUQKwXyVDM2gQ=; b=T0ao+oTIlD5/nMuzrqZKSt0CtJz7f+Wjos9/HSi8hoHc1tiwsjh33mcy98lqOeC6do u/YVaIQh9Qhq8lbodknwocm5ulJTjp8NOvG2IoNLZPzezuKpkQocjhsnngYpy/Z7aeJg 6M0X5HKbDSv/aUU+zO2pVoxVZtNMO0Di5WTR68SM/XfzuSZ+zaqedkt8THn76pCaHJKY YNPdPVD1ClETdRwK/QsdgO73LIRFOHoKmHPi3Ok1eeUx5WPDRRrT0hd56FmsA5yLaaAL efNH4gsx6b4hyKe46GHTOWlYves7b9QsBd6xbrYU0sJleIuFbVayCxvltHjaEAU7Slzu 18ww== X-Gm-Message-State: ALoCoQnLaHZlfvbFsYGFdoj5A2PINiGxp/qvnr3iGLiq1hi5FIbC2PvkbUh5KOrziTWLRzGHQ+GH MIME-Version: 1.0 X-Received: by 10.224.88.131 with SMTP id a3mr6426410qam.54.1396979172627; Tue, 08 Apr 2014 10:46:12 -0700 (PDT) Received: by 10.96.5.132 with HTTP; Tue, 8 Apr 2014 10:46:12 -0700 (PDT) In-Reply-To: <20140408174210.GA5433@behemoth> References: <20140408174210.GA5433@behemoth> Date: Tue, 8 Apr 2014 10:46:12 -0700 Message-ID: Subject: Re: FreeBSD's heartbleed response From: Mark Boolootian To: Chris Nehren Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:46:13 -0000 While it may not be quite what you're looking for, ports contains OpenSSL 1.0.1g. From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:00:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BABFF831 for ; Tue, 8 Apr 2014 18:00:04 +0000 (UTC) Received: from as1.azsupport.com (azsupport.com [74.52.186.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "azsupport.com", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F7F41D8A for ; Tue, 8 Apr 2014 18:00:04 +0000 (UTC) Date: Tue, 8 Apr 2014 19:50:49 +0200 From: Andrei To: freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response Message-ID: <20140408195049.04129f2a@azsupport.com> In-Reply-To: References: <20140408174210.GA5433@behemoth> Organization: azsupport.com X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:00:04 -0000 On Tue, 8 Apr 2014 10:46:12 -0700 Mark Boolootian wrote: > While it may not be quite what you're looking for, ports contains > OpenSSL 1.0.1g. And also FreeBSD 8.x/9.x not affected because have 0.9.x OpenSSL in base. From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:00:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 786C38FC for ; Tue, 8 Apr 2014 18:00:09 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 41A2A1D8B for ; Tue, 8 Apr 2014 18:00:09 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s38I059F068432 for ; Tue, 8 Apr 2014 14:00:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <53443917.7040609@sentex.net> Date: Tue, 08 Apr 2014 13:59:51 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response References: <20140408174210.GA5433@behemoth> In-Reply-To: <20140408174210.GA5433@behemoth> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:00:09 -0000 On 4/8/2014 1:42 PM, Chris Nehren wrote: > later, FreeBSD remains unpatched. There are many worried > sysadmins and other users in #freebsd and elsewhere wondering > what's going on and when their systems will be patched. So far > all we have is an unofficial gist on github and some discussion > here (which most users don't see) with no further information. > More transparency is needed. * The port was very quickly updated. * Xin posted a working patch to the list for those who really wanted to apply it. * I think it reasonable that code touching such a CRITICAL aspect of the OS be *well* reviewed before getting committed. IIRC there was a quick fix to an openssl bug in the past that then had to be fixed again. * What is stopping people who care about security from joining, or following this mailing list ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:05:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E45BC95 for ; Tue, 8 Apr 2014 18:05:01 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463D51FC9 for ; Tue, 8 Apr 2014 18:05:01 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id hz1so1371920pad.35 for ; Tue, 08 Apr 2014 11:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EMvyLuhuIr4SgnMRzy8xz8O/I0OdpFgEJ/RnI04Ohkg=; b=ypJ+0kk+QN2npKNqkQHm23Bv5VuIJ7vbT8Yq0iN9MC7nb/6BcyybNxisDI1WywhQHt 9CrUE72fc5djI3zNd7sS73Iki50DskyImbnov1ihIQxlFn/JGKdFHBOt9bLY6jcGcCMx i1T5u+JaJoCZreUbMOcpnUW8vkA3xyuS0IUbzeDbj/VrZ5LmENwNchLaDq7yX0A8H3Tv zpkQH+mLjvUJaGCvu/+NmCgVru12LPHoha0JRIAf6zgG/repqdhKN1SLLXmYVL1zwMU+ QXX6/ZYZdOZTN3OVynbW7AvNhYrnzLzDB+0C2pBnqr/3KKu0eP2Nb6x9fuRqjmSsoR5w 1qsA== MIME-Version: 1.0 X-Received: by 10.68.220.230 with SMTP id pz6mr900689pbc.24.1396980300765; Tue, 08 Apr 2014 11:05:00 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.70.70.231 with HTTP; Tue, 8 Apr 2014 11:05:00 -0700 (PDT) In-Reply-To: <53443917.7040609@sentex.net> References: <20140408174210.GA5433@behemoth> <53443917.7040609@sentex.net> Date: Tue, 8 Apr 2014 14:05:00 -0400 X-Google-Sender-Auth: QTwZkTzMk_M7EGhG9Ko5FSuAsGk Message-ID: Subject: Re: FreeBSD's heartbleed response From: Nathan Dorfman To: Mike Tancsa Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:05:01 -0000 Someone please correct me if I'm wrong, but I think simply adding -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is sufficient to remove the vulnerability from the base system. -nd. From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:16:59 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D85E6F for ; Tue, 8 Apr 2014 18:16:59 +0000 (UTC) Received: from elektropost.org (elektropost.org [217.115.13.199]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0841102 for ; Tue, 8 Apr 2014 18:16:58 +0000 (UTC) Received: (qmail 20396 invoked from network); 8 Apr 2014 18:16:55 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with AES128-SHA encrypted SMTP; 8 Apr 2014 18:16:55 -0000 Message-ID: <53443CBF.60103@erdgeist.org> Date: Tue, 08 Apr 2014 20:15:27 +0200 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 CC: freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response References: <20140408174210.GA5433@behemoth> <53443917.7040609@sentex.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:16:59 -0000 On 08.04.14 20:05, Nathan Dorfman wrote: > Someone please correct me if I'm wrong, but I think simply adding > -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is > sufficient to remove the vulnerability from the base system. You forgot to mention installing, but yes. erdgeist From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:17:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B65C7189 for ; Tue, 8 Apr 2014 18:17:56 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 701541123 for ; Tue, 8 Apr 2014 18:17:56 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 817B32140B; Tue, 8 Apr 2014 14:17:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 08 Apr 2014 14:17:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inconsistent.nl; h=to:from:cc:subject:date:mime-version:content-type:message-id; s=mesmtp; bh=vGULIevhpiw2Qrghcf69HH/7+pQ=; b=DXouxeBSCxxgCGxMDm VR73xt4gXHkiWU5YsbOCdd+FD20bj/OWgufIUWHTfz84sxCMK2nKWAX+Cs9NMsAU vg6UocR1bfq64zLcmyihbjZiaeNxPmJCoaOVehxfqtA0MAdS8pP1PccDbjKVMB0m Lfaffvqsg1htl31OTrLIqUcLQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=to:from:cc:subject:date:mime-version :content-type:message-id; s=smtpout; bh=vGULIevhpiw2Qrghcf69HH/7 +pQ=; b=m/tZvALAj3fJ+CtVMlKl5HIVNQrybwcV8ArEeOtHwYzN8dYSWBsVXepf od9YGILtZp6h4neIVfuLU9E/vDdWfOFsdQ8VTbn66uU+ZqVUOvuKGCJEJIdd/21P l415yU77rNKmtSE/NsUXZYcIpywxdWTDYcojRZemWyKI9Mj549o= X-Sasl-enc: WFZGuaTeSuqkyZ9WVmZGaKvr4vWi0QJhFwE43w3RC80b 1396981066 Received: from [10.9.87.29] (unknown [82.199.70.179]) by mail.messagingengine.com (Postfix) with ESMTPA id F06A2C007AD; Tue, 8 Apr 2014 14:17:45 -0400 (EDT) To: "=?utf-8?B?TmF0aGFuIERvcmZtYW4=?=" , "=?utf-8?B?TWlrZSBUYW5jc2E=?=" From: "=?utf-8?B?TWVyaWpuIFZlcnN0cmFhdGVu?=" Subject: =?utf-8?B?UmU6IEZyZWVCU0QncyBoZWFydGJsZWVkIHJlc3BvbnNl?= Date: Tue, 08 Apr 2014 20:17:45 +0200 MIME-Version: 1.0 Message-Id: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:17:56 -0000 VW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBlYXJsaWVyIGVtYWlscywgdGhlIGhlYXJ0YmVhdCBleHRl bnNpb24gb3MgQUxSRUFEWSBkaXNhYmxlZCBpbiBiYXNlLCB0aGVyZWZvcmUgRnJlZUJTRCBiYXNl IGlzbid0IHZ1bG5lcmFibGUgYW5kIHRoZSBvbmx5IHByb2JsZW0gaXMgcGVvcGxlIHdobyBpbnN0 YWxsZWQgYSBuZXdlciBPcGVuU1NMIGZyb20gcG9ydHMuCgpDaGVlcnMsCk1lcmlqbgoKLS0tLS0g UmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiTmF0aGFuIERvcmZtYW4iIDxuYUBydGZtLm5ldD4K VG86ICJNaWtlIFRhbmNzYSIgPG1pa2VAc2VudGV4Lm5ldD4KQ2M6IDxmcmVlYnNkLXNlY3VyaXR5 QGZyZWVic2Qub3JnPgpTdWJqZWN0OiBGcmVlQlNEJ3MgaGVhcnRibGVlZCByZXNwb25zZQpEYXRl OiBUdWUsIEFwciA4LCAyMDE0IDIwOjA1CgpTb21lb25lIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEkn bSB3cm9uZywgYnV0IEkgdGhpbmsgc2ltcGx5IGFkZGluZwotRE9QRU5TU0xfTk9fSEVBUlRCRUFU UyB0byBjcnlwdG8vb3BlbnNzbC9NYWtlZmlsZSAoYW5kIHJlY29tcGlsaW5nISkgaXMKc3VmZmlj aWVudCB0byByZW1vdmUgdGhlIHZ1bG5lcmFiaWxpdHkgZnJvbSB0aGUgYmFzZSBzeXN0ZW0uCgot bmQuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmZyZWVi c2Qtc2VjdXJpdHlAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5mcmVlYnNk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2Qtc2VjdXJpdHkKVG8gdW5zdWJzY3JpYmUsIHNl bmQgYW55IG1haWwgdG8gImZyZWVic2Qtc2VjdXJpdHktdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmci From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:22:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13C19594 for ; Tue, 8 Apr 2014 18:22:07 +0000 (UTC) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:201:220c::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id CEDB911FC for ; Tue, 8 Apr 2014 18:22:06 +0000 (UTC) Received: from sona.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 53C335C4E for ; Tue, 8 Apr 2014 20:21:59 +0200 (CEST) Message-ID: <53443E46.1020902@borderworlds.dk> Date: Tue, 08 Apr 2014 20:21:58 +0200 From: Christian Laursen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response References: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> In-Reply-To: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:22:07 -0000 On 04/08/14 20:17, Merijn Verstraaten wrote: > Unless I misunderstood earlier emails, the heartbeat extension os ALREADY disabled in base, therefore FreeBSD base isn't vulnerable and the only problem is people who installed a newer OpenSSL from ports. It would be nice, if so@ would send out such a statement to the security-announce list ahead of the actual advisory, so that fewer people will be panicing. -- Christian Laursen From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:39:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24090E4E for ; Tue, 8 Apr 2014 18:39:06 +0000 (UTC) Received: from smtp.peterschmitt.fr (smtp.peterschmitt.fr [IPv6:2a01:4f8:a0:72c8:4224::1]) by mx1.freebsd.org (Postfix) with ESMTP id DA4EE1344 for ; Tue, 8 Apr 2014 18:39:05 +0000 (UTC) Received: from [192.168.1.121] (89-159-92-168.rev.dartybox.com [89.159.92.168]) by smtp.peterschmitt.fr (Postfix) with ESMTPSA id 68D0E60157; Tue, 8 Apr 2014 20:38:56 +0200 (CEST) Message-ID: <5344427B.3060205@peterschmitt.fr> Date: Tue, 08 Apr 2014 20:39:55 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Mark Boolootian , Chris Nehren Subject: Re: FreeBSD's heartbleed response References: <20140408174210.GA5433@behemoth> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="11MNtLLRpTkaGt8fXSOl2JRM7aJDRivFe" Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:39:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --11MNtLLRpTkaGt8fXSOl2JRM7aJDRivFe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/04/2014 19:46, Mark Boolootian wrote: > While it may not be quite what you're looking for, ports contains > OpenSSL 1.0.1g. Why not moving critical parts of the basesystem to ports, that will be installed at system installation of course? It was one of the reasons to get BIND out from sysbase, but since their is a fresh new and powerful package manager, I think FreeBSD should rely on them instead on persisting to keep all sort of stuffs into the base. An "openssl-current" and an "openssl-stable", both providing "openssl" (an of course conflicting between each other) can be a good solution, nop= e? FreeBSD should be split in packages over the time, I think. And splitting it is not a synonym of a "not coherent system" ;) If you tell me FreeBSD should be and will always be delivered as tarballs/svn/freebsd-update, well, at least freebsd-update is a bit slow but still works. --11MNtLLRpTkaGt8fXSOl2JRM7aJDRivFe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTREJ+AAoJEFr01BkajbiBvmQP/i1qSwvVVhs582+WOlxkunhz FfNhhFanCllls9AZM8GfqyYhPd3r3qo7xm8Z8nWYre2DO+gzPcBH0WG0hZCt58of KAn8NXGecwIwSTX5O8JTNEARiQvAJ01rypkzFBOLO5UgqPCWf7eaP6yqdX9afoHc ZhZm/vdoJp36X/FpPRXiVbCPPdzWG7WjvqABgv/Fb2EAtIo7nWyeg+tYJbZUf9+N zEmlK/STg828bKrTM0658FCQzZvf3r1dXMjc3jtjbZVypuDXggjL0PE4qG5MisqT cEYSUDaYEKMVCY5B8l7jMyEgzssDsqwB66ZYrWf95hMvgNvijd1z6efOHpO+xrXL 1ddPdyHnU3AjeBB0q9oENIbyEdowkjYAQZ6FSTePzUMigiEdMBxVwEQnlPIgLW+t 8f1mScr2PO282jPXsBNjWZAjxPlq1+JZ2Vi6jbNTsolUgBAzYcH7JqgZHR3JjqIX EUnn43CZnbkxmONy8P+hmNW5vHTIqYpaayVa+87MCGCDCK1YBuvD5nlqRrFuqqfW 62/hzZ3YmGwV3sBMmOUdfSAyiOz2JBAl8lUS37Am65JUJWqVcr3izGnfkxGt46hX m6Hh5kPGQqDqjcHhsO8MoQ0NqSjEdBQWI51/5JAdVWKk0+nPL0t9Aq5bttPQPbsq fDQqfj5PeULuVqyb5f/v =d8bX -----END PGP SIGNATURE----- --11MNtLLRpTkaGt8fXSOl2JRM7aJDRivFe-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 18:45:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 304222C0 for ; Tue, 8 Apr 2014 18:45:41 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED3601468 for ; Tue, 8 Apr 2014 18:45:40 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so1488855obb.18 for ; Tue, 08 Apr 2014 11:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Vx7CbTQB4JyeOS/uSDzLwoz/ILSMffRuG9ynvLAzu6A=; b=Nnwz6HM5Te4gw2uBsQXgGaoKRVL30e+7Tj8g3KwPeI8BWmVzFzWD1gwUI2o+7JoTVA PWao1AYwueKvtMZTrT9thLPcXlFfSoMFH8VmsrgrLKwV1+4mvt6gWUOnSoUehi+BCwPq ZMzIyjklWmb42sckn/MHGt9kNk8GtbEM6h+rO7Xf3xScJr/ZTG52p0L0485W0OcORtWh WSblZt8VIqdT7lQatnppV61iVEJBzgy5CVL3pUaF16aYyGFMkie/51VJErIyvYfpZX1T QGIYB7yMa7icgldXedlacOuBgL1pZpIFIEOLIm1PMzu6PW95xBJr8D88H98j3f2HDIdC brJg== MIME-Version: 1.0 X-Received: by 10.60.48.106 with SMTP id k10mr4779994oen.20.1396982740230; Tue, 08 Apr 2014 11:45:40 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.60.158.106 with HTTP; Tue, 8 Apr 2014 11:45:40 -0700 (PDT) In-Reply-To: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> References: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> Date: Tue, 8 Apr 2014 14:45:40 -0400 X-Google-Sender-Auth: sSXiI24pUGyv9sxRWVRCnqX-P4E Message-ID: Subject: Re: FreeBSD's heartbleed response From: Nathan Dorfman To: Merijn Verstraaten Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:45:41 -0000 Are you sure about that? The only email I saw stated that FreeBSD 8.x and 9.x weren't vulnerable because they were using an older OpenSSL, from before the vulnerability was introduced. FreeBSD 10-STABLE, on the other hand, seems to use the vulnerable OpenSSL 1.0.1e, and I didn't immediately see OPENSSL_NO_HEARTBEATS in the Makefile there. So I may well be missing something, but it looks vulnerable at first glance. -nd. On Tue, Apr 8, 2014 at 2:17 PM, Merijn Verstraaten wrote: > Unless I misunderstood earlier emails, the heartbeat extension os ALREADY > disabled in base, therefore FreeBSD base isn't vulnerable and the only > problem is people who installed a newer OpenSSL from ports. > > Cheers, > Merijn > > > ----- Reply message ----- > From: "Nathan Dorfman" > To: "Mike Tancsa" > Cc: > Subject: FreeBSD's heartbleed response > Date: Tue, Apr 8, 2014 20:05 > > Someone please correct me if I'm wrong, but I think simply adding > -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is > sufficient to remove the vulnerability from the base system. > > -nd. > _______________________________________________ > 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 Tue Apr 8 18:53:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 720086AA for ; Tue, 8 Apr 2014 18:53:17 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 316CE159B for ; Tue, 8 Apr 2014 18:53:17 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id dc16so83072qab.11 for ; Tue, 08 Apr 2014 11:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oOQNoWE7tAHHu4wRIJa7UDEPY78HAZ5ull+vanag0Ms=; b=Vzu1nXYoq93nxeFPjP6jkNiS0SuTjLHGDv25cWaadgaDrD7BqvY9LnXAmbSUUW1BJb E8i00m4zRoPt4ABwQ5Y1L562wFbKer+BG8iYKgpUqGvI/YOl31bFBotbFoFhzN9ypE+S +96oaYwvI1EZVnM7hIWdm3Y8sIiIu17xp5GEtzI6GxQatz0nMsrEWXtdEt+O0rH07kjW 95SRNi685Ixh3kgd/M+NCmjMGwVuM6Rf3HhLkqRW/CjBGl1Y3LsaOP7Zr6vagbhApakW ymSm99W4oHRTVvGWcDQBQKUzNNvqEyoJjkvRDMLbW9EVvTq3B1C7gWtWHHA/rQtX1z51 gVZA== MIME-Version: 1.0 X-Received: by 10.140.101.244 with SMTP id u107mr5168376qge.107.1396983196224; Tue, 08 Apr 2014 11:53:16 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.88.105 with HTTP; Tue, 8 Apr 2014 11:53:16 -0700 (PDT) In-Reply-To: References: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> Date: Tue, 8 Apr 2014 14:53:16 -0400 X-Google-Sender-Auth: iGMFZ_snok706eRc2Wk_7HAsEvA Message-ID: Subject: Re: FreeBSD's heartbleed response From: Ed Maste To: Nathan Dorfman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 18:53:17 -0000 On 8 April 2014 14:45, Nathan Dorfman wrote: > Are you sure about that? The only email I saw stated that FreeBSD 8.x > and 9.x weren't vulnerable because they were using an older OpenSSL, > from before the vulnerability was introduced. That is correct. > FreeBSD 10-STABLE, on the other hand, seems to use the vulnerable > OpenSSL 1.0.1e, and I didn't immediately see OPENSSL_NO_HEARTBEATS in > the Makefile there. So I may well be missing something, but it looks > vulnerable at first glance. Also correct. I see that the fixes were committed a few minutes ago: FreeBSD current: r2642675 http://svnweb.freebsd.org/base?view=revision&revision=264265 FreeBSD stable/10: r2642676 http://svnweb.freebsd.org/base?view=revision&revision=264266 FreeBSD 10.0: r264267 http://svnweb.freebsd.org/base?view=revision&revision=264267 From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 19:00:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14F3EC50 for ; Tue, 8 Apr 2014 19:00:22 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8EE01620 for ; Tue, 8 Apr 2014 19:00:21 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id s7so900228qap.35 for ; Tue, 08 Apr 2014 12:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Air0q1B+prm0/x6u4hE3Yt8hUKoQXL7kUQ2KxenfQDQ=; b=uKRVe6RzulFXgp4zGb+WJXG2vX4jZ+DsahUxsKWd1cCDH+xnucbJ/m8ybn5K0ISe17 pCwCFVrPM87HRw7NNHNPCYtFpNcHVEFWc/rpYwGG4jWsSI8y+0LQSMSv0q4v2jcEpjzl Eeb97u4ijpqYaxE2sXRPMwXg8CVCOB1xi6WqLVoGZBpy4Ru4GmbE84Geund22kP7OfWL 6ckQdHuZAVymDS4yPBmlKjMoq3ecf077N7Sjk2LGGmdNJ6aucJ8mxRpq4eBhhHHOZEat 5TQCTJ/WY+DPM/Ez0w9Qq7OQz8ZlabuXpU9vy1q6kUakGu6FXIcN+x74NHwXYkXX8Qp6 tU9A== MIME-Version: 1.0 X-Received: by 10.140.82.167 with SMTP id h36mr6557279qgd.51.1396983620883; Tue, 08 Apr 2014 12:00:20 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.88.105 with HTTP; Tue, 8 Apr 2014 12:00:20 -0700 (PDT) In-Reply-To: References: <20140408181745.F06A2C007AD@frontend1.nyi.mail.srv.osa> Date: Tue, 8 Apr 2014 15:00:20 -0400 X-Google-Sender-Auth: 3onaroHDH4PIBq9WG6JWepTkabE Message-ID: Subject: Re: FreeBSD's heartbleed response From: Ed Maste To: Nathan Dorfman Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:00:22 -0000 On 8 April 2014 14:53, Ed Maste wrote: > I see that the fixes were committed a few minutes ago: Oops, some typos in the revision numbers in my last email (but the links were fine) -- here are the correct revision numbers: FreeBSD current: r264265 http://svnweb.freebsd.org/base?view=revision&revision=264265 FreeBSD stable/10: r264266 http://svnweb.freebsd.org/base?view=revision&revision=264266 FreeBSD 10.0: r264267 http://svnweb.freebsd.org/base?view=revision&revision=264267 From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 19:02:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93545D89 for ; Tue, 8 Apr 2014 19:02:23 +0000 (UTC) Received: from mx1.adversec.com (adversec.com [94.23.253.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E83616BF for ; Tue, 8 Apr 2014 19:02:23 +0000 (UTC) Date: Tue, 08 Apr 2014 20:54:35 +0200 From: Niklaus Schiess MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response References: <20140408174210.GA5433@behemoth> <20140408195049.04129f2a@azsupport.com> In-Reply-To: <20140408195049.04129f2a@azsupport.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:02:23 -0000 Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2 support in 0.9.x. So thats not an excuse. On 08.04.2014 19:50, Andrei wrote: > On Tue, 8 Apr 2014 10:46:12 -0700 > Mark Boolootian wrote: > >> While it may not be quite what you're looking for, ports contains >> OpenSSL 1.0.1g. > > And also FreeBSD 8.x/9.x not affected because have 0.9.x OpenSSL in base. > _______________________________________________ > 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" > -- PGP FP: CB84 8C68 ADDB 6C50 7DF1 4227 F2A6 056A A799 76DA From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 19:09:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADB431E5 for ; Tue, 8 Apr 2014 19:09:21 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77393173F for ; Tue, 8 Apr 2014 19:09:21 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id gq1so1534419obb.32 for ; Tue, 08 Apr 2014 12:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VIoWTUk0qYk/drJOj5LxxHs1qrFT701OA1p5jBtjBqg=; b=TJ2mRzbl9hqT0rK8DDzdbCvPw00N2JZ7wC0GY0LIpGFlU/TYBIhw3ifQrzFjj3mVt0 rgdG35jZecvtTrvQWTav1dxeNM1IGM+jPbaFLHSVM6TK7Jy/mNtiYnM8NjvXxMqHMW5x QVFY5KWvKPXnYYnYkc7kIummeFwNW3Xh6wwRkRNK8I7UkkSFhodkFuM4wxcvxgXRc6X2 O58FcrV+zUxB5w65nzbXNu7iJL5/co1fymdIKnctvkOOjRo7YFF3AeSOruMErqxySSD8 S9KuvJWUggoQ7O9FJc+//RTSn5P3L9AMU1Mt3Awj7Z83JS9LkNa0Lrwy55h5hUUuA+SR rIoA== MIME-Version: 1.0 X-Received: by 10.60.124.227 with SMTP id ml3mr3087988oeb.67.1396984160768; Tue, 08 Apr 2014 12:09:20 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.60.158.106 with HTTP; Tue, 8 Apr 2014 12:09:20 -0700 (PDT) In-Reply-To: <20140408190227.8774EDD1@hub.freebsd.org> References: <20140408174210.GA5433@behemoth> <20140408195049.04129f2a@azsupport.com> <20140408190227.8774EDD1@hub.freebsd.org> Date: Tue, 8 Apr 2014 15:09:20 -0400 X-Google-Sender-Auth: UmafeyWKsHrvP5iak7OVYSfkd_g Message-ID: Subject: Re: FreeBSD's heartbleed response From: Nathan Dorfman To: Niklaus Schiess Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:09:21 -0000 Uh, an excuse for what exactly? You must be talking about installing 1.0.1 from the ports. That was fixed yesterday by updating the version in ports to 1.0.1g: http://svnweb.freebsd.org/ports?view=revision&revision=350548 -nd. On Tue, Apr 8, 2014 at 2:54 PM, Niklaus Schiess wrote: > Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2 > support in 0.9.x. So thats not an excuse. > > On 08.04.2014 19:50, Andrei wrote: >> On Tue, 8 Apr 2014 10:46:12 -0700 >> Mark Boolootian wrote: >> >>> While it may not be quite what you're looking for, ports contains >>> OpenSSL 1.0.1g. >> >> And also FreeBSD 8.x/9.x not affected because have 0.9.x OpenSSL in base. >> _______________________________________________ >> 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" >> > > -- > PGP FP: CB84 8C68 ADDB 6C50 7DF1 4227 F2A6 056A A799 76DA > _______________________________________________ > 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 Tue Apr 8 19:21:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22B0F90E for ; Tue, 8 Apr 2014 19:21:42 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DFE9918E8 for ; Tue, 8 Apr 2014 19:21:41 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s38JLbbS082423 for ; Tue, 8 Apr 2014 15:21:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <53444C33.4060408@sentex.net> Date: Tue, 08 Apr 2014 15:21:23 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response References: <20140408174210.GA5433@behemoth> <20140408195049.04129f2a@azsupport.com> <20140408190227.70A5CDB9@hub.freebsd.org> In-Reply-To: <20140408190227.70A5CDB9@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:21:42 -0000 On 4/8/2014 2:54 PM, Niklaus Schiess wrote: > Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2 > support in 0.9.x. So thats not an excuse. The FreeBSD security team only maintains advisories for the base distributions. What people install from the ports are not covered by those advisories. Issues affecting the FreeBSD Ports Collection are covered in http://vuxml.freebsd.org/ ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 19:26:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6989A73 for ; Tue, 8 Apr 2014 19:26:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F8C11958 for ; Tue, 8 Apr 2014 19:26:45 +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 s38JQdQ4034885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2014 12:26:39 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s38JQc3Z034884; Tue, 8 Apr 2014 12:26:38 -0700 (PDT) (envelope-from jmg) Date: Tue, 8 Apr 2014 12:26:38 -0700 From: John-Mark Gurney To: Florent Peterschmitt Subject: Re: FreeBSD's heartbleed response Message-ID: <20140408192638.GA34745@funkthat.com> Mail-Followup-To: Florent Peterschmitt , Mark Boolootian , Chris Nehren , freebsd-security@freebsd.org References: <20140408174210.GA5433@behemoth> <5344427B.3060205@peterschmitt.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5344427B.3060205@peterschmitt.fr> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Tue, 08 Apr 2014 12:26:39 -0700 (PDT) Cc: Mark Boolootian , Chris Nehren , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:26:45 -0000 Florent Peterschmitt wrote this message on Tue, Apr 08, 2014 at 20:39 +0200: > On 08/04/2014 19:46, Mark Boolootian wrote: > > While it may not be quite what you're looking for, ports contains > > OpenSSL 1.0.1g. > > Why not moving critical parts of the basesystem to ports, that will be > installed at system installation of course? Because we have programs in base that depend upon OpenSSL... so, moving OpenSSL out of base is not really an option, unless you want to remove fetch, hostapd, pkg, and wpa_supplicant from the base system, we are stuck w/ OpenSSL in base... yes, there is pkg there, how are you going to fetch packages to install if you don't have that? btw, all found w/ ldd /usr/bin/* /usr/sbin/* 2>/dev/null | less and searching for libssl... -- 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 Tue Apr 8 19:42:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AF43FF5 for ; Tue, 8 Apr 2014 19:42:30 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA2061B03 for ; Tue, 8 Apr 2014 19:42:29 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wp4so1526667obc.26 for ; Tue, 08 Apr 2014 12:42:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=pEa0xj9YcDqvxYKus1uY9+Qr/37eL+depTU40URMHXs=; b=giUsB8xktaGaiQRTifYkdiuaL50T9cO8CH+J77zjH753JQZBGyxId3YQ/F4vM24v/o dgC744daksjaDA0WbcsDPj1Q9xBne0lDj2+dN/XxJfVp1lfzZ5hSJnO/w4VMAqsXwnw4 wP/iRS5Ok7Xnj4lpvm0E6/qVN+4GXUuOKt/KjMvCQ71er+aE3zbaB1+tesgnIlJnx3ft YJ7glfcR3e6Yyj6Fc98sTDOxn0h5O/WRWFNWFfw3IpmeoC1PKiROpagGYmPqgkFWtOIc aBOsVlixqg2xgQtt9+pACfmRd0ijI04RJHj4jNPIKmcmhUAwikKPMXBt1zQKKbKWfgO/ OCAw== X-Gm-Message-State: ALoCoQnDi94iCMdQHz43cPrNbd3TA07x3yCf1htt0uu0GvcUstDHXTNRyy297+Spa+2xlAOBuAtQ X-Received: by 10.60.47.15 with SMTP id z15mr2158946oem.80.1396986148691; Tue, 08 Apr 2014 12:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.5.68 with HTTP; Tue, 8 Apr 2014 12:42:08 -0700 (PDT) From: Daniel Howard Date: Tue, 8 Apr 2014 12:42:08 -0700 Message-ID: Subject: OpenSSL on 8.3 (pfsense appliance) To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 19:42:30 -0000 Hello, Per the heartbleed vulnerability, I'm looking at a vulneranle pfsense firewall appliance: # /usr/bin/openssl version OpenSSL 0.9.8y 5 Feb 2013 # /usr/local/bin/openssl version OpenSSL 1.0.1e 11 Feb 2013 # ldd /usr/local/sbin/openvpn | grep libssl libssl.so.8 => /usr/local/lib/libssl.so.8 (0x8007e9000) Per Brian Drewery, the port has been fixed, but this appliance does not have ports installed. I see an openssl package here: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openssl.tbz At this moment, the timestamp is January. Can one reasonably expect that there is a process building updated packages for this branch? Can anyone advise how long before a new openssl package is published here? Or should I spin up an 8.3 box to build a package? Has anyone else here patched a pfsense appliance yet? Last I saw their fix ETA is Thursday. Thanks, -danny -- http://dannyman.toldme.com From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 20:22:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B86ACC3 for ; Tue, 8 Apr 2014 20:22:07 +0000 (UTC) Received: from mail.carlostrub.ch (319.ch [88.198.108.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A5FF1FE3 for ; Tue, 8 Apr 2014 20:22:06 +0000 (UTC) Received: from c-st.net (localhost [127.0.0.1]) (Authenticated sender: cs@carlostrub.ch) by mail.carlostrub.ch (Postfix) with ESMTPA id 0A64718CC2B; Tue, 8 Apr 2014 22:21:53 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: OpenSSL on 8.3 (pfsense appliance) X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/) X-Mailer: OTRS Mail Service (3.3.5) Date: Tue, 8 Apr 2014 22:21:53 +0200 Message-ID: <1396988513.858894.14605605.113546.2@c-st.net> To: dannyman@toldme.com Organization: Carlo Strub From: Carlo Strub In-Reply-To: References: Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 20:22:07 -0000 08/04/2014 21:44 - Daniel Howard wrote: > Hello, >=20 > Per the heartbleed vulnerability, I'm looking at a vulneranle pfsense > firewall appliance: >=20 > # /usr/bin/openssl version > OpenSSL 0.9.8y 5 Feb 2013 > # /usr/local/bin/openssl version > OpenSSL 1.0.1e 11 Feb 2013 > # ldd /usr/local/sbin/openvpn | grep libssl > libssl.so.8 =3D> /usr/local/lib/libssl.so.8 (0x8007e9000) >=20 > Per Brian Drewery, the port has been fixed, but this appliance does not > have ports installed. >=20 > I see an openssl package here: > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/op= enssl.tbz >=20 > At this moment, the timestamp is January. Can one reasonably expect that > there is a process building updated packages for this branch? Can anyone > advise how long before a new openssl package is published here? Or should > I spin up an 8.3 box to build a package? >=20 > Has anyone else here patched a pfsense appliance yet? Last I saw their f= ix > ETA is Thursday. >=20 >=20 > Thanks, > -danny >=20 > --=20 > http://dannyman.toldme.com > _______________________________________________ > 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 For pfsense, you should definitely ask this question in the pfsense forum (= http://forum.pfsense.org/). Pfsense is essentially a fork of FreeBSD and th= ey have their own type of package system. They just released version 2.1.1 = a few days ago, but I doubt it includes the latest patches of openssl. -- Carlo Strub Ports committer= From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 21:17:37 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 095BCB7B for ; Tue, 8 Apr 2014 21:17:37 +0000 (UTC) Received: from smtp.peterschmitt.fr (smtp.peterschmitt.fr [IPv6:2a01:4f8:a0:72c8:4224::1]) by mx1.freebsd.org (Postfix) with ESMTP id BDA08165B for ; Tue, 8 Apr 2014 21:17:36 +0000 (UTC) Received: from [192.168.1.121] (89-159-92-168.rev.dartybox.com [89.159.92.168]) by smtp.peterschmitt.fr (Postfix) with ESMTPSA id 5D61C60157; Tue, 8 Apr 2014 23:17:19 +0200 (CEST) Message-ID: <5344679D.4050707@peterschmitt.fr> Date: Tue, 08 Apr 2014 23:18:21 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Mark Boolootian , Chris Nehren , freebsd-security@freebsd.org Subject: Re: FreeBSD's heartbleed response References: <20140408174210.GA5433@behemoth> <5344427B.3060205@peterschmitt.fr> <20140408192638.GA34745@funkthat.com> In-Reply-To: <20140408192638.GA34745@funkthat.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dntjKxN5hicMLjcjRIhnP0RjwabLoA6os" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:17:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dntjKxN5hicMLjcjRIhnP0RjwabLoA6os Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do we need to fetch them from the Internet? Local packages can do the job, nope? But it will lead to kind of bootstrapping=85 or everything as packages bootstrapped once for all. And yes, it will not be some pie (a french stock phrase meaning it will be hard, translated word for word :) ). On 08/04/2014 21:26, John-Mark Gurney wrote: > Florent Peterschmitt wrote this message on Tue, Apr 08, 2014 at 20:39 += 0200: >> On 08/04/2014 19:46, Mark Boolootian wrote: >>> While it may not be quite what you're looking for, ports contains >>> OpenSSL 1.0.1g. >> >> Why not moving critical parts of the basesystem to ports, that will be= >> installed at system installation of course? >=20 > Because we have programs in base that depend upon OpenSSL... so, > moving OpenSSL out of base is not really an option, unless you want > to remove fetch, hostapd, pkg, and wpa_supplicant from the base system,= > we are stuck w/ OpenSSL in base... >=20 > yes, there is pkg there, how are you going to fetch packages to install= > if you don't have that? >=20 > btw, all found w/ ldd /usr/bin/* /usr/sbin/* 2>/dev/null | less and > searching for libssl... >=20 --dntjKxN5hicMLjcjRIhnP0RjwabLoA6os Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTRGedAAoJEFr01BkajbiBIPoP/RkdZ6kwv5w4z/WDGLmwk6Yp fLpDxRuzF4Z/7Qt4BBWmf5wMjAJZieJmO3QGfQwIuPVwjLAIWMbWdEX0eOCMWZDh 1Y3PiCrKJZYCHNSSpEBtZScwpi/RgEBbF30Jq7ZW5W0s2/veqQLB4/ChcSqcF6Y3 SR2CfsV3DaEQ8rs3LN2mDq5LUJ6tzub70UbOT8fW53ufm4PleTQjcsiBGj6uCV78 mfM8bJSn/FgvPpoSDfn/8/eOOXrz9KUT4xP5rfrxgNEmNfPTTEDv8kC7ItFvOj/w CLllkDJOXjgJoCBzVd6Mi3GyiwxDuZ4vrrjoC2DckeWwRYwABAjJuIr40Om8jI4q 8TNC7Ol9Sbu3b90VRufgXx+cyqMXxEVQzVUtJI0uJnYLdu/sTxLc6oiqAM+ayQTz G61lVcFZkcrnipj8w6fO4yD4OlFCLEzAxgAFu3mkwXzoKBPsiFi2FZkLLvRIPjFT Fxe3U3wq5ne0lG7MIXKH592L/RCPUm5p+WYEovYyhrGC3CCJOYCx7nMoFff1JAQm v6W67hetnonh6k2cd59PABlVyUM+wKdhmDFxKPuXy6/0nmn/7fmbTG9KOc/BlBa3 onuarPsNTe3ngQvnOQscof/e+gUb2Ed6Bi2OE6WaawdzR1LS/jotLcbH09h3fgK0 CrkqK2HxpXxtTqa7c5im =iyg9 -----END PGP SIGNATURE----- --dntjKxN5hicMLjcjRIhnP0RjwabLoA6os-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 22:47:32 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E889BB8; Tue, 8 Apr 2014 22:47:32 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BBCB108A; Tue, 8 Apr 2014 22:47:32 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id D980313B57; Tue, 8 Apr 2014 15:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1396997251; bh=FMsnNTrucBu81hgwG01B9sZo53ZwgxrCm9z+2z0ZwUc=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=z1HDcJvIKyKIvOuA4imrQuM63AUw2dQXF4Hpv8UGOcKOZ4wtgexwmn8flxUy1ug8c pjzf4UdARCYtYtsbK/fLqaxYb2TTScxuNQboQI1R8cEsCdJRT2XpvJ3E3olI48V4pu VIxpe9s5P9IQVKsWWGqEjQSoAqcHBEXVghVNH1CU= Message-ID: <53447C81.6040106@delphij.net> Date: Tue, 08 Apr 2014 15:47:29 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Thierry Thomas , freebsd-security@FreeBSD.ORG Subject: Re: Heartbleed / r264266 / openssl version References: <20140408212917.GA9914@graf.pompo.net> In-Reply-To: <20140408212917.GA9914@graf.pompo.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , Bryan Drewery X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 22:47:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (Adding Bryan who asked this and Ben who is the maintainer as they might have some saying here; moving to public list as there is no sensitive information in this discussion). On 04/08/14 14:29, Thierry Thomas wrote: > Hello, > > I've just rebuilt a 10-STABLE server, and now: > > $ openssl version OpenSSL 1.0.1e-freebsd 11 Feb 2013 > > Actually, delphij's commit did'nt change the VERSION string in > crypto/openssl/Makefile. > > This is not very important, but it may be confusing for users. Bryan have brought this up on IRC as well. As far as I know, for the last decade we never bump the version number when making updates, unless it's a "wholesale" upgrade of certain components in very special circumstances. I have done a quick check on Linux systems and found they don't carry a patchlevel for "openssl" either however they do provide a way to tell the patchlevel because it's a package. However, they do bump the date as part of the update. What would be the preferable way of representing the patchlevel? We can do it as part of a EN batch at later time. (Note though, even without this the user or an application can still use freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out the patchlevel for userland). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRHyBAAoJEJW2GBstM+nspTsP/RucGMxAU6c7Bn9N0zGGWGBp mjlfTa5wlTYC+04VHX0q/LwFng+bUfPRqY3WC89VOuQkpgDgz/V/PwaZSG+92ib1 h6yQVzojOkV4vvVv2OBcfaaVUuAyIq8HGGT0gMh5wlnpoEt2k8d3GsilPU+R6jUz LQMhc07GAtUfDN7AErZ4TAsouaSQh7Z28tl7F5usel/V502jAzoA8B3qo+otRHnI DLYVSHmOAHrtCJoahC1eLm6zYdJWydyEtzUhDzNhWvGyptnQTw+KP48DoetJiVk7 06l/lODsJB9qh+A9u0ac8MAj/Zx8MTHB1cbP5yXyzr27dTzRe+pLbqqgmrKYA5Xj oQY3wumS8rAclfj7KHgZeE6ZGzp4at8pfrmuxlO/Pf8Si102kXakSoEwtUx9WU/I hgX/t6IPLhxLG7IoU/pJlETE8pAB81STOQs1QrPigK28UYhk3tc9H26TzkcfZvFz 5o86blfV0E6xdkuRUMT3i5sPj2DpHW75MTXzeM/ADdeRgdZBMW5GvDQAhtQCMQGN 1baTZjz46a3ZfJ3lJKbYGRAtGONH5QmeqfX2WlPKOf9ZrX3GMk3OSevcEEJ7QE9f ihccNQzuFMzTkFiE8WBrP5xr9YKXQdM9Uqdx/cDC/PNTnguzAon69bU9m1AJLsPv Xr3LKX5wWT83jO5WW1RX =t1w7 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 22:59:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76528D93 for ; Tue, 8 Apr 2014 22:59:09 +0000 (UTC) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id 41D4B1174 for ; Tue, 8 Apr 2014 22:59:09 +0000 (UTC) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id F17467B338 for ; Tue, 8 Apr 2014 18:59:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=Ix/94dVPvjMa9nXztS+TAXS1L2k=; b=AYOGCx5 uFNis8rMPYo41vjzk/AszFIPxUERXQ97U1VXZdKjBXjFif1+wZ79vM//neODRP7d KphRwldO7GVyLw/OleuIplU0ZgqUYfUjSKmu9ZwL8Kqy/P1hWxL0mOgRcqXtp4u8 V8htxlKODchveqSGj82zaDWAJ5l+fejzgrt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=FN74/D1okBmmP39TwWNBtO6+83UCBRyFD 1DdqZG0CVF7U2IFuzHCIfcUX+FyYOnzYsCZGolPY3vJDcwS3UVWGlKXGiWccND5A iMGpBxmWbBHOWU5pX0p+fqz4WyQxtvm4j50fE0sVERt8a0KFmCKfMhliqfyDgnfU 3NjCqAud8Q= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id DC42F7B336 for ; Tue, 8 Apr 2014 18:59:06 -0400 (EDT) Received: from localhost (unknown [76.99.50.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 3AE987B315 for ; Tue, 8 Apr 2014 18:58:47 -0400 (EDT) Date: Tue, 8 Apr 2014 18:58:46 -0400 From: Chris Nehren To: freebsd-security@freebsd.org Subject: Re: Heartbleed / r264266 / openssl version Message-ID: <20140408225846.GB5433@behemoth> References: <20140408212917.GA9914@graf.pompo.net> <53447C81.6040106@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: <53447C81.6040106@delphij.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 5790107E-BF71-11E3-AF05-8D19802839F8-49531120!b-pb-sasl-quonix.pobox.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 22:59:09 -0000 --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2014 at 15:47:29 -0700, Xin Li wrote: > What would be the preferable way of representing the patchlevel? We > can do it as part of a EN batch at later time. (Note though, even > without this the user or an application can still use > freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out the > patchlevel for userland). On an updated system: [(18:56:41) apeiron@behemoth ~] freebsd-version 10.0-STABLE [(18:56:42) apeiron@behemoth ~] freebsd-version -k 10.0-STABLE [(18:56:43) apeiron@behemoth ~] freebsd-version -u 10.0-STABLE [(18:56:47) apeiron@behemoth ~] I can't say this is very useful. Is this only supposed to work for -RELEASE? --=20 Chris Nehren --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQJdBAABAgBHBQJTRH8mQBSAAAAAABUAInBrYS1hZGRyZXNzQGdudXBnLm9yZ2Nu ZWhyZW4rZnJlZWJzZC1zZWN1cml0eUBwb2JveC5jb20ACgkQHo59aFf/oVMhaw/+ LanVHiVYibCvQer7W0lgVRqYppiNQ4zGN154y/52jIAxHW8/lplyIFlcyGnSmNn/ iL28C0xQkzRh4xkM16pH5Wl2wsUq2V7lf2+oG4H6x3VCJMLWl+Jp+lZQiw8fv9dE UTG42tK2Pqc71BHpwScGYEjvRR60J80d0Gyu94kArVel5rLjlVlz5l51/WgJ3vg+ rZGL6BEMshSPH59k/TrrjjMl9VhLocfUEcla4YWZyhHnNOSdE5VtPf8hWhArjOT+ 0LGiJNImV3eUiYFwwO8uALWL4O9ju/+HWVJwbu8Fl5I3Kw/GtUdxoKbD5tjlI152 ebjJBdFK99mPnRyCAMVdM/NB+0CWDvJUfqEyISv1QTuB8+f/NgxZpJDZtxCMqRJg AskOVx0QWb65uXfVryzcpajOFreRseWQV6inHOQRERJmtOKcuRLmzSEWYF909WeF ry2C+N25KAOpS9NWaADvBCvF3B4j+fgBD1OF14BccPZKyxm2qrij8xgAb6FQQO4q KzT0QViLt8JuTsWzP5vIjGoHcv9WjQB+foJQ+lMPrW9vjN1t03y5jJCWTlZ9LDUq sOER1jSda4YAgk87XqCfvh0ZbqyX9pMdbgfchtWkiamtqE5Dt+8Hy8tvvrOXay30 9ljCeYr9keYTExYg2wHahN7w8M29qaUwrAOYBc4OePg= =q6jZ -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 23:03:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2CAEEB1 for ; Tue, 8 Apr 2014 23:03:47 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 97FFD121B for ; Tue, 8 Apr 2014 23:03:47 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B154813EA5; Tue, 8 Apr 2014 16:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1396998224; bh=mHsJ7xeY5sWbBFeZHjymlMK/YX8fLsFSJvkVLgq+Bqc=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=1oCXeNJb37wtFTO41oYRcT1omk6otxUtShMkQG7GYTPzFNtNvRlFq4WiZ37LHD1wD gEoy+anzxN4PYGyhapw/5X72nkB8lAA6bMp7PNblfnib+REDbB7BnbJaHTPf1iXXAy WLJ0uPsoTiH6k+kOCmRdczqG3HeJmMwJHpEKucok= Message-ID: <53448050.9010802@delphij.net> Date: Tue, 08 Apr 2014 16:03:44 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Chris Nehren , freebsd-security@freebsd.org Subject: Re: Heartbleed / r264266 / openssl version References: <20140408212917.GA9914@graf.pompo.net> <53447C81.6040106@delphij.net> <20140408225846.GB5433@behemoth> In-Reply-To: <20140408225846.GB5433@behemoth> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 23:03:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/08/14 15:58, Chris Nehren wrote: > On Tue, Apr 08, 2014 at 15:47:29 -0700, Xin Li wrote: >> What would be the preferable way of representing the patchlevel? >> We can do it as part of a EN batch at later time. (Note though, >> even without this the user or an application can still use >> freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out >> the patchlevel for userland). > > On an updated system: > > [(18:56:41) apeiron@behemoth ~] freebsd-version 10.0-STABLE > [(18:56:42) apeiron@behemoth ~] freebsd-version -k 10.0-STABLE > [(18:56:43) apeiron@behemoth ~] freebsd-version -u 10.0-STABLE > [(18:56:47) apeiron@behemoth ~] > > I can't say this is very useful. Is this only supposed to work for > -RELEASE? Only for -RELEASE (note that 10.0-STABLE will be fully updated to a newer OpenSSL release soon so I'm not going to change anything there). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRIBQAAoJEJW2GBstM+nsR4AP/0MQ506KSLfzk9yPv/xTCBe3 vO9grcXPvjNieIZj7unhUJeHjgUoJju9CNZJ6Ee6vNACPAOpa3k1S63YbVCLZWhb Xv2N6TccWsY7Ioju4Mj+6IOOGS6R4yPmMFbd5/vFVTedZcgw5wZOFO+uLGXo05yG sTp9duMM40y3LaUGWje9BAa3Rc2CsrFkedsOgEJGoolpctq9xCGfdD4mKh8hhpQu Jdaz72+Tg0dthNSxpAYPXTGqSjYexPJWqVDm7+pQ7m4kU2otJqCkHH34OqcFRnCB UdDFhzX3hYHL569OW+uwNFguLko5iZ38I0fcRRhDs5M7bF84JzKuBCSjTaoQx2t+ xNSLvpuIW7PhhQQd4Ok9mHfocP1LBnisi3y/oL2mjDF6jlFH4hOS9gc14SPsGAHE jZLUy/H3MODC9vXelOlSYJEqkARRly8aAR6ils4NaOVLapOZAC3pjXr2nAMU0acS sgoCpysvWnx7MaNkBO9ZHT0bmSGmQH8jr29yzzBnZ9Tt4XZBtcGbX+Z0p1WgmUod wlB9IMI6qECEuPqgmkLCE4RPiIyJiFYzqwXPFI9m4+YkbVRpQTEFmzq8HL+ILqQ2 DA6BAfK0xNYZ3cGgKHfo8HvD6ffGfnG5rwGB5hS9MKAv1yaO1Y72H8LxhGyGq3ZR 6l81ijSaeHKsqUGDD9vw =D/V9 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 23:34:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 860D29CB; Tue, 8 Apr 2014 23:34:12 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7193814FC; Tue, 8 Apr 2014 23:34:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s38NYCNK098551; Tue, 8 Apr 2014 23:34:12 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s38NYC8J098549; Tue, 8 Apr 2014 23:34:12 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 8 Apr 2014 23:34:12 GMT Message-Id: <201404082334.s38NYC8J098549@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:05.nfsserver Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 23:34:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:05.nfsserver Security Advisory The FreeBSD Project Topic: Deadlock in the NFS server Category: core Module: nfsserver Announced: 2014-04-08 Credits: Rick Macklem Affects: All supported versions of FreeBSD. Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) CVE Name: CVE-2014-1453 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The Network File System (NFS) allows a host to export some or all of its file systems so that other hosts can access them over the network and mount them as if they were on local disks. FreeBSD includes both server and client implementations of NFS. II. Problem Description The kernel holds a lock over the source directory vnode while trying to convert the target directory file handle to a vnode, which needs to be returned with the lock held, too. This order may be in violation of normal lock order, which in conjunction with other threads that grab locks in the right order, constitutes a deadlock condition because no thread can proceed. III. Impact An attacker on a trusted client could cause the NFS server become deadlocked, resulting in a denial of service. IV. Workaround Systems that do not provide NFS services are not vulnerable. Neither are systems that do but use the old NFS implementation, which is the default in FreeBSD 8.x. To determine which implementation an NFS server is running, run the following command: # kldstat -v | grep -cw nfsd This will print 1 if the system is running the new NFS implementation, and 0 otherwise. To switch to the old NFS implementation: 1) Append the following lines to /etc/rc.conf: nfsv4_server_enable="no" oldnfs_server_enable="yes" 2) If the NFS server is compiled into the kernel (which is the case for the stock GENERIC kernel), replace the NFSD option with the NFSSERVER option, then recompile your kernel as described in . If the NFS server is not compiled into the kernel, the correct module will be loaded at boot time. 3) Finally, reboot the system. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:05/nfsserver.patch # fetch http://security.FreeBSD.org/patches/SA-14:05/nfsserver.patch.asc # gpg --verify nfsserver.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/ r264285 releng/8.3/ r264284 releng/8.4/ r264284 stable/9/ r264285 releng/9.1/ r264284 releng/9.2/ r264284 stable/10/ r264266 releng/10.0/ r264267 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRISyAAoJEO1n7NZdz2rnOvoQAJoxWjKV1UACccAi4Z/ChESU rSi2NrW6ZixCmSzbPxAcz9Qv7vaQVSywfG5Zy1JddNh1aVy4ExUsd/FZcRr92Cz2 ujprve/JBMc0YOsND7KIna9Rk7Ryj0IchRXquN5SyDhZbvWwnDNatQWID5awzgYM aX+48WUFk/oFX009JCR2LO3u3GqOZN6fJhLSQs+Yj+CuxQO9XlQSSUK+lTDO/2ig snT7j52eCJhsMNn1QcdMGx1Y+NdfIEDfinioAPKLUfWCXWwNRAhTD5scasHDQWV4 60kVXZzl/CNOD7awOXwIrx3GRPQSwsg2YUqGP+jXlEdIA+MNE5+vUijDcLI/cTBj WSApShrdybIyOyPzczDKmLae9NUeKspUoZTwwwSJ6p8Zr6m0/dBzKbk7TB+XFn17 Q1FVDkpq7pJUzPQxNfB9Z6wwRXeZgaJBEck/P0DvHZwJDq1mZLbcPFap91I4p471 iBVhSHHP466pj0EUuCjNrld7BgVj/iCrCO7LZr4L9t/7sDAIE+CYqv5eR7byUIOO WoMs3zplSR1XgTk5c9p6XQifv3dtRGyJicfjtKdNFxYjeokIhXxdAjWjQmwC2XoG PK7enzV2MHWg3nCpdCztD+4ZjHqdwOq/o2g0rVrum7SfOeZXyqr+YB58rpd6uR11 8z8hxDfKCzc/Lo1/T+EO =xBcd -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Apr 8 23:34:13 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DB419D2; Tue, 8 Apr 2014 23:34:13 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38FEC1501; Tue, 8 Apr 2014 23:34:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s38NYDW9098585; Tue, 8 Apr 2014 23:34:13 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s38NYDGb098583; Tue, 8 Apr 2014 23:34:13 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 8 Apr 2014 23:34:13 GMT Message-Id: <201404082334.s38NYDGb098583@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 23:34:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:06.openssl Security Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-04-08 Affects: All supported versions of FreeBSD. Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) CVE Name: CVE-2014-0076, CVE-2014-0160 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) which uses Elliptic Curve Cryptography. OpenSSL uses the Montgomery Ladder Approach to compute scalar multiplication in a fixed amount of time, which does not leak any information through timing or power. II. Problem Description The code used to handle the Heartbeat Extension does not do sufficient boundary checks on record length, which allows reading beyond the actual payload. [CVE-2014-0160]. Affects FreeBSD 10.0 only. A flaw in the implementation of Montgomery Ladder Approach would create a side-channel that leaks sensitive timing information. [CVE-2014-0076] III. Impact An attacker who can send a specifically crafted packet to TLS server or client with an established connection can reveal up to 64k of memory of the remote system. Such memory might contain sensitive information, including key material, protected content, etc. which could be directly useful, or might be leveraged to obtain elevated privileges. [CVE-2014-0160] A local attacker might be able to snoop a signing process and might recover the signing key from it. [CVE-2014-0076] IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols implementation and do not use the ECDSA implementation from OpenSSL are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 8.x and FreeBSD 9.x] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch.asc # gpg --verify openssl.patch.asc [FreeBSD 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc # gpg --verify openssl-10.patch.asc Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install IMPORTANT: the update procedure above does not update OpenSSL from the Ports Collection or from a package, known as security/openssl, which has to be updated separately via ports or package. Users who have installed security/openssl should update to at least version 1.0.1_10. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r264285 releng/8.3/ r264284 releng/8.4/ r264284 stable/9/ r264285 releng/9.1/ r264284 releng/9.2/ r264284 stable/10/ r264266 releng/10.0/ r264267 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRISyAAoJEO1n7NZdz2rnwdgP/RFT6HsugPJZeIKX2Rn36Mat qgAET7gotiU1Y7G/647BiSCOn/BQs9Z1yTLE7wKdgiVDDTZOHJCJxssXav/+Cqli G1Cyoi2Rv9R77sno0wdj62YguTg0EKnU52CYpHVmF2NA0H/zexXDrCgiQtyvnU62 ZtM2TO76qhKFXwNtIQ1EQYmu+qsxLbp65ryyu9Tq7rXlc52JYTa0QdWDcKoPtcBO U85HzJwQglX2lEmipv63s0vwur5eSTtlWSmUSpFzE1jsjYiRl7xFHQKdXxA5Ifw0 qO7LYrYK7b4EyEq9TcQQKvh05IgorjRcA4i0mSQFpc0HINtgv3bYlHyQL+tyN1+k /4uzdDFB27j8EuKZzEg6aF1JLNq9/zMvx+E0iykPodb5i+n5BzPzWc4rogHvj7rU mfSeABG3m/SifTewy1258V3TRfTKLNU8EPX2CTnJI9WjYX83GO7sM1vtaGQUOAFK gff2tFfeSmDpyCmp+RwnmIr5IefIG2y8s/0iJM/wLF3rW8ZrwP1zX+cot5KRCWfT FpdhHHLRcsCLM7frxmSgRdN+iuXIAcdfbj1EN7z1ryHLk2vRsm2n66kojt4BCnig 7JcStOjMSz843+1L3eCZubHIxVxxjKBGwqVfQ9OWbgeIro0+bapYLJIavuAa9BM6 1T0hWKFh59zAxyGPqX49 =X7Qk -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 01:06:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B6F0D5A; Wed, 9 Apr 2014 01:06:32 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BF4D10CF; Wed, 9 Apr 2014 01:06:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3916VLP035434; Wed, 9 Apr 2014 01:06:31 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3916VOC035432; Wed, 9 Apr 2014 01:06:31 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 9 Apr 2014 01:06:31 GMT Message-Id: <201404090106.s3916VOC035432@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl [REVISED] Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 01:06:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:06.openssl Security Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-04-08 Affects: All supported versions of FreeBSD. Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) CVE Name: CVE-2014-0076, CVE-2014-0160 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 2014-04-08 Initial release. v1.1 2014-04-08 Added patch applying step in Solutions section. I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) which uses Elliptic Curve Cryptography. OpenSSL uses the Montgomery Ladder Approach to compute scalar multiplication in a fixed amount of time, which does not leak any information through timing or power. II. Problem Description The code used to handle the Heartbeat Extension does not do sufficient boundary checks on record length, which allows reading beyond the actual payload. [CVE-2014-0160]. Affects FreeBSD 10.0 only. A flaw in the implementation of Montgomery Ladder Approach would create a side-channel that leaks sensitive timing information. [CVE-2014-0076] III. Impact An attacker who can send a specifically crafted packet to TLS server or client with an established connection can reveal up to 64k of memory of the remote system. Such memory might contain sensitive information, including key material, protected content, etc. which could be directly useful, or might be leveraged to obtain elevated privileges. [CVE-2014-0160] A local attacker might be able to snoop a signing process and might recover the signing key from it. [CVE-2014-0076] IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols implementation and do not use the ECDSA implementation from OpenSSL are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 8.x and FreeBSD 9.x] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch.asc # gpg --verify openssl.patch.asc [FreeBSD 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc # gpg --verify openssl-10.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install IMPORTANT: the update procedure above does not update OpenSSL from the Ports Collection or from a package, known as security/openssl, which has to be updated separately via ports or package. Users who have installed security/openssl should update to at least version 1.0.1_10. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r264285 releng/8.3/ r264284 releng/8.4/ r264284 stable/9/ r264285 releng/9.1/ r264284 releng/9.2/ r264284 stable/10/ r264266 releng/10.0/ r264267 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRJySAAoJEO1n7NZdz2rnzPcQALd6So7vDRBaYiaGwQjc55oI QwTnNzkkgxVTGwi8lDV6h8bIW3Ga8AhMGoZCVOeKbDABBDghVYe6Na5e/wsHbPPu tXmDRhoi2aV0sVCTFfpoCNJ8l2lb+5vnmEC6Oi3PMQDbRC+Ptg15o0W/2hXw0eKO yu4BhS4dl6lX7IvlR1n4sr0rfa8vwxe5OpUUd6Bzw0SUBmV+BTzq1C70FuOZ/hnD ThaZS8Ox3fcWuPylhPbhxnWqg0oVNkBpiRYpIBadrpl9EiRRzbTfF+uFvauR9tBN 1mK8lLwd7DK6x8iCSnDd2ZlN1rNn8EPsGohT4vP+szz2E2YP1x8ugihEBdYax+Dh Z4TWkm3/wJwEf00G32E1hZ8F+UavE8AmnGVk6gxiRpnv2sdNJYRlWd9O8u251qMq uzcmBX6Jr14dQCwlqof8pYKYV7VCE/Cu4JHThOCL042CLwUmXyJVMFzm6WPQlNjC dlPbSG+PXjninPjcYBoMR+863X35Guv0pJBNG/ofEh+Jy5MveaMRQX/mA+wy29zm qg74lM07adXkJujPAuA5dYjZivpW1NPOHeIjaYjaI6KDw2q3BlkGa2C3PeYDQxn4 Iqujqpem5nyQY4BO2XC8gVtuym0jDSA98bgFXumNDkmzlUUuOFOWD8YScLopOzOu EpUXgezogk1Rd3EVsaJ+ =UBO0 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 08:21:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E8191D8 for ; Wed, 9 Apr 2014 08:21:54 +0000 (UTC) Received: from eu1sys200aog108.obsmtp.com (eu1sys200aog108.obsmtp.com [207.126.144.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7483A154D for ; Wed, 9 Apr 2014 08:21:53 +0000 (UTC) Received: from mail-wi0-f169.google.com ([209.85.212.169]) (using TLSv1) by eu1sys200aob108.postini.com ([207.126.147.11]) with SMTP ID DSNKU0UDBM3v9MmpUvTu9XTg+WCkKfjaRbbU@postini.com; Wed, 09 Apr 2014 08:21:53 UTC Received: by mail-wi0-f169.google.com with SMTP id hm4so9123507wib.4 for ; Wed, 09 Apr 2014 01:21:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to :in-reply-to; bh=l78CeqreGH3rTBgAoorZ+BPJliaXi+weHDJNHWNp7Bw=; b=UybaF9Cp2k+w/wrYVH1OysOa2/cv/xy3JTuvT9FAYpH4NJ6PRg8cFrab+JaQhZYsKC FGO37SiKvM3hICPiq0oElYsMVl8yheKECk4Oxdalx7rFUIAJ+pwxT56Vm2qoBie/pGR4 yPF8UATH2OPMSErR7oluUH3PWMuXCa6+Pt+ER6kp7n6Bjvz4UQtaodtfM1DKSTlJP447 JutjfpgfzJ2tL/9hxn8HHX+x7pVLRwdRaANujpIsDMENRVCu/tpLf6mdBrpTeNeq9p3E OY4CYwuyXrVwC3CtApL9y572SaB4FRcZ6zzttgUiuFvQ5qU9uhtFi2K3q2WB+e06y/9x 3TBQ== X-Received: by 10.180.98.165 with SMTP id ej5mr8587039wib.33.1397031684359; Wed, 09 Apr 2014 01:21:24 -0700 (PDT) X-Gm-Message-State: ALoCoQlKL1CclHvQ2TamMM+SFjIAWnv3BdbKoGjuIRJnuxPtRrLwjcokuLKyknyEW/hsZHm3C5eGjPMoCFhMkO7u9c/G04LuziDqex2KeqeG1S48vM/pHlLe7lasHR+hWXSS7k/pFMNZrDHwwxwy9yguZeaULg+Rcw== X-Received: by 10.180.98.165 with SMTP id ej5mr8587021wib.33.1397031684237; Wed, 09 Apr 2014 01:21:24 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id rx9sm476641wjb.20.2014.04.09.01.21.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Apr 2014 01:21:23 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6) with ESMTP id s398LM72020617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Apr 2014 09:21:22 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6/Submit) id s398LMg7020616 for freebsd-security@freebsd.org; Wed, 9 Apr 2014 09:21:22 +0100 (BST) (envelope-from mexas) Date: Wed, 9 Apr 2014 09:21:22 +0100 (BST) From: Anton Shterenlikht Message-Id: <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl In-Reply-To: <201404082334.s38NYDxr098590@freefall.freebsd.org> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:21:54 -0000 >From owner-freebsd-security-notifications@freebsd.org Wed Apr 9 00:37:34 2014 > >IV. Workaround > >No workaround is available, but systems that do not use OpenSSL to implement >the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) >protocols implementation and do not use the ECDSA implementation from OpenSSL >are not vulnerable. Please help me find out if my systems are vulnerable. I use authenticated sendmail with security/cyrus-sasl2: # grep SENDMAIL /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 # I also use ssh-keygen(1). Am I affected? Is it possible to list a few sample base OS programs or libraries which are affected? Apologies if I completely misunderstood the advisory. Thanks From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 08:48:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71061846 for ; Wed, 9 Apr 2014 08:48:27 +0000 (UTC) Received: from lena.kiev.ua (lena.kiev.ua [82.146.51.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34AB41751 for ; Wed, 9 Apr 2014 08:48:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lena.kiev.ua; s=3; h=In-Reply-To:Content-Type:Mime-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=5r9GE6UnH+3l9fpgGbCVqQj2a9Pew7N4rR5ek8V5bsM=; b=GBxUg1NgxGmHdeVD9jlH6y0KAAummn34LeTH0lAmoc/cOxWfbMy0iC9cy7LZG1T+7hNUgYCZcL/yLBifOZ68iEWyQYuX1ocOiv7XoOn7xP9ZR07iFUzIxrtTrlLwm7BtJ5p/wpujkYBC4p61ZcXlK48MmPzjDyt9g/G2bWfcDC4=; Received: from ip-384c.rusanovka-net.kiev.ua ([94.244.56.76] helo=bedside.lena.kiev.ua) by lena.kiev.ua with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WXoBc-0008wu-ET; Wed, 09 Apr 2014 11:48:49 +0300 Received: from bedside.lena.kiev.ua (localhost.lena.kiev.ua [127.0.0.1]) by bedside.lena.kiev.ua (8.14.8/8.14.8) with ESMTP id s398mAPO005475; Wed, 9 Apr 2014 11:48:10 +0300 (EEST) (envelope-from Lena@lena.kiev.ua) Received: (from lena@localhost) by bedside.lena.kiev.ua (8.14.8/8.14.8/Submit) id s398m9OL005474; Wed, 9 Apr 2014 11:48:09 +0300 (EEST) (envelope-from Lena@lena.kiev.ua) Date: Wed, 9 Apr 2014 11:48:09 +0300 From: Lena@lena.kiev.ua To: Anton Shterenlikht Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Message-ID: <20140409084809.GA2661@lena.kiev> Mail-Followup-To: Anton Shterenlikht , freebsd-security@freebsd.org References: <201404082334.s38NYDxr098590@freefall.freebsd.org> <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 08:48:27 -0000 > >systems that do not use OpenSSL to implement > >the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) > >protocols implementation and do not use the ECDSA implementation from OpenSSL > >are not vulnerable. > > Please help me find out if my systems are vulnerable. > > I use authenticated sendmail with security/cyrus-sasl2: > > # grep SENDMAIL /etc/make.conf > SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+= -L/usr/local/lib > SENDMAIL_LDADD+= -lsasl2 > # > > I also use ssh-keygen(1). > > Am I affected? Port mail/sendmail-sasl (sendmail+tls+sasl2-8.14.8) depends on the openssl port. You need to upgrade the security/openssl port to openssl-1.0.1_10 and restart sendmail. SSH is not affected. > Is it possible to list a few sample base OS > programs or libraries which are affected? Besides ports, only FreeBSD 10 base is affected. The recipe was posted here: ldd /usr/bin/* /usr/sbin/* /bin/* 2>/dev/null | less /ssl From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 10:47:43 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D7AAB86 for ; Wed, 9 Apr 2014 10:47:43 +0000 (UTC) Received: from eu1sys200aog112.obsmtp.com (eu1sys200aog112.obsmtp.com [207.126.144.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8280143E for ; Wed, 9 Apr 2014 10:47:42 +0000 (UTC) Received: from mail-wi0-f173.google.com ([209.85.212.173]) (using TLSv1) by eu1sys200aob112.postini.com ([207.126.147.11]) with SMTP ID DSNKU0UlTP+GtytWmvy2Z9ZbTxLmiHyIwOwR@postini.com; Wed, 09 Apr 2014 10:47:42 UTC Received: by mail-wi0-f173.google.com with SMTP id z2so8632613wiv.0 for ; Wed, 09 Apr 2014 03:47:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to; bh=lxFbuU7NBAxZAp0dPc5uXn1klht4rWHYQDcmrErS2vo=; b=hY7rSeA1Qky0w0wMbPZ/rPCYsy+ExCakghfpiSPcPde10FJmJID8ipU2ISSxZsWhAs H//uUm8oJyS/9x9FWQ200HEo024PD3ES03AjjfVqQqRuiXxAE34Ocgkzbj5oMI3WjPBW S3OZX6NAd7NpXM5l5PJD080i495zFxZpl7L3UmOlywvEyMRwBSz2L3OxmG09fhNnNdRU OaAqq2YSvjA4+tVHuZFzJfq6VSSnLwdTtk7HP+Ao5s7sByg6Dx4q/I35gYcjLojvzymr auwx2wmkJdrvXYAm560a9jiQAortLDkrVZHGYlrRRO+PkeIk0NwnIFXUFgREt/c+E0LA DpSw== X-Received: by 10.194.20.65 with SMTP id l1mr8681106wje.39.1397038667798; Wed, 09 Apr 2014 03:17:47 -0700 (PDT) X-Gm-Message-State: ALoCoQljqv0nLsnJopLJbdBM5updQA+VmIOGbC7MNi4BsX8cJOaljfT54/L8Cv2WSCf0H4dXTPq3rwRnLawE2an4x8BQHLdbcvJR37b2R+hQewvTQZgautAbrg57z8bdvfm932CSnKmVmg4i8D8QKJZ4mssGWxxoqQ== X-Received: by 10.194.20.65 with SMTP id l1mr8681097wje.39.1397038667722; Wed, 09 Apr 2014 03:17:47 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id hp5sm962018wjb.0.2014.04.09.03.17.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Apr 2014 03:17:47 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6) with ESMTP id s39AHjaG024516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Apr 2014 11:17:45 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6/Submit) id s39AHjhO024515; Wed, 9 Apr 2014 11:17:45 +0100 (BST) (envelope-from mexas) Date: Wed, 9 Apr 2014 11:17:45 +0100 (BST) From: Anton Shterenlikht Message-Id: <201404091017.s39AHjhO024515@mech-cluster241.men.bris.ac.uk> To: Lena@lena.kiev.ua, mexas@bris.ac.uk Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl In-Reply-To: <20140409084809.GA2661@lena.kiev> Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:47:43 -0000 >From Lena@lena.kiev.ua Wed Apr 9 10:43:40 2014 > >Port mail/sendmail-sasl (sendmail+tls+sasl2-8.14.8) depends on the >openssl port. You need to upgrade the security/openssl port to >openssl-1.0.1_10 and restart sendmail. I didn't know about this route of having authenticated sendmail. It's not mentioned in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/SMTP-Auth.html Are you saying mail/sendmail-sasl implements exactly the same functionality as rebuilding the base OS sendmail, as mentioned in the handbook? Thanks Anton From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 12:36:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26B39586 for ; Wed, 9 Apr 2014 12:36:50 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA95C119D for ; Wed, 9 Apr 2014 12:36:49 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id ib6so1953584vcb.41 for ; Wed, 09 Apr 2014 05:36:49 -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 :content-transfer-encoding; bh=gxfSZI4tY99UQ0XprJvHuhWtL5EJS9JYOLkRroiipkY=; b=PyQjcb71A4Q4MhYOUwtamWHkm1gUp1Gqm5et18ytpdtExTFj0QUhjhQh9ag4RreMjM 0zMTlVPOqsesRWG1JJkr82NB+r/1T+zR5u0W4/ZAsyr45byLpygP+k67UnRJY2az3ZhZ fveA129Te9vZTcYuDRat8cFfKwYrV0+7HECwbEEJzn65OL/R02phFzyILTNFeJRad9N6 u86S9oOVS8g973oKNe9N2RrU7FBb7Dq0bjL/TgH2C2w4+H0y1L07Tf5DI53TVpA2W5fk HPJu/EqoS1jpTfMRGSga5OvGeQP0/ZBuZb7xVn1WUw9PJKod9ir7pDJ76f8X15HPqJv8 tK9g== MIME-Version: 1.0 X-Received: by 10.221.27.8 with SMTP id ro8mr329461vcb.30.1397047008973; Wed, 09 Apr 2014 05:36:48 -0700 (PDT) Received: by 10.221.39.130 with HTTP; Wed, 9 Apr 2014 05:36:48 -0700 (PDT) Date: Wed, 9 Apr 2014 13:36:48 +0100 Message-ID: Subject: Proposal (Was: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl) From: Pawel Biernacki To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 12:36:50 -0000 On 9 April 2014 00:34, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > FreeBSD-SA-14:06.openssl Security Advi= sory > The FreeBSD Pro= ject > > Topic: OpenSSL multiple vulnerabilities > > Category: contrib > Module: openssl > Announced: 2014-04-08 > Affects: All supported versions of FreeBSD. > Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) > 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) > 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) > 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) > 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) > 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) > 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) > 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) > CVE Name: CVE-2014-0076, CVE-2014-0160 > Thank you for finally patching that vulnerability. Many of us, FreeBSD users, are deeply concerned about security. Yesterday we had a very busy day on #FreeBSD on freenode with many people asking why there is no SA and how to mitigate the thread or patch it on their own. I understand that this is voluntary role and you have another (real life) responsibilities that=E2=80=99s why I'd like to propose an idea of (a= t least partially) paid position of Security Officer, because we all need quick and efficient response in cases like that. FreeBSD Community has a good history of paying for work, many of us supported phk@ in 2004, and recently FreeBSD Foundation hired several people to work for all of us. Because I've no idea how Foundation had planned a budget for this year, I don't know if there are any money that can be allocated for that position. If not, maybe Foundation can conduct additional public fundraising for that purpose? --=20 One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die= . From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 13:25:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D11455C1 for ; Wed, 9 Apr 2014 13:25:10 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 953C41749 for ; Wed, 9 Apr 2014 13:25:10 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5AC2361DE; Wed, 9 Apr 2014 13:25:04 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 854781D0; Wed, 9 Apr 2014 15:25:04 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Biernacki Subject: Re: Proposal References: Date: Wed, 09 Apr 2014 15:25:04 +0200 In-Reply-To: (Pawel Biernacki's message of "Wed, 9 Apr 2014 13:36:48 +0100") Message-ID: <86fvlm7hzj.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:25:10 -0000 Pawel Biernacki writes: > I understand that this is voluntary role and you have another (real > life) responsibilities that=E2=80=99s why I'd like to propose an idea of = (at > least partially) paid position of Security Officer, because we all > need quick and efficient response in cases like that. Having a paid Security Officer would not have made any difference. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 13:57:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AF305A0 for ; Wed, 9 Apr 2014 13:57:52 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CA4221A8B for ; Wed, 9 Apr 2014 13:57:51 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s39DvX3l044864 for ; Wed, 9 Apr 2014 08:57:36 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Wed Apr 9 08:57:36 2014 Message-ID: <534551C8.6030004@denninger.net> Date: Wed, 09 Apr 2014 08:57:28 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: <86fvlm7hzj.fsf@nine.des.no> In-Reply-To: <86fvlm7hzj.fsf@nine.des.no> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000205080804010404050700" X-Antivirus: avast! (VPS 140409-0, 04/09/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:57:52 -0000 This is a cryptographically signed message in MIME format. --------------ms000205080804010404050700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/9/2014 8:25 AM, Dag-Erling Sm=C3=B8rgrav wrote: > Pawel Biernacki writes: >> I understand that this is voluntary role and you have another (real >> life) responsibilities that=E2=80=99s why I'd like to propose an idea = of (at >> least partially) paid position of Security Officer, because we all >> need quick and efficient response in cases like that. > Having a paid Security Officer would not have made any difference. > > DES Agreed. In this particular case FreeBSD's team responded very quickly once the=20 threat was known and a resolution path was made available in a very=20 expeditious fashion. The real problem here is the depth of damage and the amount of work to=20 rectify it, particularly for those who have certificates issued by=20 someone else where **they** may have been compromised. But this has=20 nothing to do with FreeBSD. --=20 -- Karl karl@denninger.net --------------ms000205080804010404050700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDkxMzU3MjhaMCMGCSqGSIb3DQEJBDEW BBSxveNKfwxVRppSMFYbT/inATJKzTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAV5E/QM9AyDm0pa0aWhdEUV//0nu9 MfD+LTF+IMDAsjpGF5ut2rofmfNQMM+LWGlKqG49X9SM59QVa6xgF9/JTYFiedGnPswaWRe/ A1lNgW94H3gtw/AxdOXazf1gz5PgTyDdNMMxp3tfLPD75+euDiSaBsnDIrFNTB5ufiZ7LVZV a3qwjrLdf2gNp3vbRH1xlF9yTW+FbtinkYO5UncNUzxziaskueQo6Q+6cSt+U1nwIacJKxAz pPwwkB0AIsC3lwBnNyedyhRC6P+LLd2KX7ZdxxG0PgcflloMrMQOwv9uHNHAMV5wLY1m9t4z LFdKyXlDJ/qQDuziB6jDx+CHexVgW3496X4JyA39FbIYDhs6wNflxi34xBryffv6gPL4Yhve S1JGCeQkbxGeoCXzZzZDVed8D7JAoW0QVrfx/F5fYW6tIpfsd7t2ESl94mx54dxW5r1QrNgG 4AeWQ0j81IyQpvfxZW9srlJpPxL1yjPFTXLHgdxygnrUql33K9wseFq/cQlwebU4m+4nPyI9 1zFKMja/BKEcfTLAJZcAL7TwhixML7xO4hKJj/OOtxckT9lTPb735kE0U/SJOs0W7bCabEIc 3w84DNq4y5wC8fRpwcfyn4KJtTPqqzCn/cgkkGDC0fOC/pyGQFGRWWPIC5z2P7NNFsQ2sxeK EbSnb/EAAAAAAAA= --------------ms000205080804010404050700-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 14:23:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 712C1711 for ; Wed, 9 Apr 2014 14:23:51 +0000 (UTC) Received: from mproxy20.sbb.rs (mproxy20.sbb.rs [89.216.2.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.sbb.rs", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8EAC1D80 for ; Wed, 9 Apr 2014 14:23:50 +0000 (UTC) Received: from faust.localdomain (cable-178-148-113-18.dynamic.sbb.rs [178.148.113.18]) by mproxy20.sbb.rs (8.14.4/8.14.4) with ESMTP id s39ENR9r028222 for ; Wed, 9 Apr 2014 16:23:32 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id E61ECA41C65; Wed, 9 Apr 2014 16:21:36 +0200 (CEST) Date: Wed, 9 Apr 2014 16:21:36 +0200 From: Zoran Kolic To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Message-ID: <20140409142136.GA871@faust.sbb.rs> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy20.sbb.rs X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:23:51 -0000 Advisory claims 10.0 only to be affected. Patches to branch 9 are not of importance on the same level? Zoran From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 14:26:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03F5B825 for ; Wed, 9 Apr 2014 14:26:06 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A195D1DAD for ; Wed, 9 Apr 2014 14:26:05 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s39EQ4mb053697 for ; Wed, 9 Apr 2014 09:26:04 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Wed Apr 9 09:26:04 2014 Message-ID: <53455877.5020006@denninger.net> Date: Wed, 09 Apr 2014 09:25:59 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl References: <20140409142136.GA871@faust.sbb.rs> In-Reply-To: <20140409142136.GA871@faust.sbb.rs> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010102060508010409090103" X-Antivirus: avast! (VPS 140409-0, 04/09/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:26:06 -0000 This is a cryptographically signed message in MIME format. --------------ms010102060508010409090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 4/9/2014 9:21 AM, Zoran Kolic wrote: > Advisory claims 10.0 only to be affected. Patches to > branch 9 are not of importance on the same level? > > Zoran > 9 (and before) were only impacted if you loaded the newer OpenSSL from=20 ports. A fair number of people did, however, as a means of preventing=20 BEAST attack vectors. If you did, then you need to update that and have all your private keys=20 re-issued. If you did not then you never had the buggy code in the=20 first place. --=20 -- Karl karl@denninger.net --------------ms010102060508010409090103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDkxNDI1NTlaMCMGCSqGSIb3DQEJBDEW BBQwCRfdJUx+HpOQSkdCSYDNCM9c8jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAS+js1Gl97p52KDjurbB++2IKaaXu Cqu37A1U8loOhEU9dn9EhIsO2NOLTDaVQv1ZH0IYT4dBdWYTexCkRbOjjySMQKK9whf3mmMS AYwVTqDgm8kMvqasvxgKX2q2I0kPJ1EnbiwmxzTm1LWdOn9I5Au0QnR1U7uJs53jTbpKx51+ VxFhV65tucV0+WWfH7bag7UT29BBYjX2lsm2HGrPO5CR51I/61dbfctynqVEXv8XFKdDtFbC ecaowUSkCFI/47cX6Vmu10CLbEMGVnqFa55/pRaQaQ9HBzwboT08JMrN1akPea8NZRzlGHp1 WflbN8lbXdKuiNoIyUWSfFturEafUbIHFCFPmW2155t5YDYkVQDl6OkNaMcizeCyQ8PWIWeb uxbCiE/f0AQZpaNx/Ln0wZITHbf+r83ZFErVcjZahjW5TnYCu+YlbSEpzrL7lJgmwW5wg1Ax VuauI8S/8oLsSlRFbWHK869Yksb9c4gU7kC2mH9O+3T3PWJIvZkF9frqPXOCOf6sCYsQM/UW S9dYZTQjVSBVL14PaohSgbxiZ/o/K/RP3XlGm8L6XR5mkSIn8oiEzAE1evYqrRVmR6t2NClC KjA7rkZRx2AZ0dd9l1EptCblGS8G9wQHLJw005gIocDfhp8HF6o2f8F/EkHEHrVKqGXsRmaF 6WUpvPwAAAAAAAA= --------------ms010102060508010409090103-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 14:36:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C401CB4 for ; Wed, 9 Apr 2014 14:36:58 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id 101771FF8 for ; Wed, 9 Apr 2014 14:36:57 +0000 (UTC) MIME-version: 1.0 Received: from st11p09mm-spool002.mac.com ([17.164.24.93]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0N3R00M53N4SGJ40@st11p09mm-asmtp001.mac.com> for freebsd-security@freebsd.org; Wed, 09 Apr 2014 13:36:29 +0000 (GMT) Received: from localhost ([17.164.24.65]) by st11p09mm-spool002.mac.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N3R0018DN4S1G50@st11p09mm-spool002.mac.com>; Wed, 09 Apr 2014 13:36:28 +0000 (GMT) To: Pawel Biernacki From: Kimmo Paasiala Subject: Re: Proposal Date: Wed, 09 Apr 2014 13:36:28 +0000 (GMT) X-Mailer: iCloud MailClient14B.126622 MailServer14B.15638 X-Originating-IP: [88.195.128.33] Message-id: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> In-reply-to: <86fvlm7hzj.fsf@nine.des.no> x-icloud-spam-score: 34444444 f=icloud.com; e=icloud.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHhEKTEMXGx0EGx0YBBIZBBsTEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hueREKQ04XSxseGmJCH2lsHm5uGXhzB xkTGxkZHH5pEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxMQGx4aHxsRCl5ZF2FPXGw eEQpMRhdua2sRCkNaFxsdBBscHgQYHgQTGREKQl4XGxEKRFgXGREKREkXGBEKQkUXZn1/E01vX GBlGhIRCkJOF2tFGlJQHkNcWVxoEQpCTBduTR15WWNkaH4YRhEKQmwXYUB8U2xLHxhke34RCkJ AF2JAYmdOemBlSBthEQpwaBdmSXlmbUhLSHt5QhEKcGgXYlhTYB4SH1JHARkRCnBoF2lSc0xhW VIbfGZHEQpwaBdjaX5PeE1raUgdXxEKcGgXYEd6HnpLfHNwbgERCnBsF21nbgUfYU5hHFsbEQp wTBdnYFJHc0RQX0cZZBEKcEMXaW1rXRtATWRNGGgR X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-09_02:2014-04-09,2014-04-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404090078 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: =?utf-8?B?IkRhZy1FcmxpbmcgU23DuHJncmF2Ig==?= , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:36:58 -0000 On Apr 09, 2014, at 03:25 PM, Dag-Erling Sm=C3=B8rgrav wrote:= =0A=0APawel Biernacki wri= tes:=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0> I understand that this is voluntary r= ole and you have another (real=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0> life) respo= nsibilities that=E2=80=99s why I'd like to propose an idea of (at=0A =C2=A0= =C2=A0 =C2=A0 =C2=A0> least partially) paid position of Security Officer,= because we all=0A =C2=A0 =C2=A0 =C2=A0 =C2=A0> need quick and efficient r= esponse in cases like that.=0A=0AHaving a paid Security Officer would not = have made any difference.=0A=0ADES=0A-- =0ADag-Erling Sm=C3=B8rgrav - des@= des.no=0A=C2=A0=0ACould everyone just please stop panicking and take an ob= jective look on this issue. It took only one full DAY to come up with a fi= x and issue the security advisory. That's damn fast if you look at some of= the commercial entities that face the exact same kind of issues and often= struggle to even acknowledge that there is a problem they need to address= and take sometimes weeks to release hotfixes.=0A=0AIn my opinion this iss= ue couldn't have been handled any better considering what it takes to do t= he job properly, congrats to the security team from me.=0A=0A-Kimmo= From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 14:44:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 999A3C1 for ; Wed, 9 Apr 2014 14:44:22 +0000 (UTC) Received: from mail.in-addr.com (noop.in-addr.com [208.58.23.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68F901107 for ; Wed, 9 Apr 2014 14:44:22 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WXtfA-00049Z-5s; Wed, 09 Apr 2014 10:39:40 -0400 Date: Wed, 9 Apr 2014 10:39:40 -0400 From: Gary Palmer To: Zoran Kolic Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Message-ID: <20140409143940.GA15884@in-addr.com> References: <20140409142136.GA871@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140409142136.GA871@faust.sbb.rs> 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 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:44:22 -0000 On Wed, Apr 09, 2014 at 04:21:36PM +0200, Zoran Kolic wrote: > Advisory claims 10.0 only to be affected. Patches to > branch 9 are not of importance on the same level? The version of OpenSSL shipped in the base FreeBSD code prior to 10.0 is not vulnerable to the Heartbeat attack, however there is a different vulnerability which *is* in 8.x and 9.x and was documented in the advisory as [CVE-2014-0076] You should update 8.x and 9.x systems also, even though the vulnerability there is probably not as easy to exploit as the Heartbeat attack. Regards, Gary From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 14:47:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C155A29C for ; Wed, 9 Apr 2014 14:47:40 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 848281135 for ; Wed, 9 Apr 2014 14:47:40 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 0BB5D20E7088B; Wed, 9 Apr 2014 14:47:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 6EC8B20E70885; Wed, 9 Apr 2014 14:47:28 +0000 (UTC) Message-ID: <8A7E8A9A8B034A3498601347FFFF088C@multiplay.co.uk> From: "Steven Hartland" To: "Karl Denninger" , References: <20140409142136.GA871@faust.sbb.rs> <53455877.5020006@denninger.net> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Date: Wed, 9 Apr 2014 15:47:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:47:40 -0000 ----- Original Message ----- From: "Karl Denninger" On 4/9/2014 9:21 AM, Zoran Kolic wrote: >> Advisory claims 10.0 only to be affected. Patches to >> branch 9 are not of importance on the same level? >> >> > 9 (and before) were only impacted if you loaded the newer OpenSSL from > ports. A fair number of people did, however, as a means of preventing > BEAST attack vectors. > > If you did, then you need to update that and have all your private keys > re-issued. If you did not then you never had the buggy code in the > first place. Actually they are vulnerable without any ports install just not to CVE-2014-0160 only CVE-2014-0076, both of which where fixed by SA-14:06.openssl Regards Steve From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 14:50:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B85B625 for ; Wed, 9 Apr 2014 14:50:32 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B16511AE for ; Wed, 9 Apr 2014 14:50:31 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.8/8.14.8) with ESMTP id s39EoUer061403 for ; Wed, 9 Apr 2014 09:50:30 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Wed Apr 9 09:50:30 2014 Message-ID: <53455E31.90100@denninger.net> Date: Wed, 09 Apr 2014 09:50:25 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Steven Hartland , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl References: <20140409142136.GA871@faust.sbb.rs> <53455877.5020006@denninger.net> <8A7E8A9A8B034A3498601347FFFF088C@multiplay.co.uk> In-Reply-To: <8A7E8A9A8B034A3498601347FFFF088C@multiplay.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090108010701060802090401" X-Antivirus: avast! (VPS 140409-0, 04/09/2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 14:50:32 -0000 This is a cryptographically signed message in MIME format. --------------ms090108010701060802090401 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 4/9/2014 9:47 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Karl Denninger" > > > > On 4/9/2014 9:21 AM, Zoran Kolic wrote: >>> Advisory claims 10.0 only to be affected. Patches to >>> branch 9 are not of importance on the same level? >>> >>> >> 9 (and before) were only impacted if you loaded the newer OpenSSL=20 >> from ports. A fair number of people did, however, as a means of=20 >> preventing BEAST attack vectors. >> >> If you did, then you need to update that and have all your private=20 >> keys re-issued. If you did not then you never had the buggy code in=20 >> the first place. > > Actually they are vulnerable without any ports install just not to > CVE-2014-0160 only CVE-2014-0076, both of which where fixed by > SA-14:06.openssl > > Regards > Steve Good point -- there is that other advisory in there so "base" 8.x and=20 9.x users should update as well. However, the other problem does not involve the same sort of=20 vulnerability to remote "grabs" of data, including authentication=20 credentials (and worse, private key data.) --=20 -- Karl karl@denninger.net --------------ms090108010701060802090401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0MDkxNDUwMjVaMCMGCSqGSIb3DQEJBDEW BBTRi1AH6NVk66/8t3lSJdO8GnofyjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIASOBI1388yBC9nrgdwhImRfzKSqsN OSg631O/2TOdH8/fRNqUBAPa5TzUPoTVwI6wIo64MWVagKhIF+WFVwNF76Di2e1/Uaglz6Kw VdnCX4icye1mT712DRBIuFL7hiRaYS335nJt07HJiwgcfR7nYYiBf4SkJAhLsF5b/hfEOPKE 2PQrcw1o6cX642BnpsdialzF3Imw9FvHJPuJlsSLmBPDn3BYQ4C6PKl0IKMY10iYoBloQ4LK 0hl0n136adEtQW5kf1V7rcq1bbYkVpwjTsfeyGiTd0Et1Bbu3cLbZw3gEjtT5aRNvHZ4+vjK lp29UTzW7cDm2ujx3fqTNqjAaHxnDbV7twlN+RMrwNtjA+qTUQ94Q34m1BpWoGg6W07onsf0 x//l5FCA38oiV2k20dvP09hBsyWisdFF0sC1DnkH7bgvTY6Iyp4ela9Mm4NECWzQA6aGHXnF 6QZi564QrA98XDs8+o0MHp2d1Ht+rgYR5LveWEMmGT40FfQ9GB1hA1k5tbUym3Qksepj/lry 9EpXgvxhMlk2m5qBo9YpRGfln3Gp0FqMD7jxDs8t7CjKyqj0QotDxWii8rWgA4g9J2+2rThU btSVDNBvrMbiCdq+EYVEZvM3mF9WUxbYZMncKLTUEDHrvcOYDGv3erYQQoDNu1HtL+WGUkjo G16hy5IAAAAAAAA= --------------ms090108010701060802090401-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 13:57:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46B5C58B for ; Wed, 9 Apr 2014 13:57:10 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 012991A83 for ; Wed, 9 Apr 2014 13:57:09 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id a108so2358598qge.31 for ; Wed, 09 Apr 2014 06:57:09 -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=O1SDtEPP7pqGnx/zjKA+GLvh+mkFitnbsejdLQ6YWyY=; b=Rnk5lhoUDkaAkq+41kRzuVJpAWIiJzOEWbtk8ZHEBdMBsiQn/HOof7RAdHoIqYAIlM BfETPbY+0BCdRs8P5KoJUY49DurLYHfZAXmOc/9Fw/2QxWRLIIOyU6hLY15VnT9q6lOt 6cUA3KH9yuvx69rRe9MUYY5sZTXvtEJjFsxdZR5Id0FyO/byEq2IrmDrE/UO/ovXEvWQ CMVWdHUPHlBh7SCW7NBAi/AyRuTPyhwsNsx1jOcljJgw0NoRUAqbezanblImMfMleP4R cooJqXEJK/jPK+zck9OrUyI6nMUZ7d5tzB2FYCUkFN4PRj/0VEt0dSvlzZPWLTwuKFfs W9ig== MIME-Version: 1.0 X-Received: by 10.224.169.5 with SMTP id w5mr2676892qay.96.1397051829169; Wed, 09 Apr 2014 06:57:09 -0700 (PDT) Received: by 10.229.126.133 with HTTP; Wed, 9 Apr 2014 06:57:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Apr 2014 15:57:09 +0200 Message-ID: Subject: Re: Proposal (Was: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl) From: Big Lebowski To: freebsd-security@freebsd.org X-Mailman-Approved-At: Wed, 09 Apr 2014 15:20:28 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:57:10 -0000 > >* I understand that this is voluntary role and you have another (real *> >* life) responsibilities that=E2=80=99s why I'd like to propose an idea= of (at *> >* least partially) paid position of Security Officer, because we all *> >* need quick and efficient response in cases like that. *> > Having a paid Security Officer would not have made any difference. Do you care to elaborate on why it would not made any difference? And, if possible, also on what could do one, if you have any ideas about that? I have to say that I agree with Pawe=C5=82 fully, I would love to see such things being handled a way faster and to be better communicated, if they're 'on they way' and I also belive having paid Security Office could help - but I am happy to get to know why I might be under wrong impression. I also doesnt know if there's any chance of directing any monye from this year's budget towards improving that situation, but I also like the idea of 'targeted' funding, where people gets a chance to say where they want the money to be used, some sort of money democracy, I would say. Regards, Bl From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 15:22:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 003E5526 for ; Wed, 9 Apr 2014 15:22:57 +0000 (UTC) Received: from tau.lfms.nl (tau.lfms.nl [93.189.130.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8257B161F for ; Wed, 9 Apr 2014 15:22:57 +0000 (UTC) Received: from sim.dt.lfms.nl (dt.lfms.nl [83.84.125.148]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tau.lfms.nl (Postfix) with ESMTPS id 5FA8DFCD01; Wed, 9 Apr 2014 17:17:37 +0200 (CEST) Received: from [IPv6:2001:1af8:fe00:8414:12dd:b1ff:febe:7594] (borax.dt.lfms.nl [IPv6:2001:1af8:fe00:8414:12dd:b1ff:febe:7594]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sim.dt.lfms.nl (Postfix) with ESMTPS id D71299C09084; Wed, 9 Apr 2014 17:17:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Proposal From: Walter Hop In-Reply-To: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> Date: Wed, 9 Apr 2014 17:17:37 +0200 Message-Id: <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> To: Kimmo Paasiala X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:22:58 -0000 > In my opinion this issue couldn't have been handled any better = considering what it takes to do the job properly, congrats to the = security team from me. >=20 > -Kimmo Please don=92t frame this as criticism of the security people, that=92s = not fair. Of course we all congratulate them :) I think we=92re just interested in discussing what could be improved to = improve response time and also make their lives better. Do we need moar Jenkins? Extra build boxes? More cash to keep people on = retainer? Resources for training new people? Liaisons with other = projects to improve prior notification channels? Etc. FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their = base about an hour later, FreeBSD base took around 24 hours. Not super = bad, but I think it=92s safe to expect much more scrutiny of = security-critical code in the coming years, so it looks like a good time = to try to streamline if possible at all. The public attention for this and similar events may also provide a = unique window of opportunity for soliciting extra resources from = professional users (e.g. via a Foundation campaign). --=20 Walter Hop | PGP key: https://lifeforms.nl/pgp From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 15:29:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 868E78D0 for ; Wed, 9 Apr 2014 15:29:16 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13D4416B0 for ; Wed, 9 Apr 2014 15:29:15 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id ec20so1251345lab.25 for ; Wed, 09 Apr 2014 08:29:13 -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=wYPykbNsq/pQeG1V0cYrp8fBGFbE7RZvUsAyhfF5hsI=; b=Z2yLKBeQEWBgkpgAsdY1Iikla4rtj0LUSqjaORj0thhvTLyPmirurF/gbOTwN3XOhJ ZaVwpWfUm9c0zZd+nDveYFuiXrq26OUbr760ifoz789rTp+hAHTpc1SMOTQF3STNSXt0 NI9bz9VMuucYqrMOMcQTqw8tTSmnC+W/9dkhM6occU0PF5csrVF0LmLY+mKkt/w/qX48 VBF2VP0S5NhAPCJn/AjbW7xlVdEVFV4R9f5Uc4Y3t7reHL1udcnQz245BBKETR6XN7rE V7xIeybp3XhIslpmedtwBeogBJs6e9PZ/0in9+4iEr/cLWla6uGYL1dZ69cxSeM0ctbe PgiQ== MIME-Version: 1.0 X-Received: by 10.112.134.230 with SMTP id pn6mr7510691lbb.37.1397057353858; Wed, 09 Apr 2014 08:29:13 -0700 (PDT) Received: by 10.112.77.102 with HTTP; Wed, 9 Apr 2014 08:29:13 -0700 (PDT) Date: Wed, 9 Apr 2014 16:29:13 +0100 Message-ID: Subject: Re: Proposal From: Pawel Biernacki To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:29:16 -0000 On 9 April 2014 15:32, Kimmo Paasiala wrote: > Can you name some of those projects that claim to have such quick response > time? I'll be steering way clear of them knowing that they don't test their > security patches before releasing them. It's really quite shocking to see > that such unprofessional working attitude has taken so firm hold in the open > source world. What a pity. RedHat managed to provide the fix within 21 hours but aparently they knew very eraly about the issue. FreeBSD Security Team didn't? Why? You can _see_ the whole process on their bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1084875. On the other hand Xin Li acknowledged the issue answering to an mail to freebsd-security@ on Monday at 21:02 UTC and then after 21 hours of _silence_ the fix was commited. They managed to release the fix 15 hours before FreeBSD and I assume they test thing before release because beside Fedora and Centos they also have paying customers. Debian acknowledged the problem in the same time as FreeBSD according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883 but they released fix very very quickly. Ports got the fix very quickly as well. Maybe it'll surprise you but there are still people using FreeBSD. What we are supposed to do when so@ is silent while scripts exploting the issue are in the wild? We need more transparency here. -- One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 15:44:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B89F9D37 for ; Wed, 9 Apr 2014 15:44:52 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 7D73918D0 for ; Wed, 9 Apr 2014 15:44:52 +0000 (UTC) Received: from [172.21.87.41] (195.98.9.212.in-addr.arpa [212.9.98.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3g3qPM6Hx7z7rBZ for ; Wed, 9 Apr 2014 15:37:43 +0000 (UTC) Message-ID: <53456946.9030200@rewt.org.uk> Date: Wed, 09 Apr 2014 16:37:42 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> In-Reply-To: <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 15:44:52 -0000 On 09/04/2014 16:17, Walter Hop wrote: >> In my opinion this issue couldn't have been handled any better considering what it takes to do the job properly, congrats to the security team from me. >> >> -Kimmo > > Please don’t frame this as criticism of the security people, that’s not fair. Of course we all congratulate them :) > > I think we’re just interested in discussing what could be improved to improve response time and also make their lives better. > > Do we need moar Jenkins? Extra build boxes? More cash to keep people on retainer? Resources for training new people? Liaisons with other projects to improve prior notification channels? Etc. > > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their base about an hour later, FreeBSD base took around 24 hours. Not super bad, but I think it’s safe to expect much more scrutiny of security-critical code in the coming years, so it looks like a good time to try to streamline if possible at all. > > The public attention for this and similar events may also provide a unique window of opportunity for soliciting extra resources from professional users (e.g. via a Foundation campaign). > 24 hours for a fix that doesn't break ABI and is relatively simple (and proven to be fine by other distros) is horrendous for such a critical problem. I mentioned this on twitter also, but there wasn't even a headsup from the SO until the patch went live. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 16:16:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88E3AB7C for ; Wed, 9 Apr 2014 16:16:40 +0000 (UTC) Received: from mail.rootservice.org (devgate.rootservice.org [144.76.199.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 475151CD2 for ; Wed, 9 Apr 2014 16:16:39 +0000 (UTC) Received: from devnoip.rootservice.org (devnoip.rootservice.org [46.59.210.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rootservice.org (Postfix) with ESMTPSA id 3g3r556WSczdG4C for ; Wed, 9 Apr 2014 18:08:40 +0200 (CEST) Date: Wed, 09 Apr 2014 18:08:31 +0200 From: Joe User Organization: RootService MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-Id: <3g3r546WVbz62Xv@devnoip.rootservice.org> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: joeuser@rootservice.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:16:40 -0000 On 09.04.2014 17:29, Pawel Biernacki wrote: > [snip] > We need more transparency here. > Please read this and other related threads and you'll understand that the FreeBSD-SecTeam had no real chance to react earlier than they did. http://seclists.org/oss-sec/2014/q2/22 In fact, they were realy fast, thanks therefor. Regards, Joe User From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 16:28:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9494C9 for ; Wed, 9 Apr 2014 16:28:47 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70F411E3D for ; Wed, 9 Apr 2014 16:28:47 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i7so2982046oag.5 for ; Wed, 09 Apr 2014 09:28:46 -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:content-transfer-encoding; bh=wjnqBWoth3APevka3FLXsGYF2YGemsKa+nXkojvLITY=; b=pXuJNhH/Kl2/87wFdlAd9XHufgdHcSjfVphAAAfZke2hPuVfmeBA9w5pVShW+/PmQd tu4Xob3n5RMdjPDAmDoeM+PiPgW13YuZYx0CuO3sJqN6lHoRDZXUClV27ScLNmt89bxS ZaXh+B+dcIx4TfZSSA5/PMm9qw8HZOXRtf0rEXtdKI/GEdkrDBdPhjGZvDATDyZnhBRq 6MjFWzGPHiJ0RKgJpeFeCH7C9WJ+0ZRf39BF3rbQ4fsMdZtH74aZjRPLm/GXDirkSSBA 0TvQnBv+kGCPQpIpbO7JPnDqJL25kI/eCdauzoRP7RlfzTMboZ9SnPRcCW1S4NUx+9df Uepg== MIME-Version: 1.0 X-Received: by 10.182.85.193 with SMTP id j1mr2836326obz.52.1397060926768; Wed, 09 Apr 2014 09:28:46 -0700 (PDT) Received: by 10.182.123.17 with HTTP; Wed, 9 Apr 2014 09:28:46 -0700 (PDT) In-Reply-To: <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> Date: Wed, 9 Apr 2014 09:28:46 -0700 Message-ID: Subject: Re: Proposal From: jungleboogie0 To: Walter Hop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Pawel Biernacki , Kimmo Paasiala , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:28:47 -0000 Hi Walter, On 9 April 2014 08:17, Walter Hop wrote: >> In my opinion this issue couldn't have been handled any better consideri= ng what it takes to do the job properly, congrats to the security team from= me. >> >> -Kimmo > > Please don=E2=80=99t frame this as criticism of the security people, that= =E2=80=99s not fair. Of course we all congratulate them :) > > I think we=E2=80=99re just interested in discussing what could be improve= d to improve response time and also make their lives better. > > Do we need moar Jenkins? Extra build boxes? More cash to keep people on r= etainer? Resources for training new people? Liaisons with other projects to= improve prior notification channels? Etc. > > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their base= about an hour later, FreeBSD base took around 24 hours. Not super bad, but= I think it=E2=80=99s safe to expect much more scrutiny of security-critica= l code in the coming years, so it looks like a good time to try to streamli= ne if possible at all. > Please let us not forget that kernel.org was hacked and not detected for 17 days: http://www.theregister.co.uk/2011/08/31/linux_kernel_security_= breach/ I would rather was 24 hours for a fix that's been verified and reviewed over having to re-update the system. It looks like many linux distros had this updated before freeBSD but its a matter of hours we're talking about. > The public attention for this and similar events may also provide a uniqu= e window of opportunity for soliciting extra resources from professional us= ers (e.g. via a Foundation campaign). > > -- > Walter Hop | PGP key: https://lifeforms.nl/pgp > --=20 ------- inum: 883510009902611 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 16:18:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F0E3CB8 for ; Wed, 9 Apr 2014 16:18:22 +0000 (UTC) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D02F1D01 for ; Wed, 9 Apr 2014 16:18:21 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id w7so2950490qcr.25 for ; Wed, 09 Apr 2014 09:18:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=Pg+ilB26NyDvyOQnMfSpI2VuQB6KDfNZQy1pNanhgOQ=; b=E1jOSi8nv8sw6TMmCF6FdoEFTUNmK7VeXs/9FVHTiO7M+LKCuyEnc3Nsz7KXFvcZqj DA+hMQQ4ZAxt4egPb1xbSLtmojTrLXoP1amPCPHxo7cu0uSCJFvSWvUngkS5lat7JVqZ s35AKkh6Pc7tNz19jH64cZA6Qs99OVVMm6vTPSQ21uPE2bj4bopC9BdLRvfM57/1afUX ySanTef62enGLKM+UsJzPDXU5JVYaUlcFUD/nheAQEbYNb+gLzNfhlVgADn7riwwkJU+ 1eIbABxWFOEs9YFj6a5AxXOnnra/3m6muigi8RkKBd6u8cdsHCsn6VO+Owifz8moYPGl N5Bw== X-Gm-Message-State: ALoCoQlsmp3gA3MoV1pG1fsy5CX6e6iOIaHQOkTu6MwmhF1Wtp/ACuXjhRycxXfFumPffFvntqQu X-Received: by 10.224.39.20 with SMTP id d20mr13490927qae.21.1397058888680; Wed, 09 Apr 2014 08:54:48 -0700 (PDT) MIME-Version: 1.0 Sender: edelkind@episec.com Received: by 10.140.92.167 with HTTP; Wed, 9 Apr 2014 08:54:28 -0700 (PDT) X-Originating-IP: [38.122.12.254] In-Reply-To: <53456946.9030200@rewt.org.uk> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <53456946.9030200@rewt.org.uk> From: ari edelkind Date: Wed, 9 Apr 2014 11:54:28 -0400 X-Google-Sender-Auth: TjYMQDHIgVEoFW7BhLo_iKTvt3I Message-ID: Subject: Re: Proposal To: freebsd-security@freebsd.org X-Mailman-Approved-At: Wed, 09 Apr 2014 16:42:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:18:22 -0000 On Wed, Apr 9, 2014 at 11:37 AM, Joe Holden wrote: > 24 hours for a fix that doesn't break ABI and is relatively simple (and > proven to be fine by other distros) is horrendous for such a critical > problem. I mentioned this on twitter also, but there wasn't even a headsup > from the SO until the patch went live. > To give this some additional perspective, it took me approximately 30 minutes to write a working exploit. Everyone makes a big deal out of private keys (which, admittedly, are a big deal), but i was able to collect usernames, passwords, session credentials, back-end single-sign-on credentials (e.g. client tokens), database passwords, and more from affected hosts -- all quite easily. ari From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 17:28:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDE12ACB for ; Wed, 9 Apr 2014 17:28:54 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA8515BB for ; Wed, 9 Apr 2014 17:28:54 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5E8706F01; Wed, 9 Apr 2014 17:28:53 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A58EA3E3; Wed, 9 Apr 2014 19:28:53 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Walter Hop Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> Date: Wed, 09 Apr 2014 19:28:53 +0200 In-Reply-To: <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> (Walter Hop's message of "Wed, 9 Apr 2014 17:17:37 +0200") Message-ID: <867g6y1kfe.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, Kimmo Paasiala , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:28:54 -0000 Walter Hop writes: > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their > base about an hour later, FreeBSD base took around 24 hours. All Bryan had to do to update the port was change the version number in the Makefile, run "make makesum" and commit. I assume that he did some testing as well, but apart from that, he probably spent more time writing the commit message than actually updating the port. Ubuntu is much the same, since they distribute OpenSSL as a package rather than part of the base system - they don't even _have_ a base system. RedHat had prior notice since one of the OpenSSL devs is on their security team. They had an update ready to roll out before the issue was leaked (the builds are dated 2014-04-07 11:34:45 UTC), and were basically just waiting for the announcement, which was originally planned for today. To update OpenSSL in the FreeBSD base system, Xin first had to verify which FreeBSD releases were vulnerable and which weren't. He then had to obtain, verify, apply and test a patch for head, stable/10 and releng/10.0. Next, he had to upload the patch to the freebsd-update build servers and start the builds, which take several hours. Once the builds were done, he had to sign them and move them to the master server, from which they propagated to the mirrors, and then sign the release. Once the builds were ready to go, he moved into a phase where everything had to happen more or less simultaneously: commit the patches, finalize the advisory (which contains revision numbers and timestamps), sign it, then commit the advisory and the patch to the doc tree, update the relevant portions of the web site, wait for them to propagate (or grab a passing member of clusteradm@ and have them push it through manually), and finally mail out the advisory. Bonus points for updating vuln.xml and liaising with MITRE / CMU CERT / NVD / what have you. And yes, he has a whole team, but apart from writing the advisory (which is a lot more work than you'd think), this process is pretty much single-threaded. The best you can hope for is to have someone relieve you while you eat and sleep. And while everybody is running around yelling OMG THE INTERNET IS ON FIRE and calling this an unprecedented event, I'm sitting here with a strong sense of d=C3=A9ja vu, because this sort of thing actually happens quite often. Off the top of my head, I can think of two advisories last year - out of 14 - that were more or less rushed out in a panic. DES (so@ on sabbatical) --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 17:50:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D17855CC for ; Wed, 9 Apr 2014 17:50:34 +0000 (UTC) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D35F17D1 for ; Wed, 9 Apr 2014 17:50:34 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id sa20so2343564veb.22 for ; Wed, 09 Apr 2014 10:50:33 -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=guxkrpLJvQWgHaeG5Z+elpFXqf8QtEwf3ctS1stfh6U=; b=NX58biVRVarz30zH1Dt+VVmBRxPSnvt9esv3AcQ/jiTPT1EdK0NQmLe4XrjH6gKxGF 575AOOqr4odsbiVJ1jKrewQX/u5RFHgszWfjuB8AfKM1rfE/GmBAKnYAupRCXHwJ2gG2 NCZHdUZjX/sryCJLEuw6um73A6AlvydvYwlu5H02KqG3dhMVOUNNu0ZV9G6cQm0Z5xol 88DeWcJEGBrLBw+KxBgg80ZC1ezTrlG7c0msLxmzdAnwYP+atgdeJ0fs8+67GrVvaO9o InV3gRLVUcQS9+50eOOY9CdD0zKMYyskBR6VUfAxY8rSH0sLGiYsRZ+QOAi6Cbiw+PXK jJ6A== MIME-Version: 1.0 X-Received: by 10.58.181.170 with SMTP id dx10mr1941286vec.25.1397065833667; Wed, 09 Apr 2014 10:50:33 -0700 (PDT) Received: by 10.221.39.130 with HTTP; Wed, 9 Apr 2014 10:50:33 -0700 (PDT) In-Reply-To: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> Date: Wed, 9 Apr 2014 18:50:33 +0100 Message-ID: Subject: Re: Proposal From: Pawel Biernacki To: jungleboogie0 Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, Kimmo Paasiala , Walter Hop , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:50:34 -0000 On 9 April 2014 17:28, jungleboogie0 wrote: > > Please let us not forget that kernel.org was hacked and not detected > for 17 days: http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/ I don't know why you're bringing it up here, because FreeBSD had similar problem some time ago (http://www.freebsd.org/news/2012-compromise.html) and I think that we had learnt a lot from it. > I would rather was 24 hours for a fix that's been verified and > reviewed over having to re-update the system. It looks like many linux > distros had this updated before > freeBSD but its a matter of hours we're talking about. > -- One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 17:53:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1829572A for ; Wed, 9 Apr 2014 17:53:11 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CE915188D for ; Wed, 9 Apr 2014 17:53:10 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 0FCD16055; Wed, 9 Apr 2014 17:53:10 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 5762C40A; Wed, 9 Apr 2014 19:53:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Biernacki Subject: Re: Proposal References: Date: Wed, 09 Apr 2014 19:53:10 +0200 In-Reply-To: (Pawel Biernacki's message of "Wed, 9 Apr 2014 16:29:13 +0100") Message-ID: <86txa2z8xl.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:53:11 -0000 Pawel Biernacki writes: > RedHat managed to provide the fix within 21 hours but aparently they > knew very eraly about the issue. FreeBSD Security Team didn't? Why? > You can _see_ the whole process on their bugzilla > https://bugzilla.redhat.com/show_bug.cgi?id=3D1084875. No you can't. That ticket is just window dressing. By the time it was created, RedHat had known about the issue for at least a week, and probably more. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 18:00:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67FF9B4A for ; Wed, 9 Apr 2014 18:00:04 +0000 (UTC) Received: from mail.rootservice.org (devgate.rootservice.org [144.76.199.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26FFC1901 for ; Wed, 9 Apr 2014 18:00:03 +0000 (UTC) Received: from devnoip.rootservice.org (devnoip.rootservice.org [46.59.210.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rootservice.org (Postfix) with ESMTPSA id 3g3tYX65tqzdG50 for ; Wed, 9 Apr 2014 19:59:59 +0200 (CEST) Date: Wed, 09 Apr 2014 20:00:01 +0200 From: Joe User Organization: RootService MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: <86txa2z8xl.fsf@nine.des.no> In-Reply-To: <86txa2z8xl.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-Id: <3g3tYW2jPgz62Y0@devnoip.rootservice.org> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: joeuser@rootservice.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:00:04 -0000 On 09.04.2014 19:53, Dag-Erling SmĆørgrav wrote: > Pawel Biernacki writes: >> RedHat managed to provide the fix within 21 hours but aparently they >> knew very eraly about the issue. FreeBSD Security Team didn't? Why? >> You can _see_ the whole process on their bugzilla >> https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > > No you can't. That ticket is just window dressing. By the time it was > created, RedHat had known about the issue for at least a week, and > probably more. > > DES > According to Kurts Post on oss-sec RedHat didn't know it before others. Regards, Joe User From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 18:00:53 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F289C4A for ; Wed, 9 Apr 2014 18:00:53 +0000 (UTC) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FA38191F for ; Wed, 9 Apr 2014 18:00:53 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id oz11so2374673veb.6 for ; Wed, 09 Apr 2014 11:00:52 -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=mVdpKLIWULCHfF0A046PCRr5zuLYAhCcxSnYVhNEex0=; b=MtLReRv3z8u9d90WKl0Hyb/fBRo4VXQ0NQqH7QNEA5f5KRxgTrkEMSKoJ2jpoFgDn9 MdwscMrl7+YUjDTF9DmjEeZHS2UjGneeATLW1u4gzpOx4u4Dj5RFIQTzbouXNeoV780s eLYHf6qkX4I7n05wWQ7oVvZBrOwWhNy75zIvD600EurIDqQvalLU3crFMSAeyIFqKXOz DYOGPp5fOW1Og1waBDGU6qLz9G95X6uwPOcXqLZ3wNRO2VV4BluRpppQcfZ9N6efs6av BJxrlnx4SeQfPnqHYHp2bT9c9BrefZUyIkqk7KVOkBjN3BGCvtvjQw/YYv1iWaaQFKPp Ap8Q== MIME-Version: 1.0 X-Received: by 10.58.230.103 with SMTP id sx7mr1724754vec.28.1397066452528; Wed, 09 Apr 2014 11:00:52 -0700 (PDT) Received: by 10.221.39.130 with HTTP; Wed, 9 Apr 2014 11:00:52 -0700 (PDT) In-Reply-To: <3g3r546WVbz62Xv@devnoip.rootservice.org> References: <3g3r546WVbz62Xv@devnoip.rootservice.org> Date: Wed, 9 Apr 2014 19:00:52 +0100 Message-ID: Subject: Re: Proposal From: Pawel Biernacki To: joeuser@rootservice.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:00:53 -0000 On 9 April 2014 17:08, Joe User wrote: > On 09.04.2014 17:29, Pawel Biernacki wrote: >> [snip] >> We need more transparency here. >> > > Please read this and other related threads and you'll understand that > the FreeBSD-SecTeam had no real chance to react earlier than they did. > http://seclists.org/oss-sec/2014/q2/22 > > In fact, they were realy fast, thanks therefor. Interesting lecture, thank you. But if FreeBSD SO wasn't on the mentioned list it's an argument for payable position because that can help developing more efficient social network in the future ;-). -- One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 18:04:24 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDE0BFB1 for ; Wed, 9 Apr 2014 18:04:24 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 847B41A08 for ; Wed, 9 Apr 2014 18:04:24 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so3164322oag.35 for ; Wed, 09 Apr 2014 11:04:23 -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=VLHufwgr7/c+46PKCraWXzkxWhnrTBZsW0olLP0U5wc=; b=HZm/1R4PYhRJHVX4V4IT3hvy/lRMzqqYGs6kEEnXKrTCexFMDLIrztSZzNF1TTD8/A UTyrBA/2N2cEjoOhcW6d7CHgGrUgj51TvCjngn8/9gFN0kLYz5zBBo46vK/ZBaChfOYu 815buaQKOgKLigruLr4CiWBFbQ5FCR+W7diEjcZo9hlMOaWAzJSiprQnWvC+yfx/204w TjaVdpSQrQDghQ1DSYBY/WePGbx5DJ26CLFdSyoezrPNh8jeGpZBbAR02nQIxLP4PsOM QyRtKI/wrnc/TYtOyKY3X9ytUG7+0Qupy6M52T+pa6HOhD0UvO9YXch+cDtxzeagRuw6 0AfQ== MIME-Version: 1.0 X-Received: by 10.60.16.103 with SMTP id f7mr9892432oed.8.1397066663837; Wed, 09 Apr 2014 11:04:23 -0700 (PDT) Received: by 10.182.123.17 with HTTP; Wed, 9 Apr 2014 11:04:23 -0700 (PDT) In-Reply-To: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> Date: Wed, 9 Apr 2014 11:04:23 -0700 Message-ID: Subject: Re: Proposal From: jungleboogie0 To: Pawel Biernacki Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, Kimmo Paasiala , Walter Hop , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:04:24 -0000 Hi Pawel, On 9 April 2014 10:50, Pawel Biernacki wrote: > On 9 April 2014 17:28, jungleboogie0 wrote: >> >> Please let us not forget that kernel.org was hacked and not detected >> for 17 days: http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/ > > I don't know why you're bringing it up here, because FreeBSD had > similar problem some time ago > (http://www.freebsd.org/news/2012-compromise.html) and I think that we > had learnt a lot from it. > Interesting, I didn't know these were identical in nature. Thanks! >> I would rather was 24 hours for a fix that's been verified and >> reviewed over having to re-update the system. It looks like many linux >> distros had this updated before >> freeBSD but its a matter of hours we're talking about. >> > > -- > One of God's own prototypes. A high-powered mutant of some kind never > even considered for mass production. Too weird to live, and too rare to die. -- ------- inum: 883510009902611 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 18:15:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05C9F7FA for ; Wed, 9 Apr 2014 18:15:48 +0000 (UTC) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8BC41B68 for ; Wed, 9 Apr 2014 18:15:47 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id jw12so2379540veb.23 for ; Wed, 09 Apr 2014 11:15:46 -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:content-transfer-encoding; bh=QNLh+3sdXCrggWgoyDqLyqTfS3AkEFKUIRTcwHMPY6U=; b=vtKHxtuk5mtfNDElqXuwkGb7VdNqwu1JT7f8wB3BvYOmShrxvoThx4X/yEHGlpDdYh UyB8HdjZoRpievsraBGHy5W7/HbIZPmiPjoyTDryGnFJqY86ZzO1BoSyuNwTGoZ9Ja8f Hk6JSuJQvFktjogrHi+3U1O8MybMJs08/2J10KfsInmiCxwxAxYK9c1iurbjaqR1iF92 NZBX4d2aD1L/Vw7f0xiP75WCom1+WYdp0bXdYKE2CIF+ZquCv5g4DxbBLsXUquqU/WAW +1pv9qLjfk3E8qdbOFnFPSC8tbmr44x/iyqyJ/E2CNozNUuPSCasi8X6hJVmPVjHpXR7 rYeg== MIME-Version: 1.0 X-Received: by 10.220.12.66 with SMTP id w2mr9889537vcw.15.1397067346867; Wed, 09 Apr 2014 11:15:46 -0700 (PDT) Received: by 10.221.39.130 with HTTP; Wed, 9 Apr 2014 11:15:46 -0700 (PDT) In-Reply-To: <86txa2z8xl.fsf@nine.des.no> References: <86txa2z8xl.fsf@nine.des.no> Date: Wed, 9 Apr 2014 19:15:46 +0100 Message-ID: Subject: Re: Proposal From: Pawel Biernacki To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= 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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:15:48 -0000 On 9 April 2014 18:53, Dag-Erling Sm=C3=B8rgrav wrote: > Pawel Biernacki writes: >> RedHat managed to provide the fix within 21 hours but aparently they >> knew very eraly about the issue. FreeBSD Security Team didn't? Why? >> You can _see_ the whole process on their bugzilla >> https://bugzilla.redhat.com/show_bug.cgi?id=3D1084875. > > No you can't. That ticket is just window dressing. By the time it was > created, RedHat had known about the issue for at least a week, and > probably more. > According to http://seclists.org/oss-sec/2014/q2/36 RedHat learnt about it 7th March and after that the bugzilla entry was created. I assume that it was marked as private and unaccessible to other users for few hours until release of SA but at least he have some trace of what was done. --=20 One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die= . From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 18:41:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FF4EAFB for ; Wed, 9 Apr 2014 18:41:30 +0000 (UTC) Received: from mo3.mail-out.ovh.net (16.mo3.mail-out.ovh.net [188.165.56.217]) by mx1.freebsd.org (Postfix) with ESMTP id 4E4321F9C for ; Wed, 9 Apr 2014 18:41:30 +0000 (UTC) Received: from mail436.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id CDE73FFA63C for ; Wed, 9 Apr 2014 20:02:57 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 9 Apr 2014 20:05:03 +0200 Received: from vau75-5-82-227-220-138.fbx.proxad.net (HELO ?127.0.0.1?) (leon.fazakerley@commerceo.com@82.227.220.138) by ns0.ovh.net with SMTP; 9 Apr 2014 20:05:01 +0200 Message-ID: <53458B4F.5070908@tucoinfo.fr> Date: Wed, 09 Apr 2014 20:02:55 +0200 From: "leon@tuco" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Pawel Biernacki Subject: Re: Proposal References: <86txa2z8xl.fsf@nine.des.no> In-Reply-To: <86txa2z8xl.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 10073707943104224068 X-Ovh-Remote: 82.227.220.138 (vau75-5-82-227-220-138.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -80 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejuddrieehucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogetfedtledqtdduucdlvddtmd X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -80 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejuddrieehucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogetfedtledqtdduucdlvddtmd Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 18:41:30 -0000 On 09/04/2014 19:53, Dag-Erling SmĆørgrav wrote: > Pawel Biernacki writes: >> >RedHat managed to provide the fix within 21 hours but aparently they >> >knew very eraly about the issue. FreeBSD Security Team didn't? Why? >> >You can_see_ the whole process on their bugzilla >> >https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > No you can't. That ticket is just window dressing. By the time it was > created, RedHat had known about the issue for at least a week, and > probably more. Who cares, nobody found it in 2 years and we are squabbling about a few hours or days! I am much more worried about the late coming journalists who are starting to freak out any Internet credit card user. That is really bad for e-commerce - in addition to these depressing last years of financial crisis. Thank you for your efforts and I will definitely continue using FreeBSD. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 19:44:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABB65A7C for ; Wed, 9 Apr 2014 19:44:54 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 747281673 for ; Wed, 9 Apr 2014 19:44:54 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i7so3285881oag.5 for ; Wed, 09 Apr 2014 12:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gzANQIbQVzVOd5+UX9y7fosZpj/BfEX5Rfvec9TxM1Y=; b=a0llC/JxKKJXUCinKIRtrq417AhY9jI2zkmvzmwZwv5LgiTYU/+mVNCDuQk7+nA1YP i6ozdOHrC+1otT7V7/ROp4om8o9EXlqNSy+xEfAtjDcE7HHKSvvneJ17GdWmlSauy+Bk boE9g0LPqW7XhqpVojX2/nlnQTXRgmKLHK4ETru8LhrhMVy1Zs8gMYDI+IBwpkNb+8+I HRBUMVFEcfK6lqx5agPuI0pQbkYNJ9nR+wlTYRYmy96EQOzVT015vN3xVtRsugBnbdez a3i10nx6tG+7r/1gaBfZtmaiWPjFfh0hd7PgvGk0Zvl+RBBLp84eKizxNgSqmzziEFBu t9yw== MIME-Version: 1.0 X-Received: by 10.182.231.138 with SMTP id tg10mr10368968obc.44.1397072693806; Wed, 09 Apr 2014 12:44:53 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.60.158.106 with HTTP; Wed, 9 Apr 2014 12:44:53 -0700 (PDT) In-Reply-To: <867g6y1kfe.fsf@nine.des.no> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> Date: Wed, 9 Apr 2014 15:44:53 -0400 X-Google-Sender-Auth: 3EzQHX5pS9huxCmu33dMsOl13nU Message-ID: Subject: Re: Proposal From: Nathan Dorfman To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, Kimmo Paasiala , Walter Hop , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:44:54 -0000 First, the (unfortunately) necessary disclaimer: this is an honest question to satisfy my curiosity, nothing more. Absolutely no criticism of anyone is intended. Is it implausible to suggest that before embarking on the task of backporting, reviewing, testing and releasing the actual fix, an announcement could have been made immediately with the much simpler workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler flags? Given the severity of the issue, it doesn't seem that an immediate advisory stating "here's an immediate workaround, a full fix will be coming in the next day or two" would be terribly inappropriate. Perhaps this workaround would have required more testing than I imagine, but surely it'd be a tiny fraction of the time required to release the full fix? While I'm out here drawing fire, I might as well also ask if I'm crazy to think that it might be a good idea for the base system OpenSSL (and other third party imports) to just disable any and all non-essential functionality that can be disabled at compile time? Non-essential meaning everything not required for the base system to function -- there's always the ports version if anyone needs more. Thanks for your thoughts, and of course, your ongoing efforts. They are much appreciated. -nd. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 19:38:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E6A2938 for ; Wed, 9 Apr 2014 19:38:56 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CA85B15CE for ; Wed, 9 Apr 2014 19:38:55 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s39Jcm23027706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 9 Apr 2014 20:38:49 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s39Jcm23027706 Authentication-Results: smtp.infracaninophile.co.uk/s39Jcm23027706; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <5345A1BF.2030809@FreeBSD.org> Date: Wed, 09 Apr 2014 20:38:39 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> In-Reply-To: <867g6y1kfe.fsf@nine.des.no> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QqLsXPn8leRvonQn94suNIf2U9mhighSg" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-Mailman-Approved-At: Wed, 09 Apr 2014 19:54:25 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 19:38:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QqLsXPn8leRvonQn94suNIf2U9mhighSg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/04/2014 18:28, Dag-Erling Sm=C3=B8rgrav wrote: > RedHat had prior notice since one of the OpenSSL devs is on their > security team. They had an update ready to roll out before the issue > was leaked (the builds are dated 2014-04-07 11:34:45 UTC), and were > basically just waiting for the announcement, which was originally > planned for today. Didn't we (FreeBSD) have any advanced knowledge? There is at least one FreeBSD committer who is also an OpenSSL developer... Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --QqLsXPn8leRvonQn94suNIf2U9mhighSg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTRaHHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATXBIQAKEyyn3bZA6zBNeUwWYsvMqr n87XQiM5VsGan9/QUaQZ/M29sIFtB3Hd8DP1GZcShcjcWsan8dw5wSfx1O1qSLwU Rstsw7RsO9C/Uzhipeq8xQzmslRPqKwQdKJ6S2YVuhr+gEv823lH08GwfwL5iQHT HD1lknJgGgfpt/tkMq8IwjwFsKfNF0tyQ5w0gjFI7akLVO5iH185bUw8I5oO2/N1 AOm6m47moo97WBN2G1Caxcee+R9gnlLDaGkOTLlhdUJcTRimbO34f1fTba7djwY2 8fvHASKeR+Vm2wmwSRMWkogon0Dg8N6DGIJ8JshZ31zkxwApOj9LLGe55dAVXPSj nGZyA3Cmomwolj1ICMGWfG3tst334AOYNa3Zn79/NNVoSZuZzp81lYLH8oUuqNb6 X13yzA7F82rlKhhuLk5oG0e/gTDxUFhy84pJV7utFaAYOzphB0vqE3BT5yqo7f3l xfg6gDGfLBi9P1lzWNvz3YAE/2JYcFOBg40QctezE/C1sbXWaaxHsrBtfVpoZqxH 2LG/b9aTP7/cRV6l/5IUg3dVr9nKAhDPcZ51ZtSdc040UoVrKhrpeCyxxKz4G1GB xf27cqS4/n/6Nc9NUdsfF/J+j78R5ZFIt3w+v5zegEECXRk2XmnXObwjdYOLFsfY zk5HXTRlCJr28lWZufB9 =u2rw -----END PGP SIGNATURE----- --QqLsXPn8leRvonQn94suNIf2U9mhighSg-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 20:12:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F7387E0 for ; Wed, 9 Apr 2014 20:12:30 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E2A70196F for ; Wed, 9 Apr 2014 20:12:29 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E06136786; Wed, 9 Apr 2014 20:12:28 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 411AF4CC; Wed, 9 Apr 2014 22:12:29 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Dorfman Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> Date: Wed, 09 Apr 2014 22:12:29 +0200 In-Reply-To: (Nathan Dorfman's message of "Wed, 9 Apr 2014 15:44:53 -0400") Message-ID: <86d2gqz2he.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, Kimmo Paasiala , Walter Hop , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:12:30 -0000 Nathan Dorfman writes: > Is it implausible to suggest that before embarking on the task of > backporting, reviewing, testing and releasing the actual fix, an > announcement could have been made immediately with the much simpler > workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler > flags? No, that's not implausible, although I don't know whether that workaround was known at the time. It seems obvious in retrospect, but may not have been that obvious under pressure. Was it mentioned in the OpenSSL advisory? If all you wanted to hear was "we're working on it", well, Xin did write that almost on -security exactly 48 hours ago. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 20:13:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E74068D7 for ; Wed, 9 Apr 2014 20:13:23 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A4887198B for ; Wed, 9 Apr 2014 20:13:23 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id F14016792; Wed, 9 Apr 2014 20:13:22 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 4E9B14CF; Wed, 9 Apr 2014 22:13:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Dorfman Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> Date: Wed, 09 Apr 2014 22:13:23 +0200 In-Reply-To: <86d2gqz2he.fsf@nine.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8r?= =?utf-8?Q?grav=22's?= message of "Wed, 09 Apr 2014 22:12:29 +0200") Message-ID: <868urez2fw.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, Walter Hop , Kimmo Paasiala , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:13:24 -0000 Dag-Erling Sm=C3=B8rgrav writes: > If all you wanted to hear was "we're working on it", well, Xin did write > that almost on -security exactly 48 hours ago. s/that almost on -security/that on -security almost/ DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 20:20:43 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB048C84 for ; Wed, 9 Apr 2014 20:20:43 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E1161A7C for ; Wed, 9 Apr 2014 20:20:43 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id BD06F75CC; Wed, 9 Apr 2014 13:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397074843; bh=MnrEK9RRh0nQlnbm3BKH6tG3FR6/uMpV3+OIbIc2S/8=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=P6T0E/yz6wLVTE9BC02lA5Tb+pMHB8/0W0C5wPozsfO3cg7IsQmswNJ40SqIfX/hd CBSEXjBDZD4WNSAvip9C7EP80nVsv70cQrVx3z0tRJVVu+TRDQtxKUlyubFHBeWwOL mFZoWuAE4B/hwCxmDt+Xyn5vB+tLTds2+5Nk6fKo= Message-ID: <5345AB9A.8040001@delphij.net> Date: Wed, 09 Apr 2014 13:20:42 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Nathan Dorfman Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> In-Reply-To: <86d2gqz2he.fsf@nine.des.no> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, Walter Hop , Kimmo Paasiala , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:20:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/09/14 13:12, Dag-Erling SmĆørgrav wrote: > Nathan Dorfman writes: >> Is it implausible to suggest that before embarking on the task >> of backporting, reviewing, testing and releasing the actual fix, >> an announcement could have been made immediately with the much >> simpler workaround of adding -DOPENSSL_NO_HEARTBEATS to the >> OpenSSL compiler flags? > > No, that's not implausible, although I don't know whether that > workaround was known at the time. It seems obvious in retrospect, > but may not have been that obvious under pressure. Was it > mentioned in the OpenSSL advisory? The OpenSSL advisory did mentioned it. I didn't mention the workaround because I had posted our patch (ported and committed to secteam repo pending review at about 13:00 PDT I think, which later was revised because another unrelated CVE), and the workaround also requires recompile. Moreover, the patch would provide better protection because it changes the code so NO_CLEAN= won't skip it in an incremental build, while with -DOPENSSL_NO_HEARTBEATS it's possible that the user can mistakenly miss the fix. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRauaAAoJEJW2GBstM+nsxtIQAKOcxp0ziuJgrEpCg9yt2q7B rU6P6xOfVAbdMcNtj0v1XpXPyRrCtK2VHSYEd1BIIWlrYBwSLByeU2hfkYI0+TRS FGslwuiQVZFgkqfzQjHysAf3gZICa93q8PseHD0zcMb2gLYBqHxQo222dXBjJYY4 kdvK0qBaIy8JtYGyQbyZl9nUku0s642mla8wGPb4cuTi57F2jQk2y1lFz8dZbz3+ tiGqoEk02uJsoTYOryfgaydc4WuZ63g0w8EMIsN+18qNAVigMPgzisG8kpljA/yx mcNGfqp31BV3cHLEPjjXt7dnXvVbiEkU17ZlMNGJbgnjirfpG5sSWDM3HX1QA2Ih GYh05a3V+l2ZgpaBhdg22KBYoH7GOc4bPs1tdHzGr1dKwzZpt3JyiR+vpCAmDfwr RxNeFqmJnsK8VfvmIYqQHlZoDCTnzH60z8ecZG1dy6GiBVge9bqPBDUl9wvBRion 3vR3UMi1Ieby9a73MbffEyboXAGjXIXOTYp8JioqUlutj8VhgXNstDTdBw04w3s0 5lMXA6xI5hseZ/uJukrouVTzGKwZzFWht583An4DIsN4hjc4oF+LyBsFp1DYkRmX H7WA8wqOuqTW8rVMPLiQzt3vZOTpC98q/xntAaYktAO5lHAFoBwQnO+5xYBrENEK yJqP4hDtWUvFqQqBXPzi =fETK -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 20:20:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86D77D5A for ; Wed, 9 Apr 2014 20:20:56 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 497A21A86 for ; Wed, 9 Apr 2014 20:20:56 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 6DA5767F0; Wed, 9 Apr 2014 20:20:55 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id C60D94E2; Wed, 9 Apr 2014 22:20:55 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Biernacki Subject: Re: Proposal References: <3g3r546WVbz62Xv@devnoip.rootservice.org> Date: Wed, 09 Apr 2014 22:20:55 +0200 In-Reply-To: (Pawel Biernacki's message of "Wed, 9 Apr 2014 19:00:52 +0100") Message-ID: <8638hmz23c.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, joeuser@rootservice.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:20:56 -0000 Pawel Biernacki writes: > Joe User writes: > > http://seclists.org/oss-sec/2014/q2/22 > Interesting lecture, thank you. But if FreeBSD SO wasn't on the > mentioned list [...] We are. By my reckoning, Xin posted on -security that he was aware of the issue and working on it less than two hours after that announcement. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 20:39:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EFE2378 for ; Wed, 9 Apr 2014 20:39:02 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 366151C0F for ; Wed, 9 Apr 2014 20:39:02 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id wn1so3354771obc.16 for ; Wed, 09 Apr 2014 13:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TfSGzGdqdZg1lRpCBcZWS3lVyukdNVsI32SaKqMr2R0=; b=wy5EPFIxBWT3j/8LV6gUvWADRkbtuki+M89fAwmFSZiqp5PnTEbC3s9DQLrL0+tJxv CnoF9HC4XLpPg7dee8Vyf4nkUgKb7nPuIvv8NgWzwPWflKQeMygsHCu8EzA6N31ThxX1 3MXaQCKghjmd2OSM8HyOHlg/1tuYCz8bVqebvlyBL4eLEP4pR58CCDhZ67TsiIBMVUy6 zI1rkvyMm3IXiQSxVuMXEcBiEZG8OTgqbZkAT8ytn1KbuMRltz+zdXLO+F0XQT1OMqz+ AehVcoFqWaIIbqKYwPJaOI1vseDe6/V9wrkN+HaeZxLhEv7UcWrOWKh8Z4DfZHgwrO5i r0pA== MIME-Version: 1.0 X-Received: by 10.60.83.234 with SMTP id t10mr10427048oey.4.1397075941512; Wed, 09 Apr 2014 13:39:01 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.60.158.106 with HTTP; Wed, 9 Apr 2014 13:39:01 -0700 (PDT) In-Reply-To: <86d2gqz2he.fsf@nine.des.no> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> Date: Wed, 9 Apr 2014 16:39:01 -0400 X-Google-Sender-Auth: 1PqtGOcw7v102Wk-MEOSD5k-q0c Message-ID: Subject: Re: Proposal From: Nathan Dorfman To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Kimmo Paasiala , Walter Hop , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:39:02 -0000 On Wed, Apr 9, 2014 at 4:12 PM, Dag-Erling Sm=C3=B8rgrav wrote= : > Nathan Dorfman writes: >> Is it implausible to suggest that before embarking on the task of >> backporting, reviewing, testing and releasing the actual fix, an >> announcement could have been made immediately with the much simpler >> workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler >> flags? > > No, that's not implausible, although I don't know whether that > workaround was known at the time. It seems obvious in retrospect, but > may not have been that obvious under pressure. Was it mentioned in the > OpenSSL advisory? Yeah, I should have been clearer -- I personally learned about that from the OpenSSL advisory itself, which states: Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediatel= y upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. https://www.openssl.org/news/secadv_20140407.txt Be that as it may, Xin's explanation that simply committing a change to the Makefile would be ineffective in the face of a -DNO_CLEAN build makes sense. I didn't think about that. Moving on, is it not worth talking about going in and defining every -DOPENSSL_NO_* flag that exists and doesn't break the base system? On the simple grounds that there appears to be little to be gained from this kind of feeping creaturism, and plenty, as it turns out, to be lost. Of course, maybe the resulting build won't even work, or at least not work without significant effort. So this is more of a question than an actual suggestion. -nd. From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 20:57:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07222FDA for ; Wed, 9 Apr 2014 20:57:18 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B8D3A1E48 for ; Wed, 9 Apr 2014 20:57:17 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 99FE46B53; Wed, 9 Apr 2014 20:57:16 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id F187E52D; Wed, 9 Apr 2014 22:57:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Dorfman Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> Date: Wed, 09 Apr 2014 22:57:16 +0200 In-Reply-To: (Nathan Dorfman's message of "Wed, 9 Apr 2014 16:39:01 -0400") Message-ID: <86txa2xlub.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, Kimmo Paasiala , Walter Hop , Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:57:18 -0000 Nathan Dorfman writes: > Moving on, is it not worth talking about going in and defining every > -DOPENSSL_NO_* flag that exists and doesn't break the base system? On > the simple grounds that there appears to be little to be gained from > this kind of feeping creaturism, and plenty, as it turns out, to be > lost. This is similar in principle to what Peter did with svnlite. Worth considering. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 21:20:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C532EB02; Wed, 9 Apr 2014 21:20:00 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A274B11A2; Wed, 9 Apr 2014 21:20:00 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 8AF8F13004; Wed, 9 Apr 2014 14:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397078400; bh=A7J1T6FRR7EvJvdxhe6E7mX98jgOosR51zxYxuJfG4s=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=2WMgVO9U8qbEOxt0QMP04NKjLoW53sGE8ekQ1BNBihKpmsRazJ4GAespTMBrRfNm8 7uUfmckxugWiGgR3PTGOfE5eSsX3Uj8VpaY3RbI7+nKTCQF5cEuLY2oXIBjAcw+kRJ GKgtXpJCePsM14pBfCclGDsxO6rQIXPoS9TzHzjo= Message-ID: <5345B97E.6000802@delphij.net> Date: Wed, 09 Apr 2014 14:19:58 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:20:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/09/14 13:39, Nathan Dorfman wrote: > Moving on, is it not worth talking about going in and defining > every -DOPENSSL_NO_* flag that exists and doesn't break the base > system? On the simple grounds that there appears to be little to be > gained from this kind of feeping creaturism, and plenty, as it > turns out, to be lost. Of course, maybe the resulting build won't > even work, or at least not work without significant effort. So this > is more of a question than an actual suggestion. I'm not sure how well this can be done (see below), but that can be done in -HEAD for experiment at least. All -STABLE branches are considered as API/ABI frozen which means if we remove a functionality, they could break existing applications that happens to work for a previous FreeBSD release, so this may cause problems for -STABLE branches as application would see loss of functionality. So this is less likely to happen (IMO). Another orthogonal thought is that we should probably remove the static libraries of OpenSSL from -HEAD now (they will still be built and maybe used in the base system when static binary is absolutely needed). This will make it easier to make sure that the system is clean of outdated OpenSSL bits when updating the libraries. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRbl+AAoJEJW2GBstM+ns0XEQAIJxEjq3UdiQjo4NWwVpm6kl w/u67x3FoKehxngcmb2b+Y32C/+guWwz9gvAFnQ2cGH7EUhipxYWmcexYYg7/x3w Wl0S1StI8ib3lnnv87nvGjqPEb+N/DtvduvjjnjklNaDbUAYMiE2zWnjK7KNQ5Le iKa0WJFSJtHocF0xk8yd9CSK61crC2Cl9rYYhobUKQAEVmoAadM8vVgcK1cP2O1l J4QaYI+TZ0f1Jq+0N31y4Apei3vo9WW+OytHXyCRdsmjChLDvujy7tZ1u8iJignu VV2/zUiUCP4ULQUtn6lN0V2yLdqQjiW0SYMzwkOY0cAZNTTRmj/iLSPSf1RMSjxl MxjNM4TCp/xU20PfZZicE72BNuDctOhcE40WiZ4nhpKNHXBaD7+uy4CdUsFsae50 a8TFVoy5mPFEUq9MRvO/cxvVgdRxtEpDaEROGYFbWDDzjOHJ+vP0NvPRep6SBkUw b5OIZ73YU93kAMs/Ow7D3rlHsgnQ+E0Hgg9jeLc5iK2nWQhbKauY2GVJNtWjfoEV 10WSRSTmlVOS6S+VJwKmbAV5pc2XXgS1mq1i23S09Q4KnxS+xIvryMopYnA6qJFM cZ4rYK4FRg0JYm/gHmoCFhNuD9ZozUd+Lkhkoj/zT/ZPluvzFYFwsqxoLma/MGrt 8bUUa5K1COCDFqn8ECQp =C17j -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 21:38:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3E94BC4 for ; Wed, 9 Apr 2014 21:38:11 +0000 (UTC) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97F721449 for ; Wed, 9 Apr 2014 21:38:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N3S00G5J6EJEW10@mail-out.apple.com> for freebsd-security@freebsd.org; Wed, 09 Apr 2014 13:33:40 -0700 (PDT) X-AuditID: 11807157-f79aa6d0000017b2-6e-5345aea3ec57 Received: from [17.149.225.221] (Unknown_Domain [17.149.225.221]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 04.CF.06066.4AEA5435; Wed, 9 Apr 2014 13:33:40 -0700 (PDT) Subject: Re: Proposal From: Charles Swiger In-reply-to: Date: Wed, 09 Apr 2014 13:33:39 -0700 Message-id: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> To: Nathan Dorfman X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOPXhXd0l61yDDbZ+57Xo2fSEzWL6qXgH Jo8Zn+azeDw9M4clgCmKyyYlNSezLLVI3y6BK2PNnSvMBVuFKg7c/8rUwPier4uRk0NCwETi 04bPjBC2mMSFe+vZuhi5OIQE+pkknuyawwKSYBbQkrjx7yVTFyMHB6+AnsT2X3IgYWEBUYnL G74zgoTZBNQkJkzkAQlzCgRKXPh+iBnEZhFQkWg/2M8GMcVL4tHjiYwQtrbEsoWvwWp4Bawk 3j3cxQ6x9gqjxI47y8HWiggoSGx9+50V4jZZidPnnrNMYOSfheSiWQgXzUIydgEj8ypGgaLU nMRKE73EgoKcVL3k/NxNjKBwaygM38H4b5nVIUYBDkYlHt4Dy1yDhVgTy4orcw8xSnAwK4nw rlwFFOJNSaysSi3Kjy8qzUktPsQozcGiJM7bPQkoJZCeWJKanZpakFoEk2Xi4JRqYDzw3O7g j3LJ9hUV+p01sUsa7FNOzLy8efOST1Idj1vrj85eHtpU91u++6CElqTyrl/TTKPWcP7juLWw pr2oryHww0tOnYgLmydPCBOqeb/n+Zqym0d3zdFw8zk67Zxx1oyfPXq9s8Ul16myPb/4fF9r d6+wU6/ISrPlq3a98Hwav0n4y73Z+qJKLMUZiYZazEXFiQAyR1bUMwIAAA== Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:38:11 -0000 Hi-- On Apr 9, 2014, at 12:44 PM, Nathan Dorfman wrote: > Is it implausible to suggest that before embarking on the task of > backporting, reviewing, testing and releasing the actual fix, an > announcement could have been made immediately with the much simpler > workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler > flags? Sure, it's plausible. In fact, that exact workaround already was posted: http://www.openssl.org/news/secadv_20140407.txt "Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS." > Given the severity of the issue, it doesn't seem that an immediate > advisory stating "here's an immediate workaround, a full fix will be > coming in the next day or two" would be terribly inappropriate. > Perhaps this workaround would have required more testing than I > imagine, but surely it'd be a tiny fraction of the time required to > release the full fix? Your choices are simple: you can either do whatever you like yourself, in which case the time required to test things to your satisfaction is entirely up to you. Or you can wait until your OS vendor completes the release engineering needed to build, deploy, and validate the fixes, then publish the updated versions. > While I'm out here drawing fire, I might as well also ask if I'm crazy > to think that it might be a good idea for the base system OpenSSL (and > other third party imports) to just disable any and all non-essential > functionality that can be disabled at compile time? Deploying software with the default options selected is generally the most reasonable approach. Under unusual situations, disabling default functionality might be reasonable, but that generally indicates something is broken with the choices made upstream by the software authors. > Non-essential meaning everything not required for the base system to function -- > there's always the ports version if anyone needs more. Disabling commonly used functionality means that a lot more folks would need to replace the base system version with the ports version. Taken to the extreme, the result would be to effectively make the base system version useless. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 22:12:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C49B7ADA for ; Wed, 9 Apr 2014 22:12:06 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A944319DD for ; Wed, 9 Apr 2014 22:12:06 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 922E03ADFA for ; Wed, 9 Apr 2014 15:11:51 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl In-Reply-To: <20140409084809.GA2661@lena.kiev> Date: Wed, 09 Apr 2014 15:11:51 -0700 Message-ID: <39145.1397081511@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 22:12:06 -0000 In message <20140409084809.GA2661@lena.kiev>, Lena@lena.kiev.ua wrote: >Port mail/sendmail-sasl (sendmail+tls+sasl2-8.14.8) depends on the >openssl port. You need to upgrade the security/openssl port to >openssl-1.0.1_10 and restart sendmail. I am running 9.1-RELEASE and Apache _without_ any support for https. I am however also running Postfix as my mail server. Am I affected? From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 22:15:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AED3C03 for ; Wed, 9 Apr 2014 22:15:08 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 0319F1A13 for ; Wed, 9 Apr 2014 22:15:07 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 874543AE82 for ; Wed, 9 Apr 2014 15:15:07 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: linux-f10-openssl Date: Wed, 09 Apr 2014 15:15:07 -0700 Message-ID: <39203.1397081707@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 22:15:08 -0000 Does this port (linux-f10-openssl) also need to be rebuilt/reinstalled? From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 22:16:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77DD9E11 for ; Wed, 9 Apr 2014 22:16:31 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E6801A4D for ; Wed, 9 Apr 2014 22:16:31 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 2DE841396B; Wed, 9 Apr 2014 15:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397081789; bh=LlJBeSq8nmEQLUQHGIrvdb3pDGcij0Ybb12fgXuG6cc=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=lBawHO8k0cIUfqbQkG44DZeBITcqx30shpTRFPAcT7Jdo+u19e7DBxaFKkNnXzpx5 Ei90us5AueNbde8CHg/wh0LAYVoohRTtlcyGKohkBA0N42aR9OCx6IQ/sFsUB21q4z IDrCX3ynlPGAeNEPMGyI5IqfT3moVKTfl+yZepmk= Message-ID: <5345C699.8050909@delphij.net> Date: Wed, 09 Apr 2014 15:15:53 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl References: <39145.1397081511@server1.tristatelogic.com> In-Reply-To: <39145.1397081511@server1.tristatelogic.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 22:16:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/09/14 15:11, Ronald F. Guilmette wrote: > > In message <20140409084809.GA2661@lena.kiev>, Lena@lena.kiev.ua > wrote: > >> Port mail/sendmail-sasl (sendmail+tls+sasl2-8.14.8) depends on >> the openssl port. You need to upgrade the security/openssl port >> to openssl-1.0.1_10 and restart sendmail. > > I am running 9.1-RELEASE and Apache _without_ any support for > https. > > I am however also running Postfix as my mail server. > > Am I affected? If no security/openssl installed -- you are not. If security/openssl is installed and is older than 1.0.1_10, and postfix is configured to use SSL/TLS, and linked against the port OpenSSL (if they are built after OpenSSL port is installed, consider this as a "Yes", confirm with ldd /usr/local/libexec/postfix/smtpd and see if there is /usr/local/lib/libcrypto.so.8), then you are affected. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRcaZAAoJEJW2GBstM+nsPGAP+gJeyMYNKpZznlotKdh1Mxp3 nMYSDToOMZU09qURjL93ox94CP5dGpMtl9phYhOdmjyux+7d5GvlbuWgi2ZZnI7L YDWaQObTdsDLOQ1Szhm+drf+p7eYZ3Bs1fFBD0unUW9yI1kAtk3L4ry6+jgjIJnd ZEMfK2R+fNA/L6srKdIBYUt8rLcitUGHgqT1yN1ULckVv2os86FIGfd41BQiFBMR +4yc4m5TkrF/9FsWfR9+b2LwgqkuGzQdIgSmDNaLz0Owt3YMaApc0TpryZEhNDjW f94RzxKqyzHtr7OI2EQd+5d0CyzZAOch7b/NshOwTQGFkQU8u6AUld0nUyubGWWG fIUMOB7unDe04BKk5Ic8O+U57v9NOqastjekzzjDgEOqIYk/2W3lvnFuEbJnfTyI yvBcagDjTMWZKeSjWZne1ZcShc+pu3IP00b+SXj8DbLWSb49aKpcm/wTeI80OrLM l1k7nqufQZEGqqQslsZq/YpMw1p2wlCDEGL7culk+qnN1JebFjUn2kWrkBnPwF86 hcQ0oZdy0WPkQkb6s+hra4wEU2wx6/NtUwmjdji3FHEMBCzNUXvwkgVJMuToTmzG QrmmMthXge//aPPxWNC5slz/7558kewi9BmSRIT5pYIqArMe59ZgTxAcm614HSaG KjmrsuxwQ4codXgbthfe =z2Rc -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 22:17:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51F9AF9E for ; Wed, 9 Apr 2014 22:17:28 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 32BFF1A71 for ; Wed, 9 Apr 2014 22:17:28 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id AB04313A9A; Wed, 9 Apr 2014 15:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397081847; bh=dPux8UkcEfO+KtOcizR86dn3icLhU3n3GTeEIfh2snA=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=zG25N8aoYU68f7PSxQlHXjcUsJakjbagMltKtCdBv6jxxueiopLoURxhw455nQDrY no6m+OeM5sZXiPG4FHYHGiWQxy43807VzM/j4jivdpo9WpOMbg30DYh3s3hFPS8k4F wEJnHR52nBJWLFHCeL8hV6BZfOevBEOrmMIkw8zg= Message-ID: <5345C6F7.8060105@delphij.net> Date: Wed, 09 Apr 2014 15:17:27 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: linux-f10-openssl References: <39203.1397081707@server1.tristatelogic.com> In-Reply-To: <39203.1397081707@server1.tristatelogic.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 22:17:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/09/14 15:15, Ronald F. Guilmette wrote: > > Does this port (linux-f10-openssl) also need to be > rebuilt/reinstalled? No, it's too old to be vulnerable to CVE-2014-0160 ("Heartbleed") vulnerability, however it may be affected by certain other OpenSSL issues. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRcb3AAoJEJW2GBstM+nsQe4P/3ME48vPhbUrInEGF/JKxPO/ JV+sqQ83zvrBYKsqUj1q3bzBzcahvmGtGxjW76wwXuiU2zFnL2VrhttVIFNL+mDw h3QoEpN768GJWwSBx5eTziH7Q0CQFa1DUQVongdK5DafDPNYL4HVFOac5lxGGByx u/eLpLhcYSM6xRYgCEvXhID0npAKQfaCWEQ1oOdmr/rlkobRKBnp6HcoXm7BH+WW 8LpS8FF8xfIJLy/ilpcflblFt+aeDQmtobigPg+qCFOSA7936U3M57TFF5/imPwV dZDXnInu9DPFwYGEGF98Bz9vhqPCewks0gYbf2WD98k7x+VFaei69UyxjnR0ptU3 DuFiJcalf+3qs/DoZQV/SLxypBvCuKnJUTBa9BRb+ZTYEmyCp+mkIfBndlM1Fd2O 5TgiAulsmS30Dqcn3OsoBTeOO1LkC9B8+ZcZe3KGvCaztQYqb8ID3ZhpcYxxhAuM 27R67MTd9O9aM/EFgT9W2d4+eV0YHYjh8JR6HEKBAtG7mWHRGg+gyoHpj7ZaHduW UniSGFUBMF2g7bF5WyosbbAIhNMukWj1SzgBTNaowWJGXfWRRRGXXHyXQToqtLrv NHy37lrUPC1pAX4iqCdVcymbbCNG/3z1k7EbPJe1Coob/WCbKZQGOovL/YABVs5B 3eaiNG0ueO84Vs3tnQBQ =f3T5 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 22:28:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC35E642 for ; Wed, 9 Apr 2014 22:28:38 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 739A81BB5 for ; Wed, 9 Apr 2014 22:28:37 +0000 (UTC) Received: from [10.79.131.53] (carly.stf.rewt.org.uk [91.208.177.66]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lhr1.as41113.net (Postfix) with ESMTPS id 3g40WM4Y2mz7rBZ for ; Wed, 9 Apr 2014 22:28:31 +0000 (UTC) Message-ID: <5345C98D.7030907@rewt.org.uk> Date: Wed, 09 Apr 2014 23:28:29 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> In-Reply-To: <86d2gqz2he.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 22:28:38 -0000 The problem here is that a workaround wasn't communicated and I suspect a very small number of religous users actually sub to security@ - also bare in mmind that the website wasn't updated until a number of hours after, including rss which I suspect most people use. I am not trying to undermine the required testing here, but a simple binary patch via freebsd-update to disable heartbeats would have done in the interim (who even uses them, or knows about them). IME issues like this need to be patched first, tested later since it covers probably a large portion of the user base. I wll say that the Cloudflare disclosure was entirely irresponsible and an attempt at sly marketing, but someone should have been on this (not discounting Xin Li's quick patch, which basically nobody saw) straight away. If it is a case on lack of resources then as already mentioned, more resource is available if required - although I am unaware of the approval procedures required to publish such a patch. Not trying to start a flame war here but we've been upstaged by CentOS of all things... Cheers, Joe On 09/04/2014 21:12, Dag-Erling SmĆørgrav wrote: > Nathan Dorfman writes: >> Is it implausible to suggest that before embarking on the task of >> backporting, reviewing, testing and releasing the actual fix, an >> announcement could have been made immediately with the much simpler >> workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler >> flags? > > No, that's not implausible, although I don't know whether that > workaround was known at the time. It seems obvious in retrospect, but > may not have been that obvious under pressure. Was it mentioned in the > OpenSSL advisory? > > If all you wanted to hear was "we're working on it", well, Xin did write > that almost on -security exactly 48 hours ago. > > DES > From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 22:46:36 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 559A3B3E for ; Wed, 9 Apr 2014 22:46:36 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13C691D61 for ; Wed, 9 Apr 2014 22:46:36 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so2645628vcb.24 for ; Wed, 09 Apr 2014 15:46:35 -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:content-transfer-encoding; bh=DCnfytUnge5QgMxlxru6IIldvrNmu8g5KfZ42SpHvjM=; b=dG0ckSyTOQcqTbPt/1HsDak4QWd2/2CEN94o/eESGG0Dm10tImSRmzOSqJA+ELFctY 8PHkB6+MI8UR7vJXSLoLDL/I8c2mwza6fVyg5JTuLLKznSyatx9hfT5fqDYWU1hpDWOV namjBTcXNVx905LjbnOxzA6w/pYu5pqqP9AUaOEbvc6GQvJwU5mfOpJYxy61ZFwhc2Pu RpveiZaiP2KcVcs8tLeHmw10wZtGAl25iUy13oYtjZyfW9Z3yQc8ui9LrkpTbjZGItUe vB1HddPelaU3S3iLYoLMln+/r7cyiYwMEouN+XC9+ByY1FppS1ldZv6L14223FXyrCa4 Nzaw== MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr11189670vcb.0.1397083595214; Wed, 09 Apr 2014 15:46:35 -0700 (PDT) Received: by 10.221.39.130 with HTTP; Wed, 9 Apr 2014 15:46:35 -0700 (PDT) In-Reply-To: <867g6y1kfe.fsf@nine.des.no> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> Date: Wed, 9 Apr 2014 23:46:35 +0100 Message-ID: Subject: Re: Proposal From: Pawel Biernacki To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Kimmo Paasiala , Walter Hop X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 22:46:36 -0000 On 9 April 2014 18:28, Dag-Erling Sm=C3=B8rgrav wrote: > Walter Hop writes: >> FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their >> base about an hour later, FreeBSD base took around 24 hours. > > All Bryan had to do to update the port was change the version number in > the Makefile, run "make makesum" and commit. I assume that he did some > testing as well, but apart from that, he probably spent more time > writing the commit message than actually updating the port. > > Ubuntu is much the same, since they distribute OpenSSL as a package > rather than part of the base system - they don't even _have_ a base > system. > > RedHat had prior notice since one of the OpenSSL devs is on their > security team. They had an update ready to roll out before the issue > was leaked (the builds are dated 2014-04-07 11:34:45 UTC), and were > basically just waiting for the announcement, which was originally > planned for today. > > To update OpenSSL in the FreeBSD base system, Xin first had to verify > which FreeBSD releases were vulnerable and which weren't. He then had > to obtain, verify, apply and test a patch for head, stable/10 and > releng/10.0. Next, he had to upload the patch to the freebsd-update > build servers and start the builds, which take several hours. Once the > builds were done, he had to sign them and move them to the master > server, from which they propagated to the mirrors, and then sign the > release. > > Once the builds were ready to go, he moved into a phase where everything > had to happen more or less simultaneously: commit the patches, finalize > the advisory (which contains revision numbers and timestamps), sign it, > then commit the advisory and the patch to the doc tree, update the > relevant portions of the web site, wait for them to propagate (or grab a > passing member of clusteradm@ and have them push it through manually), > and finally mail out the advisory. > > Bonus points for updating vuln.xml and liaising with MITRE / CMU CERT / > NVD / what have you. > > And yes, he has a whole team, but apart from writing the advisory (which > is a lot more work than you'd think), this process is pretty much > single-threaded. The best you can hope for is to have someone relieve > you while you eat and sleep. > > And while everybody is running around yelling OMG THE INTERNET IS ON > FIRE and calling this an unprecedented event, I'm sitting here with a > strong sense of d=C3=A9ja vu, because this sort of thing actually happens > quite often. Off the top of my head, I can think of two advisories last > year - out of 14 - that were more or less rushed out in a panic. > Thank you for sharing that story. If you want to make an excuse that a build took a long time - it's really a poor one. If the build cluster is too slow then project need to acquire a new one. If there is no chance to get one from big friends of the project maybe it should be publicly announced that there is a need for new hardware and/or money for it. It's as easy as that. We - the users - are still here willing to help. Many of us had very hard time during last 48 hours. I know that when you fill responsible for something you want to do as much as you can, but you need to sleep, eat, etc.. If the whole process is to overwhelming for one person maybe it's time to think about extending the SO team or reorganising the process of preparing patched releases? If there is a need of hands, manpower or so why not ask the community to help? Since such situations had happened in the past and are still happening, something should be done about them. --=20 One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die= . From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 01:24:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAF0CD42 for ; Thu, 10 Apr 2014 01:24:23 +0000 (UTC) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ACFD1BE2 for ; Thu, 10 Apr 2014 01:24:23 +0000 (UTC) Received: by mail-yh0-f50.google.com with SMTP id c41so3209602yho.37 for ; Wed, 09 Apr 2014 18:24: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=O0i5Gj8kf2B5D94Isho5oXNjvZmsShnpmddRxff3Vy4=; b=UtKdp21fFJlAkG9upOwklLHCo6iFMEM1hu2kLsT5iicp410A0tIzyyyhKxuIHTNXez qw1hWxAbTGx97+jJ4e4Ig4seEbaqYcWNKmAlJKn0mlewzGlf4kjtUAY26vg+H11dAzxG 73AiDhb5iq+PUlT2jIfigPJUSoNLoTVphPF7KH90f/jevyhQkSB4R5w1qsuaYuv7ESd9 Fs3vei2u86HQcbbpDLCjwECW2f8zQRRynCFsGXsM3rsKVIbSpvX/CfmI50BXdz1JgQNt qUj7bF2SkIElGejsihfATWFFKIBqfa1KgygTarco7pUqCs6ZI6dYOhY0APNiXydgmGZZ 6igQ== MIME-Version: 1.0 X-Received: by 10.236.99.99 with SMTP id w63mr18799917yhf.52.1397093062359; Wed, 09 Apr 2014 18:24:22 -0700 (PDT) Received: by 10.170.221.214 with HTTP; Wed, 9 Apr 2014 18:24:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 09:24:22 +0800 Message-ID: Subject: Re: freebsd-security Digest, Vol 482, Issue 4 From: Ke-li Dong To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 01:24:23 -0000 help 2014-04-10 4:20 GMT+08:00 : > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-security digest..." > > > Today's Topics: > > 1. Proposal (Was: Re: FreeBSD Security Advisory > FreeBSD-SA-14:06.openssl) (Pawel Biernacki) > 2. Re: Proposal (Dag-Erling Sm?rgrav) > 3. Re: Proposal (Karl Denninger) > 4. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Zoran Kolic) > 5. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Karl Denninger) > 6. Re: Proposal (Kimmo Paasiala) > 7. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Gary Palmer) > 8. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Steven Hartland) > 9. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Karl Denninger) > 10. Re: Proposal (Was: Re: FreeBSD Security Advisory > FreeBSD-SA-14:06.openssl) (Big Lebowski) > 11. Re: Proposal (Walter Hop) > 12. Re: Proposal (Pawel Biernacki) > 13. Re: Proposal (Joe Holden) > 14. Re: Proposal (Joe User) > 15. Re: Proposal (jungleboogie0) > 16. Re: Proposal (ari edelkind) > 17. Re: Proposal (Dag-Erling Sm?rgrav) > 18. Re: Proposal (Pawel Biernacki) > 19. Re: Proposal (Dag-Erling Sm?rgrav) > 20. Re: Proposal (Joe User) > 21. Re: Proposal (Pawel Biernacki) > 22. Re: Proposal (jungleboogie0) > 23. Re: Proposal (Pawel Biernacki) > 24. Re: Proposal (leon@tuco) > 25. Re: Proposal (Nathan Dorfman) > 26. Re: Proposal (Matthew Seaman) > 27. Re: Proposal (Dag-Erling Sm?rgrav) > 28. Re: Proposal (Dag-Erling Sm?rgrav) > 29. Re: Proposal (Xin Li) > 30. Re: Proposal (Dag-Erling Sm?rgrav) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Apr 2014 13:36:48 +0100 > From: Pawel Biernacki > To: freebsd-security@freebsd.org > Subject: Proposal (Was: Re: FreeBSD Security Advisory > FreeBSD-SA-14:06.openssl) > Message-ID: > < > CAA3htvtb+yZRApEqJ41ue+6jB5Y_Une96SYyJRwQXBmQfRZbtQ@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 9 April 2014 00:34, FreeBSD Security Advisories > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > > ============================================================================= > > FreeBSD-SA-14:06.openssl Security > Advisory > > The FreeBSD > Project > > > > Topic: OpenSSL multiple vulnerabilities > > > > Category: contrib > > Module: openssl > > Announced: 2014-04-08 > > Affects: All supported versions of FreeBSD. > > Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) > > 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) > > 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) > > 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) > > 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) > > 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) > > 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) > > 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) > > CVE Name: CVE-2014-0076, CVE-2014-0160 > > > > Thank you for finally patching that vulnerability. Many of us, FreeBSD > users, are deeply concerned about security. Yesterday we had a very > busy day on #FreeBSD on freenode with many people asking why there is > no SA and how to mitigate the thread or patch it on their own. > > I understand that this is voluntary role and you have another (real > life) responsibilities that?s why I'd like to propose an idea of (at > least partially) paid position of Security Officer, because we all > need quick and efficient response in cases like that. > > FreeBSD Community has a good history of paying for work, many of us > supported phk@ in 2004, and recently FreeBSD Foundation hired several > people to work for all of us. Because I've no idea how Foundation had > planned a budget for this year, I don't know if there are any money > that can be allocated for that position. If not, maybe Foundation can > conduct additional public fundraising for that purpose? > > > > > -- > One of God's own prototypes. A high-powered mutant of some kind never > even considered for mass production. Too weird to live, and too rare to > die. > > > ------------------------------ > > Message: 2 > Date: Wed, 09 Apr 2014 15:25:04 +0200 > From: Dag-Erling Sm?rgrav > To: Pawel Biernacki > Cc: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <86fvlm7hzj.fsf@nine.des.no> > Content-Type: text/plain; charset=utf-8 > > Pawel Biernacki writes: > > I understand that this is voluntary role and you have another (real > > life) responsibilities that?s why I'd like to propose an idea of (at > > least partially) paid position of Security Officer, because we all > > need quick and efficient response in cases like that. > > Having a paid Security Officer would not have made any difference. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > > > ------------------------------ > > Message: 3 > Date: Wed, 09 Apr 2014 08:57:28 -0500 > From: Karl Denninger > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <534551C8.6030004@denninger.net> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 4/9/2014 8:25 AM, Dag-Erling Sm?rgrav wrote: > > Pawel Biernacki writes: > >> I understand that this is voluntary role and you have another (real > >> life) responsibilities that?s why I'd like to propose an idea of (at > >> least partially) paid position of Security Officer, because we all > >> need quick and efficient response in cases like that. > > Having a paid Security Officer would not have made any difference. > > > > DES > Agreed. > > In this particular case FreeBSD's team responded very quickly once the > threat was known and a resolution path was made available in a very > expeditious fashion. > > The real problem here is the depth of damage and the amount of work to > rectify it, particularly for those who have certificates issued by > someone else where **they** may have been compromised. But this has > nothing to do with FreeBSD. > > -- > -- Karl > karl@denninger.net > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2711 bytes > Desc: S/MIME Cryptographic Signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140409/859bf373/attachment-0001.bin > > > > ------------------------------ > > Message: 4 > Date: Wed, 9 Apr 2014 16:21:36 +0200 > From: Zoran Kolic > To: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: <20140409142136.GA871@faust.sbb.rs> > Content-Type: text/plain; charset=us-ascii > > Advisory claims 10.0 only to be affected. Patches to > branch 9 are not of importance on the same level? > > Zoran > > > > ------------------------------ > > Message: 5 > Date: Wed, 09 Apr 2014 09:25:59 -0500 > From: Karl Denninger > To: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: <53455877.5020006@denninger.net> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > On 4/9/2014 9:21 AM, Zoran Kolic wrote: > > Advisory claims 10.0 only to be affected. Patches to > > branch 9 are not of importance on the same level? > > > > Zoran > > > 9 (and before) were only impacted if you loaded the newer OpenSSL from > ports. A fair number of people did, however, as a means of preventing > BEAST attack vectors. > > If you did, then you need to update that and have all your private keys > re-issued. If you did not then you never had the buggy code in the > first place. > > -- > -- Karl > karl@denninger.net > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2711 bytes > Desc: S/MIME Cryptographic Signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140409/29a9014a/attachment-0001.bin > > > > ------------------------------ > > Message: 6 > Date: Wed, 09 Apr 2014 13:36:28 +0000 (GMT) > From: Kimmo Paasiala > To: Pawel Biernacki > Cc: "Dag-Erling Sm?rgrav" , freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On Apr 09, 2014, at 03:25 PM, Dag-Erling Sm?rgrav wrote: > > Pawel Biernacki writes: > ? ? ? ?> I understand that this is voluntary role and you have another > (real > ? ? ? ?> life) responsibilities that?s why I'd like to propose an idea of > (at > ? ? ? ?> least partially) paid position of Security Officer, because we > all > ? ? ? ?> need quick and efficient response in cases like that. > > Having a paid Security Officer would not have made any difference. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > ? > Could everyone just please stop panicking and take an objective look on > this issue. It took only one full DAY to come up with a fix and issue the > security advisory. That's damn fast if you look at some of the commercial > entities that face the exact same kind of issues and often struggle to even > acknowledge that there is a problem they need to address and take sometimes > weeks to release hotfixes. > > In my opinion this issue couldn't have been handled any better considering > what it takes to do the job properly, congrats to the security team from me. > > -Kimmo > > ------------------------------ > > Message: 7 > Date: Wed, 9 Apr 2014 10:39:40 -0400 > From: Gary Palmer > To: Zoran Kolic > Cc: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: <20140409143940.GA15884@in-addr.com> > Content-Type: text/plain; charset=us-ascii > > On Wed, Apr 09, 2014 at 04:21:36PM +0200, Zoran Kolic wrote: > > Advisory claims 10.0 only to be affected. Patches to > > branch 9 are not of importance on the same level? > > The version of OpenSSL shipped in the base FreeBSD code prior to 10.0 > is not vulnerable to the Heartbeat attack, however there is a different > vulnerability which *is* in 8.x and 9.x and was documented in the advisory > as [CVE-2014-0076] > > You should update 8.x and 9.x systems also, even though the vulnerability > there is probably not as easy to exploit as the Heartbeat attack. > > Regards, > > Gary > > > ------------------------------ > > Message: 8 > Date: Wed, 9 Apr 2014 15:47:25 +0100 > From: "Steven Hartland" > To: "Karl Denninger" , > > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: <8A7E8A9A8B034A3498601347FFFF088C@multiplay.co.uk> > Content-Type: text/plain; format=flowed; charset="Windows-1252"; > reply-type=response > > ----- Original Message ----- > From: "Karl Denninger" > > > > On 4/9/2014 9:21 AM, Zoran Kolic wrote: > >> Advisory claims 10.0 only to be affected. Patches to > >> branch 9 are not of importance on the same level? > >> > >> > > 9 (and before) were only impacted if you loaded the newer OpenSSL from > > ports. A fair number of people did, however, as a means of preventing > > BEAST attack vectors. > > > > If you did, then you need to update that and have all your private keys > > re-issued. If you did not then you never had the buggy code in the > > first place. > > Actually they are vulnerable without any ports install just not to > CVE-2014-0160 only CVE-2014-0076, both of which where fixed by > SA-14:06.openssl > > Regards > Steve > > > ------------------------------ > > Message: 9 > Date: Wed, 09 Apr 2014 09:50:25 -0500 > From: Karl Denninger > To: Steven Hartland , > freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: <53455E31.90100@denninger.net> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > > On 4/9/2014 9:47 AM, Steven Hartland wrote: > > ----- Original Message ----- From: "Karl Denninger" > > > > > > > > On 4/9/2014 9:21 AM, Zoran Kolic wrote: > >>> Advisory claims 10.0 only to be affected. Patches to > >>> branch 9 are not of importance on the same level? > >>> > >>> > >> 9 (and before) were only impacted if you loaded the newer OpenSSL > >> from ports. A fair number of people did, however, as a means of > >> preventing BEAST attack vectors. > >> > >> If you did, then you need to update that and have all your private > >> keys re-issued. If you did not then you never had the buggy code in > >> the first place. > > > > Actually they are vulnerable without any ports install just not to > > CVE-2014-0160 only CVE-2014-0076, both of which where fixed by > > SA-14:06.openssl > > > > Regards > > Steve > Good point -- there is that other advisory in there so "base" 8.x and > 9.x users should update as well. > > However, the other problem does not involve the same sort of > vulnerability to remote "grabs" of data, including authentication > credentials (and worse, private key data.) > > -- > -- Karl > karl@denninger.net > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 2711 bytes > Desc: S/MIME Cryptographic Signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140409/71c79a00/attachment-0001.bin > > > > ------------------------------ > > Message: 10 > Date: Wed, 9 Apr 2014 15:57:09 +0200 > From: Big Lebowski > To: freebsd-security@freebsd.org > Subject: Re: Proposal (Was: Re: FreeBSD Security Advisory > FreeBSD-SA-14:06.openssl) > Message-ID: > < > CAHcXP+dnKwJJrarzjTA4_y9BOFCf5trPe9MAuM7KtCxhEQSU_w@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > >* I understand that this is voluntary role and you have another (real > *> >* life) responsibilities that?s why I'd like to propose an idea of (at > *> >* least partially) paid position of Security Officer, because we all > *> >* need quick and efficient response in cases like that. > *> > > Having a paid Security Officer would not have made any difference. > > Do you care to elaborate on why it would not made any difference? And, > if possible, also on what could do one, if you have any ideas about > that? > > I have to say that I agree with Pawe? fully, I would love to see such > things being handled a way faster and to be better communicated, if > they're 'on they way' and I also belive having paid Security Office > could help - but I am happy to get to know why I might be under wrong > impression. > > I also doesnt know if there's any chance of directing any monye from > this year's budget towards improving that situation, but I also like > the idea of 'targeted' funding, where people gets a chance to say > where they want the money to be used, some sort of money democracy, I > would say. > > > Regards, > > Bl > > > ------------------------------ > > Message: 11 > Date: Wed, 9 Apr 2014 17:17:37 +0200 > From: Walter Hop > To: Kimmo Paasiala > Cc: freebsd-security@freebsd.org, Dag-Erling Sm?rgrav , > Pawel Biernacki > Subject: Re: Proposal > Message-ID: <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> > Content-Type: text/plain; charset=windows-1252 > > > In my opinion this issue couldn't have been handled any better > considering what it takes to do the job properly, congrats to the security > team from me. > > > > -Kimmo > > Please don?t frame this as criticism of the security people, that?s not > fair. Of course we all congratulate them :) > > I think we?re just interested in discussing what could be improved to > improve response time and also make their lives better. > > Do we need moar Jenkins? Extra build boxes? More cash to keep people on > retainer? Resources for training new people? Liaisons with other projects > to improve prior notification channels? Etc. > > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their base > about an hour later, FreeBSD base took around 24 hours. Not super bad, but > I think it?s safe to expect much more scrutiny of security-critical code in > the coming years, so it looks like a good time to try to streamline if > possible at all. > > The public attention for this and similar events may also provide a unique > window of opportunity for soliciting extra resources from professional > users (e.g. via a Foundation campaign). > > -- > Walter Hop | PGP key: https://lifeforms.nl/pgp > > > > ------------------------------ > > Message: 12 > Date: Wed, 9 Apr 2014 16:29:13 +0100 > From: Pawel Biernacki > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: > < > CAA3htvve4NNvmN0QOf6v4RwbT8PmGrSCFzNCbivfaEMN7J26Ow@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 9 April 2014 15:32, Kimmo Paasiala wrote: > > Can you name some of those projects that claim to have such quick > response > > time? I'll be steering way clear of them knowing that they don't test > their > > security patches before releasing them. It's really quite shocking to see > > that such unprofessional working attitude has taken so firm hold in the > open > > source world. What a pity. > > > RedHat managed to provide the fix within 21 hours but aparently they > knew very eraly about the issue. FreeBSD Security Team didn't? Why? > You can _see_ the whole process on their bugzilla > https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > > On the other hand Xin Li acknowledged the issue answering to an mail > to freebsd-security@ on Monday at 21:02 UTC and then after 21 hours of > _silence_ the fix was commited. They managed to release the fix 15 > hours before FreeBSD and I assume they test thing before release > because beside Fedora and Centos they also have paying customers. > > Debian acknowledged the problem in the same time as FreeBSD according > to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883 but they > released fix very very quickly. > > Ports got the fix very quickly as well. > > Maybe it'll surprise you but there are still people using FreeBSD. > What we are supposed to do when so@ is silent while scripts exploting > the issue are in the wild? > We need more transparency here. > > -- > One of God's own prototypes. A high-powered mutant of some kind never > even considered for mass production. Too weird to live, and too rare to > die. > > > ------------------------------ > > Message: 13 > Date: Wed, 09 Apr 2014 16:37:42 +0100 > From: Joe Holden > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <53456946.9030200@rewt.org.uk> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 09/04/2014 16:17, Walter Hop wrote: > >> In my opinion this issue couldn't have been handled any better > considering what it takes to do the job properly, congrats to the security > team from me. > >> > >> -Kimmo > > > > Please don?t frame this as criticism of the security people, that?s not > fair. Of course we all congratulate them :) > > > > I think we?re just interested in discussing what could be improved to > improve response time and also make their lives better. > > > > Do we need moar Jenkins? Extra build boxes? More cash to keep people on > retainer? Resources for training new people? Liaisons with other projects > to improve prior notification channels? Etc. > > > > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their > base about an hour later, FreeBSD base took around 24 hours. Not super bad, > but I think it?s safe to expect much more scrutiny of security-critical > code in the coming years, so it looks like a good time to try to streamline > if possible at all. > > > > The public attention for this and similar events may also provide a > unique window of opportunity for soliciting extra resources from > professional users (e.g. via a Foundation campaign). > > > 24 hours for a fix that doesn't break ABI and is relatively simple (and > proven to be fine by other distros) is horrendous for such a critical > problem. I mentioned this on twitter also, but there wasn't even a > headsup from the SO until the patch went live. > > > ------------------------------ > > Message: 14 > Date: Wed, 09 Apr 2014 18:08:31 +0200 > From: Joe User > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <3g3r546WVbz62Xv@devnoip.rootservice.org> > Content-Type: text/plain; charset=UTF-8 > > On 09.04.2014 17:29, Pawel Biernacki wrote: > > [snip] > > We need more transparency here. > > > > Please read this and other related threads and you'll understand that > the FreeBSD-SecTeam had no real chance to react earlier than they did. > http://seclists.org/oss-sec/2014/q2/22 > > In fact, they were realy fast, thanks therefor. > > Regards, > Joe User > > > ------------------------------ > > Message: 15 > Date: Wed, 9 Apr 2014 09:28:46 -0700 > From: jungleboogie0 > To: Walter Hop > Cc: freebsd-security@freebsd.org, Pawel Biernacki > , Kimmo Paasiala , > Dag-Erling Sm?rgrav > Subject: Re: Proposal > Message-ID: > aOSRrWtrjGLWynQSXCg@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Walter, > > > On 9 April 2014 08:17, Walter Hop wrote: > >> In my opinion this issue couldn't have been handled any better > considering what it takes to do the job properly, congrats to the security > team from me. > >> > >> -Kimmo > > > > Please don?t frame this as criticism of the security people, that?s not > fair. Of course we all congratulate them :) > > > > I think we?re just interested in discussing what could be improved to > improve response time and also make their lives better. > > > > Do we need moar Jenkins? Extra build boxes? More cash to keep people on > retainer? Resources for training new people? Liaisons with other projects > to improve prior notification channels? Etc. > > > > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their > base about an hour later, FreeBSD base took around 24 hours. Not super bad, > but I think it?s safe to expect much more scrutiny of security-critical > code in the coming years, so it looks like a good time to try to streamline > if possible at all. > > > > Please let us not forget that kernel.org was hacked and not detected > for 17 days: > http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/ > > > I would rather was 24 hours for a fix that's been verified and > reviewed over having to re-update the system. It looks like many linux > distros had this updated before > freeBSD but its a matter of hours we're talking about. > > > > > The public attention for this and similar events may also provide a > unique window of opportunity for soliciting extra resources from > professional users (e.g. via a Foundation campaign). > > > > -- > > Walter Hop | PGP key: https://lifeforms.nl/pgp > > > > > -- > ------- > inum: 883510009902611 > sip: jungleboogie@sip2sip.info > xmpp: jungle-boogie@jit.si > > > ------------------------------ > > Message: 16 > Date: Wed, 9 Apr 2014 11:54:28 -0400 > From: ari edelkind > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: > < > CAPxErSUkfJjS_kZcYb3gUbKZbcYwoGwC2O0gjRZmxNPpMPZ3TA@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Apr 9, 2014 at 11:37 AM, Joe Holden wrote: > > > 24 hours for a fix that doesn't break ABI and is relatively simple (and > > proven to be fine by other distros) is horrendous for such a critical > > problem. I mentioned this on twitter also, but there wasn't even a > headsup > > from the SO until the patch went live. > > > > To give this some additional perspective, it took me approximately 30 > minutes to write a working exploit. > > Everyone makes a big deal out of private keys (which, admittedly, are a big > deal), but i was able to collect usernames, passwords, session credentials, > back-end single-sign-on credentials (e.g. client tokens), database > passwords, and more from affected hosts -- all quite easily. > > ari > > > ------------------------------ > > Message: 17 > Date: Wed, 09 Apr 2014 19:28:53 +0200 > From: Dag-Erling Sm?rgrav > To: Walter Hop > Cc: freebsd-security@freebsd.org, Kimmo Paasiala > , Pawel Biernacki > Subject: Re: Proposal > Message-ID: <867g6y1kfe.fsf@nine.des.no> > Content-Type: text/plain; charset=utf-8 > > Walter Hop writes: > > FreeBSD ports had a fix after ~4 hours I think, Ubuntu patched their > > base about an hour later, FreeBSD base took around 24 hours. > > All Bryan had to do to update the port was change the version number in > the Makefile, run "make makesum" and commit. I assume that he did some > testing as well, but apart from that, he probably spent more time > writing the commit message than actually updating the port. > > Ubuntu is much the same, since they distribute OpenSSL as a package > rather than part of the base system - they don't even _have_ a base > system. > > RedHat had prior notice since one of the OpenSSL devs is on their > security team. They had an update ready to roll out before the issue > was leaked (the builds are dated 2014-04-07 11:34:45 UTC), and were > basically just waiting for the announcement, which was originally > planned for today. > > To update OpenSSL in the FreeBSD base system, Xin first had to verify > which FreeBSD releases were vulnerable and which weren't. He then had > to obtain, verify, apply and test a patch for head, stable/10 and > releng/10.0. Next, he had to upload the patch to the freebsd-update > build servers and start the builds, which take several hours. Once the > builds were done, he had to sign them and move them to the master > server, from which they propagated to the mirrors, and then sign the > release. > > Once the builds were ready to go, he moved into a phase where everything > had to happen more or less simultaneously: commit the patches, finalize > the advisory (which contains revision numbers and timestamps), sign it, > then commit the advisory and the patch to the doc tree, update the > relevant portions of the web site, wait for them to propagate (or grab a > passing member of clusteradm@ and have them push it through manually), > and finally mail out the advisory. > > Bonus points for updating vuln.xml and liaising with MITRE / CMU CERT / > NVD / what have you. > > And yes, he has a whole team, but apart from writing the advisory (which > is a lot more work than you'd think), this process is pretty much > single-threaded. The best you can hope for is to have someone relieve > you while you eat and sleep. > > And while everybody is running around yelling OMG THE INTERNET IS ON > FIRE and calling this an unprecedented event, I'm sitting here with a > strong sense of d?ja vu, because this sort of thing actually happens > quite often. Off the top of my head, I can think of two advisories last > year - out of 14 - that were more or less rushed out in a panic. > > DES (so@ on sabbatical) > -- > Dag-Erling Sm?rgrav - des@des.no > > > ------------------------------ > > Message: 18 > Date: Wed, 9 Apr 2014 18:50:33 +0100 > From: Pawel Biernacki > To: jungleboogie0 > Cc: freebsd-security@freebsd.org, Kimmo Paasiala > , Walter Hop , > Dag-Erling Sm?rgrav > Subject: Re: Proposal > Message-ID: > 2UkiEYF+V2+nUY2iacBJwbJVEp66cvLbh4nX_vgZQ@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 9 April 2014 17:28, jungleboogie0 wrote: > > > > Please let us not forget that kernel.org was hacked and not detected > > for 17 days: > http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/ > > I don't know why you're bringing it up here, because FreeBSD had > similar problem some time ago > (http://www.freebsd.org/news/2012-compromise.html) and I think that we > had learnt a lot from it. > > > I would rather was 24 hours for a fix that's been verified and > > reviewed over having to re-update the system. It looks like many linux > > distros had this updated before > > freeBSD but its a matter of hours we're talking about. > > > > -- > One of God's own prototypes. A high-powered mutant of some kind never > even considered for mass production. Too weird to live, and too rare to > die. > > > ------------------------------ > > Message: 19 > Date: Wed, 09 Apr 2014 19:53:10 +0200 > From: Dag-Erling Sm?rgrav > To: Pawel Biernacki > Cc: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <86txa2z8xl.fsf@nine.des.no> > Content-Type: text/plain; charset=utf-8 > > Pawel Biernacki writes: > > RedHat managed to provide the fix within 21 hours but aparently they > > knew very eraly about the issue. FreeBSD Security Team didn't? Why? > > You can _see_ the whole process on their bugzilla > > https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > > No you can't. That ticket is just window dressing. By the time it was > created, RedHat had known about the issue for at least a week, and > probably more. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > > > ------------------------------ > > Message: 20 > Date: Wed, 09 Apr 2014 20:00:01 +0200 > From: Joe User > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <3g3tYW2jPgz62Y0@devnoip.rootservice.org> > Content-Type: text/plain; charset=UTF-8 > > On 09.04.2014 19:53, Dag-Erling Sm?rgrav wrote: > > Pawel Biernacki writes: > >> RedHat managed to provide the fix within 21 hours but aparently they > >> knew very eraly about the issue. FreeBSD Security Team didn't? Why? > >> You can _see_ the whole process on their bugzilla > >> https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > > > > No you can't. That ticket is just window dressing. By the time it was > > created, RedHat had known about the issue for at least a week, and > > probably more. > > > > DES > > > > According to Kurts Post on oss-sec RedHat didn't know it before others. > > Regards, > Joe User > > > ------------------------------ > > Message: 21 > Date: Wed, 9 Apr 2014 19:00:52 +0100 > From: Pawel Biernacki > To: joeuser@rootservice.org > Cc: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: > < > CAA3htvtSOGdfUQY9SiAQu5SUzgRxs6izyLjjMPWtKao8HjJo+w@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 9 April 2014 17:08, Joe User wrote: > > On 09.04.2014 17:29, Pawel Biernacki wrote: > >> [snip] > >> We need more transparency here. > >> > > > > Please read this and other related threads and you'll understand that > > the FreeBSD-SecTeam had no real chance to react earlier than they did. > > http://seclists.org/oss-sec/2014/q2/22 > > > > In fact, they were realy fast, thanks therefor. > > Interesting lecture, thank you. But if FreeBSD SO wasn't on the > mentioned list it's an argument for payable position because that can > help developing more efficient social network in the future ;-). > > -- > One of God's own prototypes. A high-powered mutant of some kind never > even considered for mass production. Too weird to live, and too rare to > die. > > > ------------------------------ > > Message: 22 > Date: Wed, 9 Apr 2014 11:04:23 -0700 > From: jungleboogie0 > To: Pawel Biernacki > Cc: freebsd-security@freebsd.org, Kimmo Paasiala > , Walter Hop , > Dag-Erling Sm?rgrav > Subject: Re: Proposal > Message-ID: > qZNLJPkdTaDJNJn6hkmgVLg+5T9dFdHAh53ew@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Pawel, > > > > On 9 April 2014 10:50, Pawel Biernacki wrote: > > On 9 April 2014 17:28, jungleboogie0 wrote: > >> > >> Please let us not forget that kernel.org was hacked and not detected > >> for 17 days: > http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/ > > > > I don't know why you're bringing it up here, because FreeBSD had > > similar problem some time ago > > (http://www.freebsd.org/news/2012-compromise.html) and I think that we > > had learnt a lot from it. > > > > Interesting, I didn't know these were identical in nature. Thanks! > > > >> I would rather was 24 hours for a fix that's been verified and > >> reviewed over having to re-update the system. It looks like many linux > >> distros had this updated before > >> freeBSD but its a matter of hours we're talking about. > >> > > > > -- > > One of God's own prototypes. A high-powered mutant of some kind never > > even considered for mass production. Too weird to live, and too rare to > die. > > > > -- > ------- > inum: 883510009902611 > sip: jungleboogie@sip2sip.info > xmpp: jungle-boogie@jit.si > > > ------------------------------ > > Message: 23 > Date: Wed, 9 Apr 2014 19:15:46 +0100 > From: Pawel Biernacki > To: Dag-Erling Sm?rgrav > Cc: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: > iPFQ@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 9 April 2014 18:53, Dag-Erling Sm?rgrav wrote: > > Pawel Biernacki writes: > >> RedHat managed to provide the fix within 21 hours but aparently they > >> knew very eraly about the issue. FreeBSD Security Team didn't? Why? > >> You can _see_ the whole process on their bugzilla > >> https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > > > > No you can't. That ticket is just window dressing. By the time it was > > created, RedHat had known about the issue for at least a week, and > > probably more. > > > > According to http://seclists.org/oss-sec/2014/q2/36 RedHat learnt > about it 7th March and after that the bugzilla entry was created. I > assume that it was marked as private and unaccessible to other users > for few hours until release of SA but at least he have some trace of > what was done. > > > -- > One of God's own prototypes. A high-powered mutant of some kind never > even considered for mass production. Too weird to live, and too rare to > die. > > > ------------------------------ > > Message: 24 > Date: Wed, 09 Apr 2014 20:02:55 +0200 > From: "leon@tuco" > To: Dag-Erling Sm?rgrav , Pawel Biernacki > > Cc: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <53458B4F.5070908@tucoinfo.fr> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 09/04/2014 19:53, Dag-Erling Sm?rgrav wrote: > > Pawel Biernacki writes: > >> >RedHat managed to provide the fix within 21 hours but aparently they > >> >knew very eraly about the issue. FreeBSD Security Team didn't? Why? > >> >You can_see_ the whole process on their bugzilla > >> >https://bugzilla.redhat.com/show_bug.cgi?id=1084875. > > No you can't. That ticket is just window dressing. By the time it was > > created, RedHat had known about the issue for at least a week, and > > probably more. > Who cares, nobody found it in 2 years and we are squabbling about a few > hours or days! > > I am much more worried about the late coming journalists who are > starting to freak out any Internet credit card user. That is really bad > for e-commerce - in addition to these depressing last years of financial > crisis. > > Thank you for your efforts and I will definitely continue using FreeBSD. > > > ------------------------------ > > Message: 25 > Date: Wed, 9 Apr 2014 15:44:53 -0400 > From: Nathan Dorfman > To: Dag-Erling Sm?rgrav > Cc: freebsd-security@freebsd.org, Kimmo Paasiala > , Walter Hop , > Pawel > Biernacki > Subject: Re: Proposal > Message-ID: > nrh9evhv8VekMdNKauOQFN6dg@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > First, the (unfortunately) necessary disclaimer: this is an honest > question to satisfy my curiosity, nothing more. Absolutely no > criticism of anyone is intended. > > Is it implausible to suggest that before embarking on the task of > backporting, reviewing, testing and releasing the actual fix, an > announcement could have been made immediately with the much simpler > workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler > flags? > > Given the severity of the issue, it doesn't seem that an immediate > advisory stating "here's an immediate workaround, a full fix will be > coming in the next day or two" would be terribly inappropriate. > Perhaps this workaround would have required more testing than I > imagine, but surely it'd be a tiny fraction of the time required to > release the full fix? > > While I'm out here drawing fire, I might as well also ask if I'm crazy > to think that it might be a good idea for the base system OpenSSL (and > other third party imports) to just disable any and all non-essential > functionality that can be disabled at compile time? Non-essential > meaning everything not required for the base system to function -- > there's always the ports version if anyone needs more. > > Thanks for your thoughts, and of course, your ongoing efforts. They > are much appreciated. > > -nd. > > > ------------------------------ > > Message: 26 > Date: Wed, 09 Apr 2014 20:38:39 +0100 > From: Matthew Seaman > To: freebsd-security@freebsd.org > Subject: Re: Proposal > Message-ID: <5345A1BF.2030809@FreeBSD.org> > Content-Type: text/plain; charset="utf-8" > > On 09/04/2014 18:28, Dag-Erling Sm?rgrav wrote: > > RedHat had prior notice since one of the OpenSSL devs is on their > > security team. They had an update ready to roll out before the issue > > was leaked (the builds are dated 2014-04-07 11:34:45 UTC), and were > > basically just waiting for the announcement, which was originally > > planned for today. > > Didn't we (FreeBSD) have any advanced knowledge? There is at least one > FreeBSD committer who is also an OpenSSL developer... > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 1036 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140409/117cdc73/attachment-0001.sig > > > > ------------------------------ > > Message: 27 > Date: Wed, 09 Apr 2014 22:12:29 +0200 > From: Dag-Erling Sm?rgrav > To: Nathan Dorfman > Cc: freebsd-security@freebsd.org, Kimmo Paasiala > , Walter Hop , > Pawel > Biernacki > Subject: Re: Proposal > Message-ID: <86d2gqz2he.fsf@nine.des.no> > Content-Type: text/plain; charset=utf-8 > > Nathan Dorfman writes: > > Is it implausible to suggest that before embarking on the task of > > backporting, reviewing, testing and releasing the actual fix, an > > announcement could have been made immediately with the much simpler > > workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler > > flags? > > No, that's not implausible, although I don't know whether that > workaround was known at the time. It seems obvious in retrospect, but > may not have been that obvious under pressure. Was it mentioned in the > OpenSSL advisory? > > If all you wanted to hear was "we're working on it", well, Xin did write > that almost on -security exactly 48 hours ago. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > > > ------------------------------ > > Message: 28 > Date: Wed, 09 Apr 2014 22:13:23 +0200 > From: Dag-Erling Sm?rgrav > To: Nathan Dorfman > Cc: freebsd-security@freebsd.org, Walter Hop > , Kimmo Paasiala , > Pawel Biernacki > Subject: Re: Proposal > Message-ID: <868urez2fw.fsf@nine.des.no> > Content-Type: text/plain; charset=utf-8 > > Dag-Erling Sm?rgrav writes: > > If all you wanted to hear was "we're working on it", well, Xin did write > > that almost on -security exactly 48 hours ago. > > s/that almost on -security/that on -security almost/ > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > > > ------------------------------ > > Message: 29 > Date: Wed, 09 Apr 2014 13:20:42 -0700 > From: Xin Li > To: Dag-Erling Sm?rgrav , Nathan Dorfman > Cc: freebsd-security@freebsd.org, Walter Hop > , Kimmo Paasiala , > Pawel Biernacki > Subject: Re: Proposal > Message-ID: <5345AB9A.8040001@delphij.net> > Content-Type: text/plain; charset=UTF-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 04/09/14 13:12, Dag-Erling Sm?rgrav wrote: > > Nathan Dorfman writes: > >> Is it implausible to suggest that before embarking on the task > >> of backporting, reviewing, testing and releasing the actual fix, > >> an announcement could have been made immediately with the much > >> simpler workaround of adding -DOPENSSL_NO_HEARTBEATS to the > >> OpenSSL compiler flags? > > > > No, that's not implausible, although I don't know whether that > > workaround was known at the time. It seems obvious in retrospect, > > but may not have been that obvious under pressure. Was it > > mentioned in the OpenSSL advisory? > > The OpenSSL advisory did mentioned it. > > I didn't mention the workaround because I had posted our patch (ported > and committed to secteam repo pending review at about 13:00 PDT I > think, which later was revised because another unrelated CVE), and the > workaround also requires recompile. Moreover, the patch would provide > better protection because it changes the code so NO_CLEAN= won't skip > it in an incremental build, while with -DOPENSSL_NO_HEARTBEATS it's > possible that the user can mistakenly miss the fix. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTRauaAAoJEJW2GBstM+nsxtIQAKOcxp0ziuJgrEpCg9yt2q7B > rU6P6xOfVAbdMcNtj0v1XpXPyRrCtK2VHSYEd1BIIWlrYBwSLByeU2hfkYI0+TRS > FGslwuiQVZFgkqfzQjHysAf3gZICa93q8PseHD0zcMb2gLYBqHxQo222dXBjJYY4 > kdvK0qBaIy8JtYGyQbyZl9nUku0s642mla8wGPb4cuTi57F2jQk2y1lFz8dZbz3+ > tiGqoEk02uJsoTYOryfgaydc4WuZ63g0w8EMIsN+18qNAVigMPgzisG8kpljA/yx > mcNGfqp31BV3cHLEPjjXt7dnXvVbiEkU17ZlMNGJbgnjirfpG5sSWDM3HX1QA2Ih > GYh05a3V+l2ZgpaBhdg22KBYoH7GOc4bPs1tdHzGr1dKwzZpt3JyiR+vpCAmDfwr > RxNeFqmJnsK8VfvmIYqQHlZoDCTnzH60z8ecZG1dy6GiBVge9bqPBDUl9wvBRion > 3vR3UMi1Ieby9a73MbffEyboXAGjXIXOTYp8JioqUlutj8VhgXNstDTdBw04w3s0 > 5lMXA6xI5hseZ/uJukrouVTzGKwZzFWht583An4DIsN4hjc4oF+LyBsFp1DYkRmX > H7WA8wqOuqTW8rVMPLiQzt3vZOTpC98q/xntAaYktAO5lHAFoBwQnO+5xYBrENEK > yJqP4hDtWUvFqQqBXPzi > =fETK > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 30 > Date: Wed, 09 Apr 2014 22:20:55 +0200 > From: Dag-Erling Sm?rgrav > To: Pawel Biernacki > Cc: freebsd-security@freebsd.org, joeuser@rootservice.org > Subject: Re: Proposal > Message-ID: <8638hmz23c.fsf@nine.des.no> > Content-Type: text/plain; charset=utf-8 > > Pawel Biernacki writes: > > Joe User writes: > > > http://seclists.org/oss-sec/2014/q2/22 > > Interesting lecture, thank you. But if FreeBSD SO wasn't on the > > mentioned list [...] > > We are. By my reckoning, Xin posted on -security that he was aware of > the issue and working on it less than two hours after that announcement. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 > " > > ------------------------------ > > End of freebsd-security Digest, Vol 482, Issue 4 > ************************************************ > From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 01:24:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 692A8E18 for ; Thu, 10 Apr 2014 01:24:54 +0000 (UTC) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B5501BF5 for ; Thu, 10 Apr 2014 01:24:54 +0000 (UTC) Received: by mail-yk0-f173.google.com with SMTP id 10so2930823ykt.4 for ; Wed, 09 Apr 2014 18:24:53 -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=Fb9018UIhuM/sou3BCNaYvctMTaS02cArphSYqLNZuY=; b=zQVkQI3BEsxcb8f+VL4ao/1aDbQuRWrUTpt6wQiKZo4fYRJ65XowzLZgtBrFRy3Qj4 Gu532m/qVVP36VNH+0t13Hwb9byFHpWjLycyKhnnprKIhTC1hbkI59ZTbnXQxMozMpBz H3ln5TMA3060X1NIWWzFrFk4RivqCLJ8Sliw0EdyexfgVfPVRX4Jz/tqeKBUHwByVxdH ziyNZAcpbxkRTZCuKC2ej4Itiwy3AhmXIgRMDc3VGpIfY/zIp7P7Bo1lOgWYbe+eXpzE Im2km4t/xMpmjndSskpXizFxpDcGe55nlWPS0uY767d2VE10w5oV/5OBu4gMst0/oMtM ldtw== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr18208040yhn.87.1397093093414; Wed, 09 Apr 2014 18:24:53 -0700 (PDT) Received: by 10.170.221.214 with HTTP; Wed, 9 Apr 2014 18:24:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 09:24:53 +0800 Message-ID: Subject: Re: freebsd-security Digest, Vol 482, Issue 3 From: Ke-li Dong To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 01:24:54 -0000 help 2014-04-09 20:00 GMT+08:00 : > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-security digest..." > > > Today's Topics: > > 1. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Anton Shterenlikht) > 2. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Lena@lena.kiev.ua) > 3. Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > (Anton Shterenlikht) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Apr 2014 09:21:22 +0100 (BST) > From: Anton Shterenlikht > To: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: > <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> > > >From owner-freebsd-security-notifications@freebsd.org Wed Apr 9 > 00:37:34 2014 > > > >IV. Workaround > > > >No workaround is available, but systems that do not use OpenSSL to > implement > >the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) > >protocols implementation and do not use the ECDSA implementation from > OpenSSL > >are not vulnerable. > > Please help me find out if my systems are vulnerable. > > I use authenticated sendmail with security/cyrus-sasl2: > > # grep SENDMAIL /etc/make.conf > SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+= -L/usr/local/lib > SENDMAIL_LDADD+= -lsasl2 > # > > I also use ssh-keygen(1). > > Am I affected? > > Is it possible to list a few sample base OS > programs or libraries which are affected? > > Apologies if I completely misunderstood the advisory. > > Thanks > > > > ------------------------------ > > Message: 2 > Date: Wed, 9 Apr 2014 11:48:09 +0300 > From: Lena@lena.kiev.ua > To: Anton Shterenlikht > Cc: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: <20140409084809.GA2661@lena.kiev> > Content-Type: text/plain; charset=us-ascii > > > >systems that do not use OpenSSL to implement > > >the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS > v1) > > >protocols implementation and do not use the ECDSA implementation from > OpenSSL > > >are not vulnerable. > > > > Please help me find out if my systems are vulnerable. > > > > I use authenticated sendmail with security/cyrus-sasl2: > > > > # grep SENDMAIL /etc/make.conf > > SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 > > SENDMAIL_LDFLAGS+= -L/usr/local/lib > > SENDMAIL_LDADD+= -lsasl2 > > # > > > > I also use ssh-keygen(1). > > > > Am I affected? > > Port mail/sendmail-sasl (sendmail+tls+sasl2-8.14.8) depends on the > openssl port. You need to upgrade the security/openssl port to > openssl-1.0.1_10 and restart sendmail. > > SSH is not affected. > > > Is it possible to list a few sample base OS > > programs or libraries which are affected? > > Besides ports, only FreeBSD 10 base is affected. The recipe was posted > here: > ldd /usr/bin/* /usr/sbin/* /bin/* 2>/dev/null | less > /ssl > > > ------------------------------ > > Message: 3 > Date: Wed, 9 Apr 2014 11:17:45 +0100 (BST) > From: Anton Shterenlikht > To: Lena@lena.kiev.ua, mexas@bris.ac.uk > Cc: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl > Message-ID: > <201404091017.s39AHjhO024515@mech-cluster241.men.bris.ac.uk> > > >From Lena@lena.kiev.ua Wed Apr 9 10:43:40 2014 > > > >Port mail/sendmail-sasl (sendmail+tls+sasl2-8.14.8) depends on the > >openssl port. You need to upgrade the security/openssl port to > >openssl-1.0.1_10 and restart sendmail. > > I didn't know about this route of having authenticated > sendmail. It's not mentioned in the handbook: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/SMTP-Auth.html > > Are you saying mail/sendmail-sasl implements > exactly the same functionality as rebuilding > the base OS sendmail, as mentioned in the handbook? > > Thanks > > Anton > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 > " > > ------------------------------ > > End of freebsd-security Digest, Vol 482, Issue 3 > ************************************************ > From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 01:50:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5828EDB for ; Thu, 10 Apr 2014 01:50:44 +0000 (UTC) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 178271D94 for ; Thu, 10 Apr 2014 01:50:44 +0000 (UTC) Received: by mail-yh0-f43.google.com with SMTP id b6so3254396yha.30 for ; Wed, 09 Apr 2014 18:50:43 -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=85fuvEftKIX7QNbvgFdF72tbbmYOdAOJ6ULLb7ucHIk=; b=0N/1zvo4bW1xSot8H6GQkwk8GCxx0i7yL0D2ot2xq0GeUk5uDZrfmN9H8h6ETz1/Qa Bos8fZ8x6wdNoZ0Io/+T/+xgOpF5a+3PT597X8Hs05Vm5MQpWft1DC0CAsJZ7TtJdfy3 seiiEAtWJPbJ18BDIVZ50RRXz1giXXf34pKxXsE3W5BnJoOGmAsvWh9+ppItBKYSQEtx rme40uuImOHv3HCitzxyzhDBIKBo+S+oP+zwNQe1VPLvQsbCsrSOmsMwIO7J3N/xdPuZ UDZewHMCH7H+cd6Hea+ZKsiA7mThtGDh2kZ/zOEpX8xtlY3vIMfcZjHvaSRkz/DzU9kX 9zSw== MIME-Version: 1.0 X-Received: by 10.236.52.74 with SMTP id d50mr18951248yhc.44.1397094643227; Wed, 09 Apr 2014 18:50:43 -0700 (PDT) Received: by 10.170.221.214 with HTTP; Wed, 9 Apr 2014 18:50:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 09:50:43 +0800 Message-ID: Subject: Re: freebsd-security Digest, Vol 482, Issue 1 From: Ke-li Dong To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 01:50:44 -0000 help 2014-04-08 20:00 GMT+08:00 : > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-security digest..." > > > Today's Topics: > > 1. http://heartbleed.com/ (Thomas Steen Rasmussen) > 2. Re: http://heartbleed.com/ (Xin Li) > 3. Re: http://heartbleed.com/ (Mike Tancsa) > 4. Re: http://heartbleed.com/ (Xin Li) > 5. Re: http://heartbleed.com/ (Bryan Drewery) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 07 Apr 2014 22:49:54 +0200 > From: Thomas Steen Rasmussen > To: freebsd-security@freebsd.org > Subject: http://heartbleed.com/ > Message-ID: <53430F72.1040307@gibfest.dk> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > http://heartbleed.com/ describes an openssl vulnerability published > today. We are going to need an advisory for the openssl in base in > FreeBSD 10 and we are also going to need an updated port. > > The implications of this vulnerability are pretty massive, > certificates will need to be replaced and so on. I don't want to > repeat the page, so go read that. > > Best regards, > > > /Thomas Steen Rasmussen > > ps. there is a bit on the openssl site too: > https://www.openssl.org/news/secadv_20140407.txt > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTQw9yAAoJEHcv938JcvpYcFgP/iH3j6n7PgkCwSsN3qG9F37c > A6TOGbKudIeJdO76YXiU2T+FjbMThB86KuSan2iTM4h5wTLENVLvafJmBJtIKRH8 > bMZUqsUONYBSd4HpZKxbg9s8Yfy2gU0dTbs10OZ/dZw6qEr5Pd0WK6BDZ5h0ggTj > 0gF4r+FHWAe/8GgxOnfVEcmyMa+VUB46ZMmpwlCC3SG0wMAs/LJHORyl283OqyT5 > fwNfeDjInsPAgZORdR2+PZTgshwL0ogOINyGSKrLV1psQg2hEMgRT4GvO37IlhHS > qstYleB0yLiq9ayRFyj3mg2/OMq7/26ft09fHeF19VjnysClxT7lwZEaPDkbxH7j > qC1rpo1yeGuBPPdFnjbZVP5rxLR1jnQZFgTwOafjjock8ZW1ktUXOg1Upe276sv9 > NrPmNzDUkuMp7tlYEuDC2MsxQNSjeCo86FdMGCH+/c+DbRqBidELFH8SYEgzK2kj > TiT8tmBjdLC8PL+1SvBV4hLgapFJp2nvXsxyuJc2teRntKdgjFObQPEzb+iM/zFA > mSOjuGUh28qABlqQ32B04VDBOQRUs6zWDe0cssspajqfx7T7wVaE1FGBDUUt0QkN > B45cs2ql0OG5XB03GLsJv0tSdymzwohlBmoqmA08mKVWILFdkL/zzSY8Mw0oTfUa > GWD5kOI/wytuF5svXFnP > =gj4I > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 2 > Date: Mon, 07 Apr 2014 14:02:45 -0700 > From: Xin Li > To: Thomas Steen Rasmussen , > freebsd-security@freebsd.org > Subject: Re: http://heartbleed.com/ > Message-ID: <53431275.4080906@delphij.net> > Content-Type: text/plain; charset="iso-8859-1" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, Thomas, > > On 04/07/14 13:49, Thomas Steen Rasmussen wrote: > > Hello, > > > > http://heartbleed.com/ describes an openssl vulnerability > > published today. We are going to need an advisory for the openssl > > in base in FreeBSD 10 and we are also going to need an updated > > port. > > > > The implications of this vulnerability are pretty massive, > > certificates will need to be replaced and so on. I don't want to > > repeat the page, so go read that. > > We are already working on this but building, reviewing, etc. would > take some time. > > Attached is the minimal fix (extracted from upstream git repository) > we are intending to use in the advisory for those who want to apply a > fix now, please DO NOT use any new certificates before applying fixes. > > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTQxJ1AAoJEJW2GBstM+nsz6AP/2m28eIzuF/JFhyZB7rkLAZR > vP9P0Tu1Vupwd6FN5X9m1O4t5ORhMfn5Y8SuxemHPg8NncaEptg43rs+TED4ucGd > ulyFLJsAZtCDlTTVRAuhp3PfvNllBcoG6a+sWg0qjDqxnzWpPZShCP8ay9g/3q4W > ceYJigXyi7KtKuNlc2YXlC5CA5NpKV9zsc0KhZj/PIq9qLiv+JYUriz1BRE8J+5P > CusO3usNgwHFx0XppMQRXxg/iSYnqs/YM6btENgsOBlRsCJkfSPbxE1z6Vmp0h27 > mOWiBLIOOR97WfYHCUHUHg+1bpJKz6VXUDHbNjjoaaLWg2D4HCkqgm45mgKZBHwh > 6SZUR90WthBbbFwJ3vY+wdARBO1V3RBg64ACZfYEIimqtGKZ5VaJgmYFLZc33RQr > O6Gpt7KeiwxaPYe/18zIiBULKeGBtQXettKpw4KOrkKSfnZePNxQIiqQmzLmfzXW > VwgRYlAAhjmv/ROCdnQJiKQKnloo9xUEPtk1ngmw6ThJJuDGS+Mcm1pWwbvMPF5/ > cWXprDXW4/Hws8GCXbZxYRrC0xQ0zDL+K589H/3pTWV5ijnI/CpM1gzvd0NH/H4+ > LQNILNJ+p2Uhp3D7yoz1bQC8gV2XeXROeNGEuY3VRyNbnv3z65mjWry/4QZo+kp6 > NcKVrUpKLG4odhL7BXBF > =7rU5 > -----END PGP SIGNATURE----- > -------------- next part -------------- > Index: crypto/openssl/ssl/d1_both.c > =================================================================== > --- crypto/openssl/ssl/d1_both.c (revision 264059) > +++ crypto/openssl/ssl/d1_both.c (working copy) > @@ -1458,26 +1458,36 @@ dtls1_process_heartbeat(SSL *s) > unsigned int payload; > unsigned int padding = 16; /* Use minimum padding */ > > + if (s->msg_callback) > + s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, > + &s->s3->rrec.data[0], s->s3->rrec.length, > + s, s->msg_callback_arg); > + > /* Read type and payload length first */ > + if (1 + 2 + 16 > s->s3->rrec.length) > + return 0; /* silently discard */ > hbtype = *p++; > n2s(p, payload); > + if (1 + 2 + payload + 16 > s->s3->rrec.length) > + return 0; /* silently discard per RFC 6520 sec. 4 */ > pl = p; > > - if (s->msg_callback) > - s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, > - &s->s3->rrec.data[0], s->s3->rrec.length, > - s, s->msg_callback_arg); > - > if (hbtype == TLS1_HB_REQUEST) > { > unsigned char *buffer, *bp; > + unsigned int write_length = 1 /* heartbeat type */ + > + 2 /* heartbeat length */ + > + payload + padding; > int r; > > + if (write_length > SSL3_RT_MAX_PLAIN_LENGTH) > + return 0; > + > /* Allocate memory for the response, size is 1 byte > * message type, plus 2 bytes payload length, plus > * payload, plus padding > */ > - buffer = OPENSSL_malloc(1 + 2 + payload + padding); > + buffer = OPENSSL_malloc(write_length); > bp = buffer; > > /* Enter response type, length and copy payload */ > @@ -1488,11 +1498,11 @@ dtls1_process_heartbeat(SSL *s) > /* Random padding */ > RAND_pseudo_bytes(bp, padding); > > - r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + > payload + padding); > + r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, > write_length); > > if (r >= 0 && s->msg_callback) > s->msg_callback(1, s->version, TLS1_RT_HEARTBEAT, > - buffer, 3 + payload + padding, > + buffer, write_length, > s, s->msg_callback_arg); > > OPENSSL_free(buffer); > Index: crypto/openssl/ssl/t1_lib.c > =================================================================== > --- crypto/openssl/ssl/t1_lib.c (revision 264059) > +++ crypto/openssl/ssl/t1_lib.c (working copy) > @@ -2486,16 +2486,20 @@ tls1_process_heartbeat(SSL *s) > unsigned int payload; > unsigned int padding = 16; /* Use minimum padding */ > > + if (s->msg_callback) > + s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, > + &s->s3->rrec.data[0], s->s3->rrec.length, > + s, s->msg_callback_arg); > + > /* Read type and payload length first */ > + if (1 + 2 + 16 > s->s3->rrec.length) > + return 0; /* silently discard */ > hbtype = *p++; > n2s(p, payload); > + if (1 + 2 + payload + 16 > s->s3->rrec.length) > + return 0; /* silently discard per RFC 6520 sec. 4 */ > pl = p; > > - if (s->msg_callback) > - s->msg_callback(0, s->version, TLS1_RT_HEARTBEAT, > - &s->s3->rrec.data[0], s->s3->rrec.length, > - s, s->msg_callback_arg); > - > if (hbtype == TLS1_HB_REQUEST) > { > unsigned char *buffer, *bp; > > ------------------------------ > > Message: 3 > Date: Mon, 07 Apr 2014 22:27:09 -0400 > From: Mike Tancsa > To: d@delphij.net, freebsd-security@freebsd.org > Subject: Re: http://heartbleed.com/ > Message-ID: <53435E7D.5000801@sentex.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 4/7/2014 5:02 PM, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi, Thomas, > > > > On 04/07/14 13:49, Thomas Steen Rasmussen wrote: > >> Hello, > >> > >> http://heartbleed.com/ describes an openssl vulnerability > >> published today. We are going to need an advisory for the openssl > >> in base in FreeBSD 10 and we are also going to need an updated > >> port. > >> > >> The implications of this vulnerability are pretty massive, > >> certificates will need to be replaced and so on. I don't want to > >> repeat the page, so go read that. > > > > We are already working on this but building, reviewing, etc. would > > take some time. > > > > Hi, > The webpage lists > > FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c) > > I take it this is only if you installed from the ports no ? > > ---Mike > > > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ > > > ------------------------------ > > Message: 4 > Date: Mon, 07 Apr 2014 19:29:18 -0700 > From: Xin Li > To: Mike Tancsa , d@delphij.net, > freebsd-security@freebsd.org > Subject: Re: http://heartbleed.com/ > Message-ID: <53435EFE.4010103@delphij.net> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 4/7/14, 7:27 PM, Mike Tancsa wrote: > > On 4/7/2014 5:02 PM, Xin Li wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > >> > >> Hi, Thomas, > >> > >> On 04/07/14 13:49, Thomas Steen Rasmussen wrote: > >>> Hello, > >>> > >>> http://heartbleed.com/ describes an openssl vulnerability > >>> published today. We are going to need an advisory for the > >>> openssl in base in FreeBSD 10 and we are also going to need an > >>> updated port. > >>> > >>> The implications of this vulnerability are pretty massive, > >>> certificates will need to be replaced and so on. I don't want > >>> to repeat the page, so go read that. > >> > >> We are already working on this but building, reviewing, etc. > >> would take some time. > >> > > > > Hi, The webpage lists > > > > FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c) > > > > I take it this is only if you installed from the ports no ? > > That's correct. OpenSSL shipped with the base system in these two > releases are not vulnerable because they don't support the extension. > > Cheers, > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJTQ179AAoJEJW2GBstM+nsIa4P/RAXDidWzc01T2ghX4uNFtod > C2Wd2k2B6i24LcV3PPub6dQjRI9sMxh9Q/7bIqXctThJ41U9s44P7Zvf6T7Xh/LY > YM4FBAFKNiMC+WZsS78pGW6pYIULml66El7sb/G6DNOzjezWlD3MwnPo2S0nibQJ > BDJ0pU3BH0A2rvyDWmF7aAveJtEuFPCCovytadStHiFZk3nKMwdN0ariLVq8JFlU > s5uqf0rWRXuYIIJ2/Fv9XxUHWi0RrvyXojfdPVNIhEppmdswCzxyb+PLOBbWuZZp > 9ma/ELuo8VJmmsP2A0zX2PriejfFtTR7vXP8V3VwP8RvS2YRFH44Bmyllxn2eYYI > HbemABH2A5rCiMbEu32AGX7i1HikWScwKNIEJbK35BEIb9g3UGRFuxeRw9J6mTyd > 44hMRO1YeyHv/nuSQ+g+d+nzB1dBYSq7YbG5UAPs0v+5fbnoPTU/28olKx1br83H > BZdO+y8VUppNnRWL2wvnsbd1M8/nGABNBD9tco9ftlN0jUpFtSXkPEt20JWwZS/l > HiD328EnTJKgB5nllizsCDIgaTDUYMeH6Bf8QJ54t+Cfu6sS1YYCv2/ycu5tKfqv > yRU6ypV82kye/fRBkFj4JwCOXcPozm+9uPAG9bk1355w+EyKmMrba79BvwtQ+uUj > PXJpfmZifPnNDBTXrg2d > =FDDO > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 5 > Date: Mon, 07 Apr 2014 21:41:25 -0500 > From: Bryan Drewery > To: freebsd-security@freebsd.org > Subject: Re: http://heartbleed.com/ > Message-ID: <534361D5.6070109@FreeBSD.org> > Content-Type: text/plain; charset="iso-8859-1" > > On 4/7/2014 3:49 PM, Thomas Steen Rasmussen wrote: > > Hello, > > > > http://heartbleed.com/ describes an openssl vulnerability published > > today. We are going to need an advisory for the openssl in base in > > FreeBSD 10 and we are also going to need an updated port. > > > > The implications of this vulnerability are pretty massive, > > certificates will need to be replaced and so on. I don't want to > > repeat the page, so go read that. > > > > Best regards, > > > > > > /Thomas Steen Rasmussen > > > > ps. there is a bit on the openssl site too: > > https://www.openssl.org/news/secadv_20140407.txt > > The port has been updated. 1.0.1_10 has the fix. > > -- > Regards, > Bryan Drewery > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 553 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140407/07e15f81/attachment-0001.sig > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 > " > > ------------------------------ > > End of freebsd-security Digest, Vol 482, Issue 1 > ************************************************ > From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 01:51:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 825201AE for ; Thu, 10 Apr 2014 01:51:02 +0000 (UTC) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 450521E49 for ; Thu, 10 Apr 2014 01:51:02 +0000 (UTC) Received: by mail-yk0-f169.google.com with SMTP id 142so3000672ykq.28 for ; Wed, 09 Apr 2014 18:51:01 -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=EkD7rGpHyBt6NuGjmQjN8G9FcF5QNsW5JlrCHHADuCE=; b=xP4gnC/qkbN9GxaxAcYct0/EEK9++s5vNZxrZUSgzRm/AOIikYCgjtP8YmpS63nQeD 9nIC0sLEWCT8yo+MLLABWx26YVVRPgJJSqcq+310G90E/6WaYEzgEuXZpXRKr37DV3lN tSjG/16g1kp+npr8ZPqe20VP5b4xJytAjnS1DXcjNkolM7KYJI12dplqa4/9e91V7lIM aE51gATiGd8Ad4ECETtsYlVF6RSJYVsYApYzUtWRRMpPWuemHCr98oZcpunU6mqAeYc2 TXK/9zTcqynKViExFu8Rl1BIY/+OBL+IFEKnpMaZYjY/i0zEu72mpiu2Bq+Ka29bkOR5 2Btg== MIME-Version: 1.0 X-Received: by 10.236.39.242 with SMTP id d78mr18393870yhb.36.1397094661401; Wed, 09 Apr 2014 18:51:01 -0700 (PDT) Received: by 10.170.221.214 with HTTP; Wed, 9 Apr 2014 18:51:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Apr 2014 09:51:01 +0800 Message-ID: Subject: Re: freebsd-security Digest, Vol 481, Issue 2 From: Ke-li Dong To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 01:51:02 -0000 help 2014-04-04 20:00 GMT+08:00 : > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-security digest..." > > > Today's Topics: > > 1. Re: [PATCH] casperd should detach from controlling session > (Pawel Jakub Dawidek) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Apr 2014 16:38:29 +0200 > From: Pawel Jakub Dawidek > To: d@delphij.net > Cc: "freebsd-security@freebsd.org" > Subject: Re: [PATCH] casperd should detach from controlling session > Message-ID: <20140403143828.GA1703@garage.freebsd.pl> > Content-Type: text/plain; charset="us-ascii" > > On Mon, Mar 17, 2014 at 06:09:04PM -0700, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 03/17/14 02:26, Pawel Jakub Dawidek wrote: > > > On Thu, Mar 13, 2014 at 02:08:36PM -0700, Xin Li wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > > >> > > >> Hi, Pawel, > > >> > > >> I have noticed that casperd's child (zygote) would still use > > >> controlling session from parent. This can be observed by running > > >> ps - -ax on systems running casperd, where the child have a > > >> spurious console associated. > > >> > > >> The attached patch would fix it. May I commit it against -HEAD? > > > > > > Hmm, daemon(3) does call setsid(2) already... Are you sure casperd > > > wasn't running with -F? > > > > Oh, sure daemon(3) indeed does setsid(2) but casperd calls it after > > zygote_init() so it has no effect to the zygote process, [...] > > Sorry for dropping the ball. I see the problem now, thanks. > > > [...] maybe something like this instead? > > I like the first patch better. > > > Index: sbin/casperd/casperd.c > > =================================================================== > > - --- sbin/casperd/casperd.c (revision 263272) > > +++ sbin/casperd/casperd.c (working copy) > > @@ -671,9 +671,6 @@ main(int argc, char *argv[]) > > pjdlog_prefix_set("(casperd) "); > > pjdlog_debug_set(debug); > > > > - - if (zygote_init() < 0) > > - - pjdlog_exit(1, "Unable to create zygote process"); > > - - > > pfh = pidfile_open(pidfile, 0600, &otherpid); > > if (pfh == NULL) { > > if (errno == EEXIST) { > > @@ -699,6 +696,9 @@ main(int argc, char *argv[]) > > pjdlog_debug(1, "PID stored in %s.", pidfile); > > } > > > > + if (zygote_init() < 0) > > + pjdlog_exit(1, "Unable to create zygote process"); > > + > > /* > > * Register core services. > > */ > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://mobter.com > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 196 bytes > Desc: not available > URL: < > http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140403/08869005/attachment-0001.sig > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > 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 > " > > ------------------------------ > > End of freebsd-security Digest, Vol 481, Issue 2 > ************************************************ > From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 05:28:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51242D0 for ; Thu, 10 Apr 2014 05:28:21 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 2CEF412C2 for ; Thu, 10 Apr 2014 05:28:19 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 9E6463ADFA for ; Wed, 9 Apr 2014 22:28:09 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Heartbleed, a few naive questions Date: Wed, 09 Apr 2014 22:28:09 -0700 Message-ID: <41616.1397107689@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 05:28:21 -0000 My apologies if the following few naive questions are out of place or off topic here. I do suppose that there might perhaps be other places where such question might perhaps be better put, but many/most/all of those other places appear to be filled, at present, with discussions and comments which are about on par with some of the alien abduction theories relating to MH370. And I would prefer to have a more thoughtful exchange. Thus I come here. Anyway, having read the currently available (and quite detailed) online descriptions of the Heartbleed bug, I am disposed to seek answers to the following few questions: 1) Why does OpenSSL even contain a function called "OPENSSL_malloc"? Does anyone other than me think that it might perhaps have been a better choice to provide only a function called "OPENSSL_calloc"? 2) Not that this would actually have eliminated the bug, but... Was there some compelling reason why space for the "buffer" at issue was allocated via a call to "OPENSSL_malloc", rather than, say, simply being declared as a function-local "auto" char[1+2+65536+padding] ? 3) Not that this would actually have eliminated the bug, but... After making some effort to do so, I have been unable to find any information online which would serve to document the initial state of the blocks of memory allocated by calls to pthread_create(). Would any of you happen to know if said blocks are or, conversely, are not cleared to zeros prior to execution of the created thread(s)? 4) If, as has been suggested in some quarters, the _actual_ size of the heartbeat client-supplied payload may be correctly determined without any reference whatsoever to the _content_ of the request packet, then why is/was it the case that the SSL protocol specified that such packets should contain a payload length specification... a value that, as we all now know, may be spoofed with disasterous consequences? Regards, rfg P.S. Looking just now at the man page for execve(2) I could not help but notice that it neglects to say a single word about the state of the memory comprising the initial page of the (new) execution stack, let alone any additional pages that may be subsequently and automagically added to the execution stack. I, for one, had certainly always hoped and believed that such pages would be pre-initialized by the kernel to all zeros... as opposed, say, to whatever data had been left in those pages by the most recently deceased process(es) that last held them. But in lieu of any explicit statement on the matter within the man page, I am left with a slight uneasy feeling. To be clear, I have no real fear that others might be able to abscond with data left unerased at the demise of my processes, but as a general matter of principal I greatly prefer it if important aspects of behavior are documented. To me, every man page is a contract. From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 06:28:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D363FECD for ; Thu, 10 Apr 2014 06:28:02 +0000 (UTC) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by mx1.freebsd.org (Postfix) with ESMTP id B4C9217C2 for ; Thu, 10 Apr 2014 06:28:02 +0000 (UTC) Received: from [192.168.1.130] ([unknown] [74.109.117.51]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0N3S00ITUV5LP050@vms173009.mailsrvcs.net> for freebsd-security@freebsd.org; Thu, 10 Apr 2014 00:27:22 -0500 (CDT) Message-id: <53462BAE.1000201@argolis.org> Date: Thu, 10 Apr 2014 01:27:10 -0400 From: Matt Piechota User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-version: 1.0 To: Ke-li Dong , freebsd-security@freebsd.org Subject: Re: freebsd-security Digest, Vol 481, Issue 2 References: In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 06:28:02 -0000 On 04/09/2014 09:51 PM, Ke-li Dong wrote: > help > > > 2014-04-04 20:00 GMT+08:00 : > >> Send freebsd-security mailing list submissions to >> freebsd-security@freebsd.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> or, via email, send a message with subject or body 'help' to >> freebsd-security-request@freebsd.org >> You might want to send "help" to freebsd-security-request@freebsd.org (note "request" in the address). This is just getting sent out to all the members. From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 06:29:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D24AFB5 for ; Thu, 10 Apr 2014 06:29:05 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5360D17E5 for ; Thu, 10 Apr 2014 06:29:05 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 877BB13FF7; Wed, 9 Apr 2014 23:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397111344; bh=uLr7gPlANSgrTQVCJxh2r7AwG4ewCaUz1c+vRAH8D/0=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=C0Ha+swFtuaTFewS2JVN4rNawseI1pKpjr6HA4Gzn7uq7Vv8LBkyZWfOqyU6EZuI4 1QTt8KC1bHLE9mHtm3JIr9buBGgWQvvdRVwLJ8cGLdr3Iv4JXIqXwVPe6C8lchdHzu oaLY03NBunsGVqDKcl+oTEnxzKHQ3rHrm2V92SzY= Message-ID: <53463A2E.90905@delphij.net> Date: Wed, 09 Apr 2014 23:29:02 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: Heartbleed, a few naive questions References: <41616.1397107689@server1.tristatelogic.com> In-Reply-To: <41616.1397107689@server1.tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 06:29:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 4/9/14, 10:28 PM, Ronald F. Guilmette wrote: > > My apologies if the following few naive questions are out of place > or off topic here. I do suppose that there might perhaps be other > places where such question might perhaps be better put, but > many/most/all of those other places appear to be filled, at > present, with discussions and comments which are about on par with > some of the alien abduction theories relating to MH370. And I > would prefer to have a more thoughtful exchange. Thus I come > here. > > Anyway, having read the currently available (and quite detailed) > online descriptions of the Heartbleed bug, I am disposed to seek > answers to the following few questions: > > 1) Why does OpenSSL even contain a function called > "OPENSSL_malloc"? Does anyone other than me think that it might > perhaps have been a better choice to provide only a function called > "OPENSSL_calloc"? For this bug, doing calloc() makes no difference. Is doing calloc() a good practice in general? Sometimes it is, sometimes it merely slows things down. > 2) Not that this would actually have eliminated the bug, but... > > Was there some compelling reason why space for the "buffer" at > issue was allocated via a call to "OPENSSL_malloc", rather than, > say, simply being declared as a function-local "auto" > char[1+2+65536+padding] ? Automatic arrays are introduced with C99. By the way, how do you benefit from allocating from stack than from heap for relatively large chunk of memory? > 3) Not that this would actually have eliminated the bug, but... > > After making some effort to do so, I have been unable to find any > information online which would serve to document the initial state > of the blocks of memory allocated by calls to pthread_create(). > Would any of you happen to know if said blocks are or, conversely, > are not cleared to zeros prior to execution of the created > thread(s)? I don't think I understood this question, do you have a code fragment to describe your question? > 4) If, as has been suggested in some quarters, the _actual_ size > of the heartbeat client-supplied payload may be correctly > determined without any reference whatsoever to the _content_ of the > request packet, then why is/was it the case that the SSL protocol > specified that such packets should contain a payload length > specification... a value that, as we all now know, may be spoofed > with disasterous consequences? Do you have any reference here? I'm not an expert in OpenSSL code but looking at the specification, it seems like, without the payload length there is no way to figure out what length the padding is. > Regards, rfg > > > P.S. Looking just now at the man page for execve(2) I could not > help but notice that it neglects to say a single word about the > state of the memory comprising the initial page of the (new) > execution stack, let alone any additional pages that may be > subsequently and automagically added to the execution stack. Upon successful exec*(), the process address space is rebuilt. So no, you can no longer access any memory contents. > I, for one, had certainly always hoped and believed that such pages > would be pre-initialized by the kernel to all zeros... as opposed, > say, to whatever data had been left in those pages by the most > recently deceased process(es) that last held them. But in lieu of > any explicit statement on the matter within the man page, I am left > with a slight uneasy feeling. New pages are always initialized to zeros before access is given to process, this must happen or that by itself is a very serious security issue, because inter-process isolation is broken. Hope this helps. Should you find anything that we need to correct in the manual page to help others please speak up. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTRjouAAoJEJW2GBstM+nsaBUP/3efRvXu6+g37XZvPmJq6Ahm +uHQlZx7RjEP/3StQhNpHGL0BGTKiv5+diSusABOk8brkaw+Ergn7nTXRGRO4TTz 9wWBLcQs0iETsltYXmDSUw+EBJZDPFSjhyiZZTjxi9rzdqyVeIPlE4L5Tfu8dRhC QqO4Ccxh4QA6p3nMVhrh0WNbnvjfBTWNkZERo4w8b4QdwrkyxpnqVq0fwwNyIks1 EJ8u54EE2wAra7EfmaIfPFEELjID9JmlknmLuGE1rAbqW5zYyMU4eVaFHWpMVR1E 1yjJZrj7wGu6wBhM5zp1kh2+9HU7UnB7Xg1VVZjzT7XdkBO2IcftbpxZ6j+3VLM0 H9zwV7+9tMFAcXoOrAuHPhzqmxEImXd88uWxGJ31m0Ke6gPO1HZkc+Hknkaznfpa +W/NOKEKwr8a01renLIm0HhMdSRM/s2iDMFhZg47uCXWNxIqcpaDyJ/wU2vgi+yF OnDpxJ9/OfCcaj2pd8FdR+4mkxAQiwOc1ItSPqOj2pKNVbTNZnbff/z7ATAWI0e3 5aI4OibW7Fm2I5n6UhRePPfmNle+iJL2WXawmolNnvUohtrSwqeznkpvm2kLl3gz c4G+TzbegSn2wVmM2IiRP4tQcYxTuhFPCGnDnH2MfGpaEAMqMZRl5CESeiTjtY1F 8eC8q75ReaBNO95iGge1 =vXk2 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 06:39:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB9D29E for ; Thu, 10 Apr 2014 06:39:30 +0000 (UTC) Received: from eu1sys200aog125.obsmtp.com (eu1sys200aog125.obsmtp.com [207.126.144.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7AF418CC for ; Thu, 10 Apr 2014 06:39:29 +0000 (UTC) Received: from mail-wg0-f48.google.com ([74.125.82.48]) (using TLSv1) by eu1sys200aob125.postini.com ([207.126.147.11]) with SMTP ID DSNKU0Y8hUqknKxUdMgIsNGolsy1VH6bXOQW@postini.com; Thu, 10 Apr 2014 06:39:29 UTC Received: by mail-wg0-f48.google.com with SMTP id l18so3524648wgh.7 for ; Wed, 09 Apr 2014 23:39:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:message-id:to:subject:reply-to :in-reply-to; bh=mAd6zmuoIXrHKKmetZlDA76GPiQpOgnxOEkX/yd4Mrc=; b=FtJRdjGnKSJOmmb7ZD4V4We+5SrqkB4x7zROtyBztg8R9K99pMpXPvpiwQ9jDzzmxS +pcm4U6ZB7PLQULQi5KfR6rNJJhOVwY+F7RYvmEjbm+BvvnRUh4BsCFnu+TzRKAt6b/S 45arM48csKKcmrkRVcE/NdeTrZnXQR7kAvezdkNkQvbuOVumA757rfSkItRUV022ZgcG tqIiZEicZpxivsKXbLHnvIwU6lsF+s0tLpN6CYd+VMYzDB1PLydycMp4+S+MTkCUxDqE DeE7YqDN30aJWhjSCjvy8tHcHelDsm7HT2ifnPXqI444nQUYkj7sDCGb8K1zd4rI7vPn y/qA== X-Gm-Message-State: ALoCoQlSzGnHxvgvB3GxrxLegeXo+MeVXu2C/ex6E/mYGX0tAFtOZYEjxCmZMUnrDZLnokGxViSkTryrfhLUboBvywMq/LF/0hFfQF4jlfFur13PBGszSrvvksW5fdbUeNrYn1z7lmjD8o3dsjoZPC3lGkjZlmqyrA== X-Received: by 10.194.90.107 with SMTP id bv11mr13266620wjb.11.1397111941503; Wed, 09 Apr 2014 23:39:01 -0700 (PDT) X-Received: by 10.194.90.107 with SMTP id bv11mr13266611wjb.11.1397111941381; Wed, 09 Apr 2014 23:39:01 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id dr2sm5068715wid.2.2014.04.09.23.39.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Apr 2014 23:39:00 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6) with ESMTP id s3A6cx6b057731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Apr 2014 07:38:59 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.6/Submit) id s3A6cwxF057730; Thu, 10 Apr 2014 07:38:58 +0100 (BST) (envelope-from mexas) Date: Thu, 10 Apr 2014 07:38:58 +0100 (BST) From: Anton Shterenlikht Message-Id: <201404100638.s3A6cwxF057730@mech-cluster241.men.bris.ac.uk> To: freebsd-security@freebsd.org, lists@rewt.org.uk Subject: Re: Proposal In-Reply-To: <5345C98D.7030907@rewt.org.uk> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mexas@bris.ac.uk List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 06:39:30 -0000 >Date: Wed, 09 Apr 2014 23:28:29 +0100 >From: Joe Holden >To: freebsd-security@freebsd.org >Subject: Re: Proposal > >The problem here is that a workaround wasn't communicated and I suspect >a very small number of religous users actually sub to security@ I do read it. > - also >bare in mmind that the website wasn't updated until a number of hours >after, including rss which I suspect most people use. I don't use rss >I am not trying to undermine the required testing here, but a simple >binary patch via freebsd-update to disable heartbeats would have done in >the interim (who even uses them, or knows about them). not for me. I much prefer a verified security advisory. Anton From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 07:09:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3182CD24 for ; Thu, 10 Apr 2014 07:09:12 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id E682B1B7C for ; Thu, 10 Apr 2014 07:09:11 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E3E066B05; Thu, 10 Apr 2014 07:09:09 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 76406930; Thu, 10 Apr 2014 09:09:10 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Biernacki Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> Date: Thu, 10 Apr 2014 09:09:09 +0200 In-Reply-To: (Pawel Biernacki's message of "Wed, 9 Apr 2014 23:46:35 +0100") Message-ID: <86ioqh7jai.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, Kimmo Paasiala , Walter Hop X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 07:09:12 -0000 Pawel Biernacki writes: > If you want to make an excuse that a build took a long time - it's > really a poor one. If the build cluster is too slow then project need > to acquire a new one. The freebsd-update build is not a normal make buildworld or make release, it's much more complicated than that. > Many of us had very hard time during last 48 hours. I know that when > you fill responsible for something you want to do as much as you can, > but you need to sleep, eat, etc.. If the whole process is to > overwhelming for one person maybe it's time to think about extending > the SO team or reorganising the process of preparing patched releases? > If there is a need of hands, manpower or so why not ask the community > to help? Did you read the part where I said this is mostly single-threaded? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 09:29:19 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2BA8AFE for ; Thu, 10 Apr 2014 09:29:19 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05EDA18D6 for ; Thu, 10 Apr 2014 09:29:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s3A9SrwV053012; Thu, 10 Apr 2014 19:28:55 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 10 Apr 2014 19:28:53 +1000 (EST) From: Ian Smith To: Pawel Biernacki Subject: Re: Proposal In-Reply-To: Message-ID: <20140410183123.L54500@sola.nimnet.asn.au> References: <3g3r546WVbz62Xv@devnoip.rootservice.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org, joeuser@rootservice.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 09:29:19 -0000 On Wed, 9 Apr 2014 19:00:52 +0100, Pawel Biernacki wrote: > On 9 April 2014 17:08, Joe User wrote: > > On 09.04.2014 17:29, Pawel Biernacki wrote: > >> [snip] > >> We need more transparency here. > >> > > > > Please read this and other related threads and you'll understand that > > the FreeBSD-SecTeam had no real chance to react earlier than they did. > > http://seclists.org/oss-sec/2014/q2/22 > > > > In fact, they were realy fast, thanks therefor. Personally, I'm well impressed by the speed (and care) with which this happened, in the by now very well explained course of events. Special thanks to Xin for all the single-threaded work and Dag-Erling for the explanations, though I'm sure there were other willing hands on deck. > Interesting lecture, thank you. But if FreeBSD SO wasn't on the > mentioned list it's an argument for payable position because that can > help developing more efficient social network in the future ;-). That's no argument for a paid SO at all, but seeing a few people banging on how throwing money at such problems could or should help, I'd like to offer a counter argument - off-topic as this whole aspect surely is. In a largely voluntary project such as FreeBSD, or for that matter any number of community volunteer efforts, the introduction of paid staff can - unless handled with extreme sensitivity - be a kiss of death. As soon as there's someone/s whose paid job it is to perform such roles, many of the other, voluntary members of a team such as Security are more likely to tend to sit back and expect or allow the employee to 'do his or her job'. However well-meaning, that's a natural tendency that can often dissipate the collaborative energies of enthusiastic volunteers; I've seen this occur in many once-voluntary organisations over 40 years. As far as I can determine, the Foundation already supports the SO and other senior developers in other useful ways; conference accomodation and travel, access to infrastructure, etc, and provides grants to people for specific projects, including ongoing ones like Release Engineering; this is entirely appropriate and serves to consolidate voluntary energy, not to compete with it. My 2 Yen - I know, not worth much these days - Ian From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 10:00:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7062769 for ; Thu, 10 Apr 2014 10:00:07 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE801BDD for ; Thu, 10 Apr 2014 10:00:07 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 803613ADFA for ; Thu, 10 Apr 2014 03:00:00 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Heartbleed, a few naive questions In-Reply-To: <53463A2E.90905@delphij.net> Date: Thu, 10 Apr 2014 03:00:00 -0700 Message-ID: <42638.1397124000@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:00:07 -0000 In message <53463A2E.90905@delphij.net>, Xin Li wrote: >On 4/9/14, 10:28 PM, Ronald F. Guilmette wrote: >> 1) Why does OpenSSL even contain a function called >> "OPENSSL_malloc"? Does anyone other than me think that it might >> perhaps have been a better choice to provide only a function called >> "OPENSSL_calloc"? > >For this bug, doing calloc() makes no difference. I would very much like to know how you reached that conclusion. I may be wrong in this instance... I have been, on more than one occasion in my lifetime... but I do disagree with your conclusion in this instance. The bug is described in some great detail here: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html What I believe to the the text of the buggy code in question appears to be available here: http://code.woboq.org/crypto/openssl/ssl/d1_both.c.html For the information being leaked to an attacker by this bug, where exactly do _you_ believe it is coming from, if not out of a buffer which has been allocated (out of recycled and non-cleared memory) by the call to OPENSSL_malloc? >Is doing calloc() a >good practice in general? Sometimes it is, sometimes it merely slows >things down. I agree entirely. If data leakage is occurring within the program that I use to crop my vacation pictures, the world will not be terribly the worse for it. but that was not the question I was asking. Rather, I was asking, albeit indirectly, whether a program or library, such as OpenSSL, which is primarily a security-forcused tool, and upon which a significant fraction of online humanity depends for its security, is deserving of a "belt and suspenders" sytle of defensive programming. >> 2) Not that this would actually have eliminated the bug, but... >> >> Was there some compelling reason why space for the "buffer" at >> issue was allocated via a call to "OPENSSL_malloc", rather than, >> say, simply being declared as a function-local "auto" >> char[1+2+65536+padding] ? > >Automatic arrays are introduced with C99. I am sorry that I failed to be clear. My question has/has nothing to do what what you are calling "automatic arrays" and what I would prefer to call "dynamically sized arrays". If you look at the actual code you will see that "padding" is not really a variable quantity. Rather it appears to have a fixed value (16). So the real question I had intended to pose was actually: "Why wasn't space for the buffer obtained by a simple local variable declaration of the following general form?" enum { padding = 16 }; auto char buffer[1+2+65536+padding]; or more simply: auto char buffer[1+2+65536+16]; >By the way, how do you benefit from allocating from stack than from >heap for relatively large chunk of memory? Doing so is unambiguously more efficient, and provides an absolute assurance that the memory will be fully and properly reclaimed at the instant the containing function exits, however just with respect to the security issues alone, I must admit that this might possibly not make any difference at all, specifically in relation to memory leakage of those secrets which belong *to the server itself*. However depending on how (or whether) memory which is allocated to hold execution stacks is pre-zeroed (before being given to a process or a thread) and depending on whether each SSL session gets its own separate thread (and thus also its own private execution stack) allocating buffers out of the stack, rather than out of the (common) process- wide heap might at least prevent leakage of secrets belonging to one client to a different client. (And by the way, it would not be a terribly difficult thing to add to any C compiler a new option that, when used during compilation of select "mission critical" secirity software, would have the effect of generating code for each function that completely zeros at least the statically-sized part of the new stack frame upon entry to the function, or conversely would generate code which would zero the current frame just before function exit. Such an option might be useful when compiling critical security code, such as the OpenSSL library, and if it had been available and used in conjunction with allocation of the problematic buffer on the stack, as I suggested, I believe that those steps, taken together would have eliminated even the possibility of leakage of server-specific secrets. Such an approach might seem extreme to some, but would it have been worse that the current mess the net finds itself in?) >> 3) Not that this would actually have eliminated the bug, but... >> >> After making some effort to do so, I have been unable to find any >> information online which would serve to document the initial state >> of the blocks of memory allocated by calls to pthread_create(). >> Would any of you happen to know if said blocks are or, conversely, >> are not cleared to zeros prior to execution of the created >> thread(s)? > >I don't think I understood this question... I'll try again. A call to pthread_create() causes space to be allocated for an execution stack for the newly created thread. I was asking if that space is cleared to zeros (by pthread_create) before it is handed over to the nely created thread. My hope and belief is that it is, but if it is, that fact does not seem to have made its way into the relevant man page. >> 4) If, as has been suggested in some quarters, the _actual_ size >> of the heartbeat client-supplied payload may be correctly >> determined without any reference whatsoever to the _content_ of the >> request packet, then why is/was it the case that the SSL protocol >> specified that such packets should contain a payload length >> specification... a value that, as we all now know, may be spoofed >> with disasterous consequences? > >Do you have any reference here? I'm not an expert in OpenSSL code but >looking at the specification, it seems like, without the payload >length there is no way to figure out what length the padding is. Please review the detailed description of the bug provided here: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html "Note that the actual length in the SSLv3 record is not checked." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is the crux of the matter. The actual received record is this big: ->.<- Unfortunately however there is a field within the record which says how big it is _alleged_ to be... by the client (aka the attacker). The value within that field can be a lie. It can claim that the received record is actually this big: ->...........................................................<- The problem is that the buggy OpenSSL code believed the lie, rather than believing the actual size of the record it received, which it also had ready access to. My question was about the specification of the SSL protocol. I do wonder why the authors/developers of that protocol engineered it in such a way that a client was even able to lie to the server about how much data he had actually sent. Why was that field even present in the protocol?? It was clearly not needed, since... as is now clear... servers have other (and accurate) ways of deducing the _actual_ lenth of the _actual_ payload. In effect it seems to me that the very design of the protocol may be to blame here. Is the SSL protocol, as currently defined, walking around with a giant "KICK ME" sign taped to its back? The protocol provided the ability... if not to say the outright INVITATION... to lie to the server. Then we all wake up one day and learn that, lo and behold, some nefarious people might actually be doing that. Now, everybody is running around expressing shock and surprise. I'm not sure that I understand that. Having read a couple of explanations of this bug now, the whole thing seems (a) inevitable and (b) fundamentally the fault of the protocol specification itself. And yet various online commentators seem all too ready and willing to lay the blame on the C language itself, almost as if *it* created the flawed protocol, or developed the bad code. >From where I am sitting, nothing could be further from the truth. >> P.S. Looking just now at the man page for execve(2) I could not >> help but notice that it neglects to say a single word about the >> state of the memory comprising the initial page of the (new) >> execution stack... >... >New pages are always initialized to zeros before access is given to >process, Right. My point is that it wouldn't kill anyone to explicitly say that, specifically in the man pages for exec*() and also for brk()/sbrk(). (The latter is relevant to the heap, while the former is relevant to the stack. In both cases, new space is zeroed before being given to the process. These facts are undoubtedly widely known but are nontheless currently UNDOCUMENTED within the relevant FreeBSD man pages. This should be corrected. Worse yet, looking now at my dog-eared copy of IEEE 1003.1-1990 I see that even the official POSIX.1 standard entirely dropped the ball by also and likewise failing to even mention that the stack space given to the new process after a call to exec*() may be relied upon to contain something other than flotsam and jetsum left over from previously demised processes. The fact that the POSIX comittee was guilty of this shameful omission is no excuse for the FreeBSD team to repeat their mistake.) >Hope this helps. Should you find anything that we need to correct in >the manual page to help others please speak up. I just did. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 10:10:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A9E0BC2 for ; Thu, 10 Apr 2014 10:10:22 +0000 (UTC) Received: from mail.carlostrub.ch (319.ch [88.198.108.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDF291D75 for ; Thu, 10 Apr 2014 10:10:20 +0000 (UTC) Received: from c-st.net (localhost [127.0.0.1]) (Authenticated sender: cs@carlostrub.ch) by mail.carlostrub.ch (Postfix) with ESMTPA id 6738B18CC29; Thu, 10 Apr 2014 12:10:10 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/) X-Mailer: OTRS Mail Service (3.3.5) Date: Thu, 10 Apr 2014 12:10:09 +0200 Message-ID: <1397124609.974780.949873937.113568.2@c-st.net> To: Lena@lena.kiev.ua Organization: Carlo Strub From: Carlo Strub In-Reply-To: <20140409084809.GA2661@lena.kiev> References: <20140409084809.GA2661@lena.kiev> <201404082334.s38NYDxr098590@freefall.freebsd.org> <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> Cc: freebsd-security@freebsd.org, mexas@bris.ac.uk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:10:22 -0000 >=20 > SSH is not affected. >=20 SSH is indeed not affected, but I guess you should still consider the secre= t sshd key on your otherwise affected server as burnt, as it might have bee= n in the memory too while an attacker was inspecting it via heartbleed. Bet= ter recreate the secret ssh key and all other secret keys on your server as= well. But, again, the OpenSSH protocol/software per se are not affected.= From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 10:15:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D59CF6B; Thu, 10 Apr 2014 10:15:31 +0000 (UTC) Received: from mx.softlayer.com (mx101.softlayer.com [IPv6:2607:f0d0:1000:b::19:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.softlayer.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C1731DEA; Thu, 10 Apr 2014 10:15:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=softlayer.com; s=ex13; h=MIME-Version:Content-Transfer-Encoding:Content-ID:Content-Type:In-Reply-To:References:Message-ID:Date:Subject:CC:To:From; bh=KPwB/WnmaeBC1tByN6KDIJRRyLoKzLdZzP6o54KnQLU=; b=unSY2PopBMWbedtH5WYfJtt3PL8kYK6t+9kh4J+Ch1YkxiS4ympdJ1YHLAmwPS2rVPIoVdjlrXqFsmI/S1uiAI6TIBba08XgMLAPA8j3WoPuu5km0v82FtfS0lxPt/nxPrZnphLx/2oiw/kc21o+xlNFGD3/rhB5YWWCeedp1Po0PdW62aFwDbWpuqQDK5LdUH0nfB1h+LCcakTenjyEotVBQbFXnurH2k/3P7l0sO+wdw+ripyEoJ/kHhsx3vmI/yftMS3PUlFt38pt42+By1yUPY9B1WUArr0Ul88vr5JwEdYUd73H8VjAIm9codBnIf9F4gG32OfPiPdqXYwp8A==; Received: from mail.softlayer.com by mx.softlayer.com with esmtp (Exim) (envelope-from ) id 1WYC13-000DMT-PM; Thu, 10 Apr 2014 05:15:29 -0500 Received: from SM-CAS151.softlayer.local (172.18.18.38) by SM-TMG152.softlayer.local (172.18.18.52) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 10 Apr 2014 05:15:29 -0500 Received: from SM-DAG155.softlayer.local ([fe80::a8f6:d611:d2d:bfef]) by SM-CAS151.softlayer.local ([fe80::2cad:d6ac:55f7:c0e%10]) with mapi id 14.02.0342.003; Thu, 10 Apr 2014 05:15:29 -0500 From: Cyrus Lopez To: Carlo Strub , "mexas@bris.ac.uk" Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Thread-Topic: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl Thread-Index: AQHPU4NI2s9YPClGnkadErEd6JIZyJsJRiwAgAAHfICAAak+gIAAAXwA Date: Thu, 10 Apr 2014 10:15:28 +0000 Message-ID: References: <20140409084809.GA2661@lena.kiev> <201404082334.s38NYDxr098590@freefall.freebsd.org> <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> <1397124609.974780.949873937.113568.2@c-st.net> In-Reply-To: <1397124609.974780.949873937.113568.2@c-st.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.18.52] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:15:31 -0000 >>=20 >> SSH is not affected. >>=20 >=20 > SSH is indeed not affected, but I guess you should still consider the sec= ret sshd key on your otherwise affected server as burnt, as it might have b= een in the memory too while an attacker was inspecting it via heartbleed. B= etter recreate the secret ssh key and all other secret keys on your server = as well. But, again, the OpenSSH protocol/software per se are not affected. This is incorrect. The heartbleed exploit would have only returned portions= of memory that were under the control of OpenSSL, not general memory used = by other processes on the system. From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 10:47:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 282A517A for ; Thu, 10 Apr 2014 10:47:30 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DDB5B127E for ; Thu, 10 Apr 2014 10:47:29 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id EC7126E9C; Thu, 10 Apr 2014 10:47:27 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 989BEAA4; Thu, 10 Apr 2014 12:47:28 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Joe Holden Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> <5345C98D.7030907@rewt.org.uk> Date: Thu, 10 Apr 2014 12:47:28 +0200 In-Reply-To: <5345C98D.7030907@rewt.org.uk> (Joe Holden's message of "Wed, 09 Apr 2014 23:28:29 +0100") Message-ID: <86bnw95um7.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:47:30 -0000 Joe Holden writes: > IME issues like this need to be patched first, tested later [...] If we'd done that and screwed up, you'd be on the barricades demanding our heads. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 10:59:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 197B263C for ; Thu, 10 Apr 2014 10:59:09 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CF8711368 for ; Thu, 10 Apr 2014 10:59:08 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E76FA6EC9; Thu, 10 Apr 2014 10:59:07 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 91360AB9; Thu, 10 Apr 2014 12:59:08 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Ronald F. Guilmette" Subject: Re: Heartbleed, a few naive questions References: <42638.1397124000@server1.tristatelogic.com> Date: Thu, 10 Apr 2014 12:59:08 +0200 In-Reply-To: <42638.1397124000@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Thu, 10 Apr 2014 03:00:00 -0700") Message-ID: <867g6x5u2r.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:59:09 -0000 "Ronald F. Guilmette" writes: > Xin Li writes: > > For this bug, doing calloc() makes no difference. > I would very much like to know how you reached that conclusion. It's very simple. The explpoit relies on reading past the end of the allocated buffer. Clearing the allocated buffer would not have made any difference. The problem is the size of the buffer, not its contents. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 11:01:19 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4DAD732 for ; Thu, 10 Apr 2014 11:01:19 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6BC11395 for ; Thu, 10 Apr 2014 11:01:19 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id id10so3332505vcb.12 for ; Thu, 10 Apr 2014 04:01:18 -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:cc:content-type :content-transfer-encoding; bh=Kp75rIcmjEHnxJX073ngQogvMaGI4HeWM0HjWyX3VGA=; b=f+N0Xy7+3WYIPz0uLDhln4d6Z13HyOlDsG6yHVzTxNcNzm9ksd/IHB4WSYS/apqpFs Av4mdk6udO0WIwbUDtdoaz0fUtTXfElwgWO1wCrzUGBOPyTCb2n7efl422gyZHdoP2vO 9j7bfCeEhZmG8w3hhuMIx0zaSQY+JtSND7Yy8Z6IvAV5A0rjcyacW9O47E0f8pGzYk0i 3LauHdzSQzJ7QNgtBsgTRYcZVKOcMCrEtUatfpP6Cvx/UcSXdeVxzdotMM1eRg8U5AIK sS5jrCtGjSNO92eoGCxYBf1WX37Gr53U1RW2/6q9tBNvi7IbAXYUdB1EQ6Rc3cWyb7oz K4ww== MIME-Version: 1.0 X-Received: by 10.58.201.5 with SMTP id jw5mr13422892vec.6.1397127678633; Thu, 10 Apr 2014 04:01:18 -0700 (PDT) Received: by 10.221.39.130 with HTTP; Thu, 10 Apr 2014 04:01:18 -0700 (PDT) Date: Thu, 10 Apr 2014 12:01:18 +0100 Message-ID: Subject: Re: Proposal From: Pawel Biernacki To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Kimmo Paasiala , Walter Hop X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:01:20 -0000 On 10 April 2014 08:09, Dag-Erling Sm=C3=B8rgrav wrote: > Pawel Biernacki writes: >> If you want to make an excuse that a build took a long time - it's >> really a poor one. If the build cluster is too slow then project need >> to acquire a new one. > > The freebsd-update build is not a normal make buildworld or make > release, it's much more complicated than that. > So you're telling me that nothing can be done about it? >> Many of us had very hard time during last 48 hours. I know that when >> you fill responsible for something you want to do as much as you can, >> but you need to sleep, eat, etc.. If the whole process is to >> overwhelming for one person maybe it's time to think about extending >> the SO team or reorganising the process of preparing patched releases? >> If there is a need of hands, manpower or so why not ask the community >> to help? > > Did you read the part where I said this is mostly single-threaded? > Yes, but you also wrote: > The best you can hope for is to have someone relieve > you while you eat and sleep. And I don't understand why all of those things need to be single-threaded, since you even mention asking someone from clusteradm@ to help: > Once the builds were ready to go, he moved into a phase where everything > had to happen more or less simultaneously: commit the patches, finalize > the advisory (which contains revision numbers and timestamps), sign it, > then commit the advisory and the patch to the doc tree, update the > relevant portions of the web site, wait for them to propagate (or grab a > passing member of clusteradm@ and have them push it through manually), > and finally mail out the advisory. --=20 One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die= . From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 11:20:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96997B0F for ; Thu, 10 Apr 2014 11:20:08 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5709515C7 for ; Thu, 10 Apr 2014 11:20:08 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 7AFA16EFA; Thu, 10 Apr 2014 11:20:07 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2D038AE0; Thu, 10 Apr 2014 13:20:08 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Biernacki Subject: Re: Proposal References: Date: Thu, 10 Apr 2014 13:20:08 +0200 In-Reply-To: (Pawel Biernacki's message of "Thu, 10 Apr 2014 12:01:18 +0100") Message-ID: <86y4zd4ejb.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, Kimmo Paasiala , Walter Hop X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:20:08 -0000 Pawel Biernacki writes: > Dag-Erling Sm=C3=B8rgrav writes: > > The freebsd-update build is not a normal make buildworld or make > > release, it's much more complicated than that. > So you're telling me that nothing can be done about it? I'm telling you that you're arguing out of ignorance. Publishing an advisory takes time because there are many steps involved. Wishing that all those tasks only take ten minutes each and can be performed in parallel won't make it so. > And I don't understand why all of those things need to be > single-threaded, I've told you, everything needs to be done in a specific order. You can't mail out the advisory before it's published on the web because it contains links to itself. You can't push the advisory to the web site before it's signed. You can't sign it until it's complete. You can't complete it until you've committed the patches, because it contains information about the commits. You can't commit until after the freebsd-update builds have completed and the binary patches have propagated to all the mirrors, because you want the source and binary patches to go out simultaneously. And so on and so forth. Throwing more manpower at the job won't make a difference; in fact, it might slow things down due to the need to communicate and coordinate. Read your Fred Brooks. > since you even mention asking someone from clusteradm@ to help: Yes, I mentioned getting someone from clusteradm@ to run the web update script manually instead of waiting 10 minutes for the next scheduled update. Trust me, that's not a major sticking point in the process. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 11:35:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25E7D1D7 for ; Thu, 10 Apr 2014 11:35:54 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id E4C041768 for ; Thu, 10 Apr 2014 11:35:53 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.11] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N3T00KYC9EO8V80@st11p09mm-asmtp002.mac.com> for freebsd-security@freebsd.org; Thu, 10 Apr 2014 10:35:31 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_2F1E293B-BE63-41EE-BDEF-705BB82C8C8D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: http://heartbleed.com/ From: Kimmo Paasiala In-reply-to: <5344020E.9080001@erdgeist.org> Date: Thu, 10 Apr 2014 13:33:47 +0300 Message-id: <680DECA1-4AD9-4B40-8F82-68E8499C01BB@icloud.com> References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <5343FD71.6030404@sentex.net> <5344020E.9080001@erdgeist.org> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGBEKTEMXGx0EGx0YBBIZBBsSEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsZGmJCH2luGFNtGXhzB xlrGxoZH39jEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxIQGx4aHxsRCl5ZF2FMaEN kEQpMRhdsa2sRCkNaFxISBBsTHwQbGBIEGRkRCkRYFxgRCkRJFxsRCkJFF2Z9fxNNb1xgZRoSE QpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQpCQBdkbn5 wTGdyaxxkbxEKcGgXenNvWExacntjUn4RCnBoF2REWlxlUFpEZmkcEQpwaBdtekVuaVNzGwV6a REKcGgXZgEBXGcBR3pzGmIRCnBoF25yGGRiHkhDf1xiEQpwaxdoaUt+WUxGS3BGAREKcEsXYml yE1hdXGdtU3MRCnBrF2N5AXgFE2NySXhvEQpwbBdtZ24FH2FOYRxbGxE= X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-10_02:2014-04-10,2014-04-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=6 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404100158 Cc: Dirk Engling X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 11:35:54 -0000 --Apple-Mail=_2F1E293B-BE63-41EE-BDEF-705BB82C8C8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 8.4.2014, at 17.05, Dirk Engling wrote: > On 08.04.14 15:45, Mike Tancsa wrote: >=20 >> I am trying to understand the implications of this bug in the >> context of a vulnerable client, connecting to a server that does not >> have this extension. e.g. a client app linked against 1.xx thats >> vulnerable talking to a server that is running something from = RELENG_8 >> in the base (0.9.8.x). Is the server still at risk ? Will the client >> still bleed information ? >=20 > If the adversary is in control of the network and can MITM the > connection, then yes. The client leaks random chunks of up to 64k > memory, and that is for each heartbeat request the server sends. >=20 > erdgeist >=20 Going back to this original report of the vulnerability. Has it been = established with certainty that the attacker would first need MITM = capability to exploit the vulnerability? I=92m asking this because MITM = capability is not something that just any attacker can do. Also if this = is true then it can be argued that the severity of this vulnerabilty has = be greatly exaggerated. -Kimmo --Apple-Mail=_2F1E293B-BE63-41EE-BDEF-705BB82C8C8D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTRnOPAAoJEFvLZC0FWRVpFY0H/3Sek6VeBBJJEoUMyAtCT7i1 XEFOAqW69Qs5n4Frp2psjmjwSxUxJphWgE+/izzYDOfxV76yqDSvNJDAxdZG57gR bjt1ASSCFGuLxIuZ9h8F3PlausBn83M30ycv67g5h/mwKw3lSVmi5FRbELLk2QXu zDjBTKKmzjD5mIp2IjSTlK8WaT5GWPIZh1RMNYGHN161WL097wjfbORMXXfAT3Ys 60dXFxUdv6Fs345z9zy+g4A58/K4FCAfbfGZajdPIQecwPzzBC9um2H1oKPHSDgE 9M5Gnn39i5loRRSGAbpfwRCMS98RdLb45sQQtiSAekFDoFiOBE/CONKY85cMVA0= =cZAw -----END PGP SIGNATURE----- --Apple-Mail=_2F1E293B-BE63-41EE-BDEF-705BB82C8C8D-- From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 12:03:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4C87AA8 for ; Thu, 10 Apr 2014 12:03:04 +0000 (UTC) Received: from mail.carlostrub.ch (319.ch [88.198.108.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A221E1A0A for ; Thu, 10 Apr 2014 12:03:04 +0000 (UTC) Received: from c-st.net (localhost [127.0.0.1]) (Authenticated sender: cs@carlostrub.ch) by mail.carlostrub.ch (Postfix) with ESMTPA id 0F0AF18CC29; Thu, 10 Apr 2014 14:03:01 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:06.openssl X-Powered-BY: OTRS - Open Ticket Request System (http://otrs.org/) X-Mailer: OTRS Mail Service (3.3.5) Date: Thu, 10 Apr 2014 14:03:00 +0200 Message-ID: <1397131380.350083.338453171.113568.2@c-st.net> To: clopez@softlayer.com Organization: Carlo Strub From: Carlo Strub In-Reply-To: References: <20140409084809.GA2661@lena.kiev> <201404082334.s38NYDxr098590@freefall.freebsd.org> <201404090821.s398LMg7020616@mech-cluster241.men.bris.ac.uk> <1397124609.974780.949873937.113568.2@c-st.net> Cc: freebsd-security@freebsd.org, mexas@bris.ac.uk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:03:05 -0000 10/04/2014 12:58 - Cyrus Lopez wrote: >=20 >=20 > >>=20 > >> SSH is not affected. > >>=20 > >=20 > > SSH is indeed not affected, but I guess you should still consider the s= ecret sshd key on your otherwise affected server as burnt, as it might have= been in the memory too while an attacker was inspecting it via heartbleed.= Better recreate the secret ssh key and all other secret keys on your serve= r as well. But, again, the OpenSSH protocol/software per se are not affecte= d. >=20 >=20 > This is incorrect. The heartbleed exploit would have only returned portio= ns of > memory that were under the control of OpenSSL, not general memory used by= other > processes on the system. >=20 >=20 >=20 >=20 Thanks for the update. I wasn't aware of that.= From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 12:40:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DABB33CB for ; Thu, 10 Apr 2014 12:40:01 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id B4CCB1CDA for ; Thu, 10 Apr 2014 12:40:01 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 87A783AE82 for ; Thu, 10 Apr 2014 05:39:55 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Heartbleed, a few naive questions In-Reply-To: <867g6x5u2r.fsf@nine.des.no> Date: Thu, 10 Apr 2014 05:39:55 -0700 Message-ID: <43981.1397133595@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:40:02 -0000 In message <867g6x5u2r.fsf@nine.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: >"Ronald F. Guilmette" writes: >> Xin Li writes: >> > For this bug, doing calloc() makes no difference. >> I would very much like to know how you reached that conclusion. > >It's very simple. The explpoit relies on reading past the end of the >allocated buffer. You're right, of course, and I missed that. My apologies. My other points still stand however, the most important of which is that the protocol definition itself seems to be asking for trouble, and that this bug was/is the almost inevitable outgrowth of an entirely poorly considered bit of the SSL protocol specification. Hummm... In fact, now that I look at the code some more I'm not even sure if my suggestion for using calloc() in place of malloc() throughout OpenSSL was even entirely off the mark... although the exact _place_ where that suggestion might have been most profitably applied is *not* within the dtls1_process_heartbeat() function itself, but rather is wherever the original receive buffer was allocated, i.e. the buffer that is pointed to by s->s3->rrec.data upon entry to the dtls1_process_heartbeat() function. I have not searched the code to find the place where this original packet receive buffer is allocated, however regardless of whereever this allocation takes place I think that it is safe to say that if such buffers were always allocated to the maximum possible size needed (1+2+65536+16) _and_ if they were always obtained via calls to calloc() or its functional equivalent, then there would never have been such a thing as the Heartbleed bug and this conversation would not now be taking place. Does anyone happen to have a copy of the complete original (unpatched) source code lying around? I have a sudden urge to look and see where exactly the buffer corresponding to s->s3->rrec.data is allocated, with an eye to trying to understand why on earth it was ever made shorter than 1+2+65536+16 bytes long. (Well, actually, it appears that these buffers could all have reasonably be allocated to the rather smaller fixed size of 2^14+16 if the OpenSSL authors had actually followed the RFC. See below.) Regards, rfg P.S. Public reports regarding this bug assert that an attacker can gulp down up to 64KB long chunks of one's private data at a time. I have no reason at present to disbelieve those assertions, however if those assertions are true, then that would seem to suggest that in addition to creating a rather awful bug, the implementors of OpenSSL may have also failed to perform range checking on the payload_length values provided within received HeartbeatRequest packets... range checking that is apparently *MANDITORY* in order to simply meet the requirements of the relevant RFC (6520): "The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]." ... "If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently. ^^^^ If the OpenSSL authors had simply bothered to implement the requirements of RFC6520, then it would appear that the worst case data leakage would have been on the order of 16KB(-3) per gulp... still quite an awful bug, but not quite as bad as the one currently making headlines. From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 12:48:03 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CE83856 for ; Thu, 10 Apr 2014 12:48:03 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D64D1DCF for ; Thu, 10 Apr 2014 12:48:03 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id i50so3776403qgf.20 for ; Thu, 10 Apr 2014 05:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=tFI2lG/VcfLAp2Qghfw0R0KnTJNjO8l/4RApMmqF0BM=; b=DWUdNqMWRu7Pf2i9c+V21Ooq9XQqBN2IMCklSUCLJyttFGhDhwBJ7XuX3kB6epXD3g MVFQ/Bdermn+oOiW0BiROl3wMhBH6w+rW0zlNhpmLbGpsLgGjjx25Xj5usaYjl8wbHV5 yv6pmY8f4p/OISIa7Yu6TCBUutRHTQnTId5gutM2Ei3z0wiEhbwV0A2szDKQB+cZ4Bqw 5P/HOhKkpTV9769fBqsQ/vHz7EyrM14kRw6HCRhZAUdbQvZJw6DXeLZwK6L+GCy8gIYJ 9x8ctTb6bR4/5u5TYOZ9LXt0qer2QoiChRXDvJ0CAWV4xuFEw3pvl8fY33vDuHArOh1d Teug== MIME-Version: 1.0 X-Received: by 10.140.105.181 with SMTP id c50mr19144673qgf.17.1397134082318; Thu, 10 Apr 2014 05:48:02 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.88.105 with HTTP; Thu, 10 Apr 2014 05:48:02 -0700 (PDT) In-Reply-To: <680DECA1-4AD9-4B40-8F82-68E8499C01BB@icloud.com> References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <5343FD71.6030404@sentex.net> <5344020E.9080001@erdgeist.org> <680DECA1-4AD9-4B40-8F82-68E8499C01BB@icloud.com> Date: Thu, 10 Apr 2014 08:48:02 -0400 X-Google-Sender-Auth: lmEmQ5haS3ffHUbebvin6hGzv2s Message-ID: Subject: Re: http://heartbleed.com/ From: Ed Maste To: Kimmo Paasiala Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:48:03 -0000 On 10 April 2014 06:33, Kimmo Paasiala wrote: > > Going back to this original report of the vulnerability. Has it been esta= blished with certainty that the attacker would first need MITM capability t= o exploit the vulnerability? I'm asking this because MITM capability is not= something that just any attacker can do. Also if this is true then it can = be argued that the severity of this vulnerabilty has be greatly exaggerated= . No, the attack does not rely on MITM. The vulnerability is available to anyone who can establish a connection. From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 13:48:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 573BC474 for ; Thu, 10 Apr 2014 13:48:17 +0000 (UTC) Received: from mail.koukaam.se (mail.koukaam.se [193.86.201.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.koukaam.se", Issuer "KOUKAAM Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA20D14DA for ; Thu, 10 Apr 2014 13:48:13 +0000 (UTC) Received: from [192.168.1.41] (unassigned-81-90-254-125.ujezd.net [81.90.254.125] (may be forged)) (authenticated bits=0) by mail.koukaam.se (8.14.5/8.14.5) with ESMTP id s3ADdqVM004523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 15:40:02 +0200 (CEST) (envelope-from knezour@weboutsourcing.cz) Message-ID: <53469F27.90509@weboutsourcing.cz> Date: Thu, 10 Apr 2014 15:39:51 +0200 From: Ondra Knezour User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: Heartbleed, a few naive questions References: <42638.1397124000@server1.tristatelogic.com> In-Reply-To: <42638.1397124000@server1.tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 13:48:17 -0000 Dne 10.4.2014 12:00, Ronald F. Guilmette napsal(a): > Rather, I was asking, albeit indirectly, whether a program or > library, such as OpenSSL, which is primarily a security-forcused > tool, and upon which a significant fraction of online humanity > depends for its security, is deserving of a "belt and suspenders" > sytle of defensive programming. > [..] > (And by the way, it would not be a terribly difficult thing to add to > any C compiler a new option that, when used during compilation of > select "mission critical" secirity software, would have the effect of > generating code for each function that completely zeros at least the > statically-sized part of the new stack frame upon entry to the > function, or conversely would generate code which would zero the > current frame just before function exit. Such an option might be > useful when compiling critical security code, such as the OpenSSL > library, and if it had been available and used in conjunction with > allocation of the problematic buffer on the stack, as I suggested, I > believe that those steps, taken together would have eliminated even > the possibility of leakage of server-specific secrets. You can have all those safety nets in the code, functions, compilers, but there will be a day, when some creative person will do some creative "optimization" in name of speed, efficiency, whatever. The compiler is forcing zeroing of buffer on allocation in case of size_of buffer is known on compile time? Let it be size_of int + size_of last_tcp_fragment, yeah, we got them. Following thread comes on my mind all the time reading your message http://www.mail-archive.com/misc@openbsd.org/msg128161.html (I don't know which platforms are refered as slow, but it would be funny if we are talking about architecture of which last machine standing was just moved in museum between the computing and paleolitic departments.) -- Ondra From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 15:25:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28950F95; Thu, 10 Apr 2014 15:25:58 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id E46601040; Thu, 10 Apr 2014 15:25:57 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.11] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N3T00G1ZMV4TJ40@st11p09mm-asmtp002.mac.com>; Thu, 10 Apr 2014 15:25:54 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_D379FA02-4174-493A-AB71-20F9F6F853EE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: http://heartbleed.com/ From: Kimmo Paasiala In-reply-to: Date: Thu, 10 Apr 2014 18:24:24 +0300 Message-id: References: <53430F72.1040307@gibfest.dk> <53431275.4080906@delphij.net> <5343FD71.6030404@sentex.net> <5344020E.9080001@erdgeist.org> <680DECA1-4AD9-4B40-8F82-68E8499C01BB@icloud.com> To: Ed Maste X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHxEKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCHx1SGGZZGXhzB xlrGx8YH1lpEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGx0QGx4aHxsRCl5ZF2FMbFN OEQpMRhdsa2sRCkNaFxISBBsTHwQbGBIEGRkRCkRYFxgRCkRJFxsRCkJFF2Z9fxNNb1xgZRoSE QpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQpCQBdkbn5 wTGdyaxxkbxEKcGgXY0tSfHMbeEliQlwRCnBoF21EUmVHT2hIHntmEQpwaBdtekVuaVNzGwV6a REKcGgXZgEBXGcBR3pzGmIRCnBoF20faUJEGX9fTXwTEQpwfxdtfX5sG1NCZV5PfBEKcGsXYxt MaX4SeBpLEkURCnBLF2JpchNYXVxnbVNzEQpwaxd6Q1tERHJvSUZNXREKcGwXbWduBR9hTmEcW xsRCnBMF2loUwEZYW1AeB5OEQ== X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-10_04:2014-04-10,2014-04-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404100242 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:25:58 -0000 --Apple-Mail=_D379FA02-4174-493A-AB71-20F9F6F853EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 10.4.2014, at 15.48, Ed Maste wrote: > On 10 April 2014 06:33, Kimmo Paasiala wrote: >>=20 >> Going back to this original report of the vulnerability. Has it been = established with certainty that the attacker would first need MITM = capability to exploit the vulnerability? I'm asking this because MITM = capability is not something that just any attacker can do. Also if this = is true then it can be argued that the severity of this vulnerabilty has = be greatly exaggerated. >=20 > No, the attack does not rely on MITM. The vulnerability is available > to anyone who can establish a connection. Yes of course when you now read the description of the problem at = http://heartbleed.com/ it=92s completely clear that the attack can be = done by anyone. Thanks. -Kimmo --Apple-Mail=_D379FA02-4174-493A-AB71-20F9F6F853EE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTRresAAoJEFvLZC0FWRVpjS8H/jbjQV0Q5uC86+1rX7+dOE2z Lc66xiuyqeMuBec6j82p/Yz+xIkWY+M8UhWewMD0i7Fnjy1J64S50BWBAMkeb0CK tO4EjWKo/wvAk8QG7zYYbn8gJY0gQXH6LRJjJgCJFcdC4OeHV8zam6ttYT7GNdGg Y6IjGqaT8r6HVa0d/JGCBVTdx/DsmgOz8bB90tA3IdIaQP5e0FKQrJzknzCo4LVe G+xmZV50I7mrBRsL4SFfh5unZ4e5lDWzcJmuSP3kl8+WpPjv+bpDE0His4B7h1yo 5wNN+XCEktG7cbds3q+883Aatl7d9/odgs8UWcpQGyemPnVzNnbFH0zrS9Cb3Cw= =HfEv -----END PGP SIGNATURE----- --Apple-Mail=_D379FA02-4174-493A-AB71-20F9F6F853EE-- From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 14:56:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 610595A9 for ; Thu, 10 Apr 2014 14:56:42 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35CF81BEB for ; Thu, 10 Apr 2014 14:56:42 +0000 (UTC) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3AEucJN007387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 07:56:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: A different proposal From: Paul Hoffman In-Reply-To: Date: Thu, 10 Apr 2014 07:56:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Thu, 10 Apr 2014 15:29:36 +0000 Cc: Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:56:42 -0000 On Apr 9, 2014, at 3:46 PM, Pawel Biernacki = wrote: > Since such situations had happened in the past and are still > happening, something should be done about them. Quite right. It is reasonable to assume that, given what we now know = about the memory allocation scheme in OpenSSL, that other bugs exist and = will only be found by exploits. Thus, it is reasonable to assume that = there will be future emergencies like Heartbleed related to bugs in = OpenSSL. If your reliance on OpenSSL bugs being fixed requires a fix at a rate = faster than what the FreeBSD community provides, then you should not = rely on the FreeBSD community. Install OpenSSL on your mission-critical = systems from OpenSSL source, not from FreeBSD ports or packages. The = OpenSSL source will always be updated before the FreeBSD community fixes = are released. --Paul Hoffman (who will continue to rely on the FreeBSD community for = OpenSSL, and is in fact terribly grateful for the volunteers who did = this work as quickly as they did)= From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 15:29:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 114B62F4 for ; Thu, 10 Apr 2014 15:29:44 +0000 (UTC) Received: from hermes.aitken.com (hermes.aitken.com [108.44.206.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3B121082 for ; Thu, 10 Apr 2014 15:29:43 +0000 (UTC) Received: by hermes.aitken.com (Postfix, from userid 1001) id 6973C3E749A; Thu, 10 Apr 2014 15:20:39 +0000 (UTC) Date: Thu, 10 Apr 2014 15:20:39 +0000 From: Jeff Aitken To: freebsd-security@freebsd.org Subject: Re: Proposal Message-ID: <20140410152039.GA18467@hermes.aitken.com> References: <86y4zd4ejb.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86y4zd4ejb.fsf@nine.des.no> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 15:29:44 -0000 On Thu, Apr 10, 2014 at 01:20:08PM +0200, Dag-Erling Sm??rgrav wrote: > Throwing more manpower at the job won't make a difference; in fact, it > might slow things down due to the need to communicate and coordinate. You mean 9 women can't make a baby in 1 month?!! On Wed, Apr 09, 2014 at 03:44:53PM -0400, Nathan Dorfman wrote: > While I'm out here drawing fire, I might as well also ask if I'm crazy > to think that it might be a good idea for the base system OpenSSL (and > other third party imports) to just disable any and all non-essential > functionality that can be disabled at compile time? Non-essential > meaning everything not required for the base system to function -- > there's always the ports version if anyone needs more. I see the potential benefit but I think I'm opposed to this idea in general. I don't like having partially-crippled software packages in the base system because it ends up being a lot of work to deal with them. Whether you choose to install port/package over top of the base system version or put it in /usr/local you end up with a number of potential issues. I base this on negative experiences that I've had with sendmail, DNS, and kerberos in the past, to name a few. Just my opinion, YMMV obviously. --Jeff From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 17:03:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E166185; Thu, 10 Apr 2014 17:03:48 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCBFB1A29; Thu, 10 Apr 2014 17:03:46 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so4220339wgg.6 for ; Thu, 10 Apr 2014 10:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=YHvQoVsLs/AQYbf2I8MQSBdUbg7YgH6+2BSzlqcYBfo=; b=Ld6XAMnmDUfGqGEmI+2Aihd5TxpImR067X9i5ONEe/MLHQttjZRcKzfJeJEKOJX8H5 W021q4nXcbBkCqi9Dspb5Sf8SOuWNXBrdWZGxm8zspAJwIIYIa7qu0qo1+qJmWtSDwor aQp6okj++1LfZyM0cThIxqHhoZNvbduYwsOxsHnZbGiYcp+RfG3zPQrsXH01nu4XsIe5 lFdAB+ElhP90+wdUbltuoB3DuRkrDf6REYyBOSNkrvY3eKmualq3rFwzh1xtjSMl2+bo TWroa89cluvQCxMX3qRYTdaTYwMKzx6QbyKiptXQXxdouN0po4/padftxG5pwuqeqnTe nFNg== MIME-Version: 1.0 X-Received: by 10.194.1.242 with SMTP id 18mr16391562wjp.22.1397149425081; Thu, 10 Apr 2014 10:03:45 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Thu, 10 Apr 2014 10:03:45 -0700 (PDT) Date: Thu, 10 Apr 2014 12:03:45 -0500 Message-ID: Subject: MITM attacks against portsnap and freebsd-update From: David Noel To: freebsd-bugs@freebsd.org, freebsd-hackers , freebsd-security@freebsd.org, FreeBSD Questions Mailing List , secteam , Colin Percival Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 17:03:48 -0000 I found a few bugs in portsnap and freebsd-update that I'd like to bring to the community's attention and hopefully recruit people to help fix. I mentioned them to Colin (their author) a few years ago and he agreed that they're issues that need to be addressed, but in the time since neither he nor I have been able to get around to fixing them. I'm hoping that someone reading this is able and willing to pitch in. I've also taken this to secteam@, but no one there's made any progress on them in the past 6 months so I figured it was time to approach the broader community. Surely there's a benevolent sh-savvy hacker out there who has time to take these on. They're pretty simple fixes -- the functionality that's needed exists in the scripts already, it just needs to be reused in a few key places. I also think it would be an appropriate time to discuss retiring portsnap. Problem Summary 1. Both portsnap and freebsd-update extract fetched data prior to its SHA256 verification. The extraction libraries used have a long history of bugs so it's reasonable to assume there might be more. Both freebsd-update and portsnap are run as root. Using a vulnerability in the decompression libraries an attacker who was MITM-capable could compromise any FreeBSD system running portsnap or freebsd-update. 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of mechanism to verify the data prior to processing and mirroring it. Without this, mirrors are open to compromise via methods similar to those found in the client-side scripts (decompression library exploitation). It also means an attacker could feed a mirror a corrupt archive, opening users of that mirror to compromise. 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. 4. The addition of subversion in base makes portsnap redundant. Solution Summary 1. A re-working of the snapshot hashing and hash verification process. 2. The addition of hashing and hash verification code to pmirror.sh. 3. The server-side inclusion of date-stamps, and strict client-side enforcement of expiration policies. 4. Retire portsnap. Details The functions of concern in portsnap.sh are fetch_snapshot(), fetch_update(), and fetch_snapshot_verify(). The lines of concern in pmirror.sh are 99-103, 121-125, 138-149, and 153-157 (using revision 257073). The functions of concern in freebsd-update.sh are fetch_metadata(), fetch_files_premerge(), and fetch_files(). Retiring Portsnap With the inclusion of svnlite in 10 I think the valid question comes up as to whether we really need the portsnap system or whether it could be safely retired. Obviously if the conclusion of that discussion is that we don't need it then these bug fixes would be unnecessary. The reason I see for it to be retired is that subversion allows us to easily and securely check out the ports tree. It's a one-line command: `svn co https://...`. Keeping it up-to-date it is another one-liner: `cd /usr/ports; svn update`. With the inclusion of svnlite in base, the portsnap code and servers acting as mirrors become redundant and seem like a waste of resources. PR's I've avoided filing PR's to give myself, Colin, or secteam@ the chance to fix these bugs first. Since none of us have had the time free to do so and because I'm now sharing these bugs publicly with the list I figure it would be an appropriate time to file PR's for them. MITM attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188429 MITM attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188428 Freeze attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188434 Freeze attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188430 MITM attacks against portsnap mirrors (pmirror.sh): http://www.freebsd.org/cgi/query-pr.cgi?pr=188432 Retiring portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188433 David Noel From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 18:35:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7B84F85; Thu, 10 Apr 2014 18:35:52 +0000 (UTC) Received: from angkar.epipe.com (angkar.epipe.com [IPv6:2a01:4f8:d15:583::2]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 765CF14A1; Thu, 10 Apr 2014 18:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=epipe.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=ufYYIoxOlS+52zd0YEm2Tg3/UWYFm9/js6b0m+ggBPI=; b=VMeybeJMT1rYRzlq9XVlKQrCVEaqfwkpHyn6ErcX24j0r97mJ958Th/JojpLyt387qLf00FBNXamY6wqIJTFpgNR97byP0XIgOwL630g5c0SiryCB5bIeeE2dUz2BWXrk8/ZfzAkh1U5j9IQnf5G4JjLrzlxwngbxOJnnWbDGnY=; Received: by angkar.epipe.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WYJpE-0003Pw-AA; Thu, 10 Apr 2014 18:35:48 +0000 Message-ID: <5346E459.3020207@epipe.com> Date: Thu, 10 Apr 2014 21:35:05 +0300 From: Janne Snabb MIME-Version: 1.0 To: freebsd-ports@freebsd.org, freebsd security Subject: Missing binary package security updates? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 18:35:52 -0000 Hi, I recently started using the new fancy pkgng binary packages on some machines that I maintain. I thought I could save a lot of time as I would not need to keep compiling ports manually any more. Unfortunately it seems that it was not such a good idea: # date Thu Apr 10 21:27:22 EEST 2014 # pkg audit openssl-1.0.1_9 is vulnerable: OpenSSL -- Multiple vulnerabilities - private data exposure CVE: CVE-2014-0076 CVE: CVE-2014-0160 WWW: http://portaudit.FreeBSD.org/5631ae98-be9e-11e3-b5e3-c80aa9043978.html 1 problem(s) in the installed packages found. # pkg upgrade Updating repository catalogue Nothing to do # This is on FreeBSD 8/i386. I think I have noticed binary package updates only about once a week. Is my observation correct? Why such an infrequent update cycle? If there is some real reason to build package updates so rarely, would it be possible to hasten the cycle whenever serious issues like CVE-2014-0160 are found? Right now pkgng binary packages are not really suitable for production use because of lacking essential security updates. (There should be a loud and clear warning about this in the Handbook if it stays this way?) Best Regards, -- Janne Snabb snabb@epipe.com From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 18:33:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF5DBE1F; Thu, 10 Apr 2014 18:33:32 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71B231487; Thu, 10 Apr 2014 18:33:31 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s3AIXUdJ031567; Thu, 10 Apr 2014 13:33:30 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s3AIXU0v031566; Thu, 10 Apr 2014 13:33:30 -0500 (CDT) (envelope-from brooks) Date: Thu, 10 Apr 2014 13:33:30 -0500 From: Brooks Davis To: David Noel Subject: Re: MITM attacks against portsnap and freebsd-update Message-ID: <20140410183330.GB31394@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 10 Apr 2014 19:23:42 +0000 Cc: freebsd-security@freebsd.org, Colin Percival X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 18:33:32 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Trimming the list to -security plus Colin in hopes of reducing the number of partial conversations. Sending to four lists and an alias is a list etiquette violation.] [Also dropping the discussion of replacing portsnap since that is a mostly unrelated discussion.] On Thu, Apr 10, 2014 at 12:03:45PM -0500, David Noel wrote: > Problem Summary >=20 > 1. Both portsnap and freebsd-update extract fetched data prior to its > SHA256 verification. The extraction libraries used have a long history > of bugs so it's reasonable to assume there might be more. Both > freebsd-update and portsnap are run as root. Using a vulnerability in > the decompression libraries an attacker who was MITM-capable could > compromise any FreeBSD system running portsnap or freebsd-update. > 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of > mechanism to verify the data prior to processing and mirroring it. > Without this, mirrors are open to compromise via methods similar to > those found in the client-side scripts (decompression library > exploitation). It also means an attacker could feed a mirror a corrupt > archive, opening users of that mirror to compromise. These seem like serious issues and a verify-first design would have been better. That said, I'm not convinced that a rototil of the protocol and all the associated storage duplication is worth the effort. It's better in my mind to commit one of the patches to sandbox gzip with Capsicum which will protect from everything except filling the disk by denying gunzip the ability to do anything but write to the file opened by the script. That will protect all gzip users. > 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. What do you mean by a freeze attack? I'm not familiar with this term and I didn't find this post, the PRs, or a quick Google search illuminating. -- Brooks --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iKYEARECAGYFAlNG4/pfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtTuQgCbBwNhwz/lP6urDkGC7F1KVlZ4 Er0An3cYneantIfrC4keWX63TrO/5or3 =zDqa -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 19:34:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B32A8E5E for ; Thu, 10 Apr 2014 19:34:56 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB491AA3 for ; Thu, 10 Apr 2014 19:34:56 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id l6so4994032oag.39 for ; Thu, 10 Apr 2014 12:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T6VDsGEXqoTAF5K9H7zTuxRS54dNqlOKNPGyxsY5TOw=; b=sJUyqYAp7LFUkmDQxCO6KGoaOqEzW4OsmRIWT0j+vtlWVFPumnc5v0UKBTajQx3iK0 wivGiBieEwCmXdtj2OrW2EKgTz2+g1dRqAoOrUrRZZyB3rHl8FegitBJHJ+Z9Iv1cvwD OE/zVHx5dDFZcHe5kif06emNPoe50pzcSzCNPQO+tBLW+gxl7ONtbc5VmpfaClpIIELi YEvPilHss2DRURyDkTMBoD1v1Ngmw29Smlzop5/5ZKavplWn3+pnJUETeb4ym95kSr+i xtQQ0DCekn6VCIjNfrdHMNvXIoFpnr9avB0Ej4bJfzXsqWW1/JA/45OvGHBRPH7ZGCZs njnQ== MIME-Version: 1.0 X-Received: by 10.182.28.195 with SMTP id d3mr15707511obh.19.1397158495642; Thu, 10 Apr 2014 12:34:55 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.60.158.106 with HTTP; Thu, 10 Apr 2014 12:34:55 -0700 (PDT) In-Reply-To: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> Date: Thu, 10 Apr 2014 15:34:55 -0400 X-Google-Sender-Auth: C_9tijw8kE_WxYcRX0EdHC77qoY Message-ID: Subject: Re: A different proposal From: Nathan Dorfman To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 19:34:56 -0000 On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrot= e: > If your reliance on OpenSSL bugs being fixed requires a fix at a rate fas= ter than what the FreeBSD community provides, then you should not rely on t= he FreeBSD community. Install OpenSSL on your mission-critical systems from= OpenSSL source, not from FreeBSD ports or packages. I really don't think one needs to go this far. The workaround provided in the original OpenSSL advisory, recompiling with -DOPENSSL_NO_HEARTBEATS, was directly applicable to FreeBSD. For anyone unsure exactly where to effect that option, it was discussed on this very list. Also posted on this list was a working patch containing the actual fix, on Monday afternoon. So yes, if you want a fully tested, reviewed and supported fix, you had to wait, but anyone in desperate need of an immediate fix had options that didn't involve ditching FreeBSD's OpenSSL. -nd. From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 19:37:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FA5FF80 for ; Thu, 10 Apr 2014 19:37:15 +0000 (UTC) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AB3D1AD7 for ; Thu, 10 Apr 2014 19:37:14 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id e16so4952900qcx.13 for ; Thu, 10 Apr 2014 12:37:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=P3Vw2S8zc1Kk/byhbttwnX58INAkoH/XfwtBRbhhL7A=; b=SGECfbbHEKqTwHR39rd2rt+BZ3HlTb/jCinEuEXB3W4xWXGIXImrppEMNMPtmmX6jX D6F1ubi5trlhZsRxP/ikGeXPaUW5Hqp9FVLC+1e20Kxdks//XCMF3h64Uk231/Yta8b/ SyFMltfcgM0clQci3vTDTW7UDwMy5Dh5IcKUEsas6kGqeySwzq5Wz8ON1og8UNKOwxg5 wsfuNiY9jY7ZszFgpNzSP/m1K3VCt1w/+we7gFMXM9yQQ2biBm1b2EXJs2TK1j90EEPa /oW5hbwo64IjMn4mFqJA3cfbPwf+31LVd8RI7kgZ2p7/HHzRKcy30CDuYWsNnG8m4lRx 4hSA== X-Gm-Message-State: ALoCoQl1hh99g6W/HLAU6wXviyA3ThKD3yNmxA3GaANzoL8WOVKvC5gf/CmRo3khK+swcYeuotfY X-Received: by 10.224.92.134 with SMTP id r6mr23593572qam.82.1397158628533; Thu, 10 Apr 2014 12:37:08 -0700 (PDT) MIME-Version: 1.0 Sender: edelkind@episec.com Received: by 10.140.92.167 with HTTP; Thu, 10 Apr 2014 12:36:48 -0700 (PDT) X-Originating-IP: [207.237.190.18] In-Reply-To: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> From: ari edelkind Date: Thu, 10 Apr 2014 15:36:48 -0400 X-Google-Sender-Auth: NafLbuoFAbAOydSmfMgQNrlH2x0 Message-ID: Subject: Re: A different proposal To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 19:37:15 -0000 On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrote: > Quite right. It is reasonable to assume that, given what we now know about > the memory allocation scheme in OpenSSL, that other bugs exist and will > only be found by exploits. Thus, it is reasonable to assume that there will > be future emergencies like Heartbleed related to bugs in OpenSSL. > I'm guessing you read a popular post by Theo de Raadt that's been going around. Sorry, but OpenBSD's bastardized memory allocation scheme would not have solved this; OpenSSL's malloc implementation was not to blame here. Amateurish failure to check the sanity of user-supplied input was to blame. Idiotic, error-prone protocol specifications, written by non-programmers, were to blame. OpenSSL's allocator, in this instance, worked fine -- even if it isn't the optimal choice for all operating systems. If your reliance on OpenSSL bugs being fixed requires a fix at a rate > faster than what the FreeBSD community provides, then you should not rely > on the FreeBSD community. Or just make sure that all of your running services link to the OpenSSL library built from ports. While i'm not exactly thrilled with the prospect of waiting a significant amount of time for a vulnerability in the base distribution to be officially patched, relying on the base system for something like that is a bit like taking a tank to the racetrack. > Install OpenSSL on your mission-critical systems from OpenSSL source, not > from FreeBSD ports or packages. This is a poor idea from a maintenance standpoint. Firstly, the ports system was updated fairly quickly, but aside from that, updating an existing port yourself to download and install the next version is usually a trivial task. And you get package management for free. ari From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 19:52:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A8C16F9; Thu, 10 Apr 2014 19:52:49 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 812051C74; Thu, 10 Apr 2014 19:52:48 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm4so5609092wib.2 for ; Thu, 10 Apr 2014 12:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4r1UqVqZsLVUDL7/xY8t2Jnj6CzvveNipuKJ96mvmq8=; b=yXbuEozr5SWlzGR/rv+TZDuKr+pSQ/z1hmYpCWoHmWQ+KM4311r82XG6NnNW3i1T4Q vymmSHEE2N+K2H2cuwxPlGt/xwYdlzB8EV3ptq6EuOxkRkpBJ129+bjyA7Pjr+/Fp6Wm udsyfFGcYblK8XlW1d2XOxWu+AlIkw7pN042+JilFEdaV83KoAm9jiBGJTz4dmRVkPmk WRuNJ38weHl9SYIT8XUB1CxF/z21DGHnwPQyqun6zWS5/EvBnI9ug1oPRAStkjWgtZvb fZpAIVGPMNJW5gg195VEQd1a4K+bll6OwLw7th3aHzP5R5ZmvwrwUN3cvqP8jZgms2Tm 2few== MIME-Version: 1.0 X-Received: by 10.194.71.164 with SMTP id w4mr16961376wju.0.1397159566709; Thu, 10 Apr 2014 12:52:46 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Thu, 10 Apr 2014 12:52:46 -0700 (PDT) In-Reply-To: <20140410183330.GB31394@lor.one-eyed-alien.net> References: <20140410183330.GB31394@lor.one-eyed-alien.net> Date: Thu, 10 Apr 2014 14:52:46 -0500 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update From: David Noel To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, Colin Percival X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 19:52:49 -0000 > I'm not convinced that a rototil of the protocol and all the associated > storage duplication is worth the effort. As far as portsnap is concerned I'm not convinced that ANY amount of effort is worth it. That is why I was hoping to start a conversation on the possibility of phasing it out. > It's better in my mind to commit one of the patches to sandbox gzip > with Capsicum... Portsnap also passes un-verified files to tar, so that would need to be patched too. > ...which will protect from everything except filling the > disk by denying gunzip the ability to do anything but write to the file > opened by the script. That will protect all gzip users. I agree that what you're proposing is probably the simplest solution, but I'm not convinced that it would guarantee system security. Nothing against Robert Watson, but sandboxes are always being broken out of. There's a history of vulnerabilities in the jail subsystem, isn't it likely that someone some day will find a bug in Capsicum? As unlikely as it seems that someone would be able to pull off a MITM attack, posses a tar or gzip 0day, and also posses a Capsicum 0day, there is -- like Murphy's law -- that old saying* "Any bug that can be exploited will be." *I definitely just made that up, but I do firmly believe it to be true. > What do you mean by a freeze attack? I'm not familiar with this term > and I didn't find this post, the PRs, or a quick Google search > illuminating. Sorry. A freeze attack is similar to a replay attack. In a replay attack an attacker would feed the system an older, exploitable version of the software being updated so that they could break in. A freeze attack is when an attacker feeds the system the same version of the software being updated so that critical updates are not installed. While portsnap and freebsd-update do check to ensure that what's being updated is no older than what's currently on the system they do not check to ensure that what's being updated is not the same version as what's currently installed. -David From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 20:26:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5C89556; Thu, 10 Apr 2014 20:26:02 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E312A10BF; Thu, 10 Apr 2014 20:26:01 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id b13so4522093wgh.5 for ; Thu, 10 Apr 2014 13:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=blGZT05EPQEu+GmhYSlEqW52A1o02gErOHmyj9c5r2w=; b=EClonAUsAe5gXlBlNfh419pJjxYgGUDRiNQOrW4j+MbSEiIHRhiR7Vzqo94JP9Lvef ECosIY8xcZAegw8SQGcA2mrDean/7F8YboBPuyrItvsqbSBZ1H+TWNOQskbB/L5B1Th9 JlqPcDGrIfdHMA5MpKrpSYI5dMmdTNrkz6g6X15GwYLEiiaSFmeODxwMrV5o0JSJhaEx G/EryjjwbiQBp4u2IwvEiCxAYT8v8HIivWThdsJXO7LDH+bRlTGaKU5KYdEZD/vBRBy4 Eg3BtPTNJKgcrDY4ZZYzfhLJYCjH26OD4FNJMS3R1RPXiO/2QPJzc5mROPeEC4lzzCyQ exZw== MIME-Version: 1.0 X-Received: by 10.195.12.33 with SMTP id en1mr16746555wjd.31.1397161560089; Thu, 10 Apr 2014 13:26:00 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Thu, 10 Apr 2014 13:26:00 -0700 (PDT) In-Reply-To: References: <20140410183330.GB31394@lor.one-eyed-alien.net> Date: Thu, 10 Apr 2014 15:26:00 -0500 Message-ID: Subject: Re: MITM attacks against portsnap and freebsd-update From: David Noel To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, bapt@FreeBSD.org, Colin Percival X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:26:02 -0000 On 4/10/14, David Noel wrote: >> I'm not convinced that a rototil of the protocol and all the associated >> storage duplication is worth the effort. > > As far as portsnap is concerned I'm not convinced that ANY amount of > effort is worth it. That is why I was hoping to start a conversation > on the possibility of phasing it out. > >> It's better in my mind to commit one of the patches to sandbox gzip >> with Capsicum... > > Portsnap also passes un-verified files to tar, so that would need to > be patched too. > >> ...which will protect from everything except filling the >> disk by denying gunzip the ability to do anything but write to the file >> opened by the script. That will protect all gzip users. > > I agree that what you're proposing is probably the simplest solution, > but I'm not convinced that it would guarantee system security. Nothing > against Robert Watson, but sandboxes are always being broken out of. > There's a history of vulnerabilities in the jail subsystem, isn't it > likely that someone some day will find a bug in Capsicum? As unlikely > as it seems that someone would be able to pull off a MITM attack, > posses a tar or gzip 0day, and also posses a Capsicum 0day, there is > -- like Murphy's law -- that old saying* "Any bug that can be > exploited will be." > > *I definitely just made that up, but I do firmly believe it to be true. > >> What do you mean by a freeze attack? I'm not familiar with this term >> and I didn't find this post, the PRs, or a quick Google search >> illuminating. > > Sorry. A freeze attack is similar to a replay attack. In a replay > attack an attacker would feed the system an older, exploitable version > of the software being updated so that they could break in. A freeze > attack is when an attacker feeds the system the same version of the > software being updated so that critical updates are not installed. > While portsnap and freebsd-update do check to ensure that what's being > updated is no older than what's currently on the system they do not > check to ensure that what's being updated is not the same version as > what's currently installed. > > -David > A paper I found useful back when I first started digging into portsnap and freebsd-update is titled "Package Management Security" and can be found at ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf. It reviews common attacks against package management systems, analyzes both APT and YUM, and points out a number of flaws in them. Many of the attacks discussed also apply to the design of our ports tree management and binary update systems. A very good read for anyone interested in that sort of thing. Baptiste, this conversation made me think of your work on pkgng (I love it, by the way!), so I thought I'd cc you as well. I don't know how knowledgeable you are about common attack vectors against package management systems so I thought maybe this paper would be of some interest to you. I realize I cut off the first email, so if you're curious and didn't see my initial message you can find it here: http://www.mail-archive.com/freebsd-security@freebsd.org/msg04777.html Regards, David Noel From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 20:05:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 740C7E7E for ; Thu, 10 Apr 2014 20:05:40 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 546151D8A for ; Thu, 10 Apr 2014 20:05:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3AK5dai010367 for ; Thu, 10 Apr 2014 20:05:39 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3AK5dmU010365 for freebsd-security@freebsd.org; Thu, 10 Apr 2014 20:05:39 GMT (envelope-from bdrewery) Received: (qmail 18250 invoked from network); 10 Apr 2014 15:05:38 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Apr 2014 15:05:38 -0500 Message-ID: <5346F98D.6030102@FreeBSD.org> Date: Thu, 10 Apr 2014 15:05:33 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Janne Snabb , freebsd-ports@freebsd.org, freebsd security Subject: Re: Missing binary package security updates? References: <5346E459.3020207@epipe.com> In-Reply-To: <5346E459.3020207@epipe.com> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NHBbLboAnfNiJilJHEDhm9VMCsLtOGhU6" X-Mailman-Approved-At: Thu, 10 Apr 2014 20:37:35 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:05:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NHBbLboAnfNiJilJHEDhm9VMCsLtOGhU6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/10/2014 1:35 PM, Janne Snabb wrote: > Hi, >=20 > I recently started using the new fancy pkgng binary packages on some > machines that I maintain. I thought I could save a lot of time as I > would not need to keep compiling ports manually any more. >=20 > Unfortunately it seems that it was not such a good idea: >=20 > # date > Thu Apr 10 21:27:22 EEST 2014 > # pkg audit > openssl-1.0.1_9 is vulnerable: > OpenSSL -- Multiple vulnerabilities - private data exposure > CVE: CVE-2014-0076 > CVE: CVE-2014-0160 > WWW: http://portaudit.FreeBSD.org/5631ae98-be9e-11e3-b5e3-c80aa9043978.= html >=20 > 1 problem(s) in the installed packages found. > # pkg upgrade > Updating repository catalogue > Nothing to do > # >=20 > This is on FreeBSD 8/i386. >=20 > I think I have noticed binary package updates only about once a week. I= s > my observation correct? Why such an infrequent update cycle? If there i= s > some real reason to build package updates so rarely, would it be > possible to hasten the cycle whenever serious issues like CVE-2014-0160= > are found? (I am involved in building the packages) Yes packages currently start building Tuesday night. It takes until Saturday/Sunday for all release/arch to finish building. As each release/arch is finished the packages are uploaded. I did want to expedite updating this package but was blocked by a number of things. I regret we did not, and will not, have a package available sooner for all release/archs. I have started an internal discussion on building packages more frequently for security updates. >=20 > Right now pkgng binary packages are not really suitable for production > use because of lacking essential security updates. (There should be a > loud and clear warning about this in the Handbook if it stays this way?= ) >=20 > Best Regards, >=20 --=20 Regards, Bryan Drewery --NHBbLboAnfNiJilJHEDhm9VMCsLtOGhU6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRvmNAAoJEDXXcbtuRpfPdHIH/0OLeUDa5/rd2OGRkfzAhYRK 2+iflU9p5JYy0hKYVWo6h8qcjT6Ask/7DkFVYMqoJ1S0YUa07CqpSjWKIfArh4nW aJKm5YORcwwY5RJCcc3+W0ykEvWmB2DlqIPZHXB3Y8TcaC9C2+N4K3eKOp7GUDE/ fNcvTJUBAq/z5JiDNUVmLC1hZXoYeEq+WP1T7jnWYbDBNCkEtzjpchUAnkX7fzbC UsWZSOMsRPpTYmdG9FHmneUVKQOWr8vEPOH7CQdQej9aLn8UhaotDimLQlTfy/K1 KIm6pw4DP+CYOa3uBGdLmMcCxcGOwuEKJsasmO1b7YCyMLOFm8V84Is3gT+qDZQ= =mVxs -----END PGP SIGNATURE----- --NHBbLboAnfNiJilJHEDhm9VMCsLtOGhU6-- From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 20:39:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 050B58A4; Thu, 10 Apr 2014 20:39:51 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D039311E4; Thu, 10 Apr 2014 20:39:50 +0000 (UTC) Received: from [192.168.0.20] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id C2C6D43BA8; Thu, 10 Apr 2014 15:39:29 -0500 (CDT) Message-ID: <53470170.6010401@marino.st> Date: Thu, 10 Apr 2014 22:39:12 +0200 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bryan Drewery , Janne Snabb , freebsd-ports@freebsd.org, freebsd security Subject: Re: Missing binary package security updates? References: <5346E459.3020207@epipe.com> <5346F98D.6030102@FreeBSD.org> In-Reply-To: <5346F98D.6030102@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Apr 2014 20:43:40 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: marino@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:39:51 -0000 On 4/10/2014 22:05, Bryan Drewery wrote: > On 4/10/2014 1:35 PM, Janne Snabb wrote: >> >> I think I have noticed binary package updates only about once a week. Is >> my observation correct? Why such an infrequent update cycle? If there is >> some real reason to build package updates so rarely, would it be >> possible to hasten the cycle whenever serious issues like CVE-2014-0160 >> are found? > > (I am involved in building the packages) > > Yes packages currently start building Tuesday night. It takes until > Saturday/Sunday for all release/arch to finish building. As each > release/arch is finished the packages are uploaded. I think there is also some misconceptions here. There are over 24,000 packages. Even with incremental building, one week's worth of changes forces between 7000 and 15000 packages to rebuild. I assume some people think that touching 300 packages in a week means only 300 packages need to be rebuilt, but the reality is that it's hundreds. Depending on the machines and how many there are, it could take multiple days to make packages for just one platform. If it takes two days and there are 4 platforms to build, that's 8 days right there. So the words "infrequent update cycle" I think is a signal that these parameters aren't understood. (Note, I am not involved in building FreeBSD packages) >> Right now pkgng binary packages are not really suitable for production >> use because of lacking essential security updates. (There should be a >> loud and clear warning about this in the Handbook if it stays this way?) What would make it better? Even if somebody designed a particular vulnerability so important that it merited an out of cycle build (and all the ripples that would cause) it is still looking at 2-3 days cycle, minimum. How many of these security updates are "essential and can't wait 7 days?". heartbleed doesn't happen every day... Depending on what is deemed acceptable, I can't envision how binary packages (a courtesy ultimately) can be made good enough from a security standpoint. John From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 20:40:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46EA594B for ; Thu, 10 Apr 2014 20:40:35 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01A28125E for ; Thu, 10 Apr 2014 20:40:34 +0000 (UTC) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3AKeVjR019765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 13:40:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A different proposal From: Paul Hoffman In-Reply-To: Date: Thu, 10 Apr 2014 13:40:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <86C6A2FD-DA42-425C-9E49-4A959311955F@vpnc.org> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> To: Nathan Dorfman X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Thu, 10 Apr 2014 20:43:51 +0000 Cc: freebsd-security@freebsd.org, Pawel Biernacki X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 20:40:35 -0000 On Apr 10, 2014, at 12:34 PM, Nathan Dorfman wrote: > On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman = wrote: >> If your reliance on OpenSSL bugs being fixed requires a fix at a rate = faster than what the FreeBSD community provides, then you should not = rely on the FreeBSD community. Install OpenSSL on your mission-critical = systems from OpenSSL source, not from FreeBSD ports or packages. >=20 > I really don't think one needs to go this far. The workaround provided > in the original OpenSSL advisory, recompiling with > -DOPENSSL_NO_HEARTBEATS, was directly applicable to FreeBSD. For > anyone unsure exactly where to effect that option, it was discussed on > this very list. Also posted on this list was a working patch > containing the actual fix, on Monday afternoon. That fixed *this* bug; earlier ones took actual patches. > So yes, if you want a fully tested, reviewed and supported fix, you > had to wait, but anyone in desperate need of an immediate fix had > options that didn't involve ditching FreeBSD's OpenSSL. I was not proposing ditching FreeBSD's OpenSSL when the next bug was = found: I was proposing that you switch at your own speed before the next = emergency. And I'm not proposing that's the best thing to do: I'm = certainly not going to, I'm quite happy with the FreeBSD response. This is a different proposal than "someone should get paid to reduce my = security timing issues". It is "I should take responsibility for my = security timing issues". --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 22:28:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22CF553D for ; Thu, 10 Apr 2014 22:28:06 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F41B81BE3 for ; Thu, 10 Apr 2014 22:28:05 +0000 (UTC) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3AMS3B6023093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 10 Apr 2014 15:28:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: A different proposal From: Paul Hoffman In-Reply-To: Date: Thu, 10 Apr 2014 15:28:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Fri, 11 Apr 2014 01:58:40 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 22:28:06 -0000 On Apr 10, 2014, at 12:36 PM, ari edelkind = wrote: > On Thu, Apr 10, 2014 at 10:56 AM, Paul Hoffman wrote: >=20 >> Quite right. It is reasonable to assume that, given what we now know = about >> the memory allocation scheme in OpenSSL, that other bugs exist and = will >> only be found by exploits. Thus, it is reasonable to assume that = there will >> be future emergencies like Heartbleed related to bugs in OpenSSL. >>=20 >=20 > I'm guessing you read a popular post by Theo de Raadt that's been = going > around. Sorry, but OpenBSD's bastardized memory allocation scheme = would > not have solved this; OpenSSL's malloc implementation was not to blame > here. =20 I have heard from others, less interested in self-aggrandizement than = Theo, that OpenSSL's malloc was significantly to blame. I'm not saying = OpenBSD's is better, just that I have heard from multiple sources that = OpenSSL malloc-wrapping both hides some bugs and makes them hard to find = with automated tools. > Amateurish failure to check the sanity of user-supplied input was to > blame. =20 Yes. > Idiotic, error-prone protocol specifications, written by > non-programmers, were to blame. =20 Not in this case. > OpenSSL's allocator, in this instance, > worked fine -- even if it isn't the optimal choice for all operating > systems. Maybe; I'm certainly not in a position to say either way. > If your reliance on OpenSSL bugs being fixed requires a fix at a rate >> faster than what the FreeBSD community provides, then you should not = rely >> on the FreeBSD community. >=20 >=20 > Or just make sure that all of your running services link to the = OpenSSL > library built from ports. While i'm not exactly thrilled with the = prospect > of waiting a significant amount of time for a vulnerability in the = base > distribution to be officially patched, relying on the base system for > something like that is a bit like taking a tank to the racetrack. Updates to ports are inherently slower than patches from the OpenSSL = team. My point is not that either ports or distribution are "too slow" = for everyone: it is that if you are sure you need something faster than = them, there is another option. >> Install OpenSSL on your mission-critical systems from OpenSSL source, = not >> from FreeBSD ports or packages. >=20 >=20 > This is a poor idea from a maintenance standpoint. Firstly, the ports > system was updated fairly quickly, ...but not necessarily quick enough for the people complaining about the = response speed of the FreeBSD team... > but aside from that, updating an > existing port yourself to download and install the next version is = usually > a trivial task. And you get package management for free. Again: the whole point of this thread are people who apparently need = more speed, demanding that someone be paid to make things faster for = them. --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Thu Apr 10 23:38:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB676658 for ; Thu, 10 Apr 2014 23:38:47 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AB6212C4 for ; Thu, 10 Apr 2014 23:38:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3ANclpP076715 for ; Thu, 10 Apr 2014 23:38:47 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3ANckQ0076711 for freebsd-security@freebsd.org; Thu, 10 Apr 2014 23:38:46 GMT (envelope-from bdrewery) Received: (qmail 32872 invoked from network); 10 Apr 2014 18:38:45 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Apr 2014 18:38:45 -0500 Message-ID: <53472B7F.5090001@FreeBSD.org> Date: Thu, 10 Apr 2014 18:38:39 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: David.I.Noel@gmail.com, freebsd-security@freebsd.org, security@FreeBSD.org, Colin Percival Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="912kS9jVUih1hEInUujejB43T7nkUJNab" X-Mailman-Approved-At: Fri, 11 Apr 2014 02:08:35 +0000 Cc: secteam X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 23:38:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --912kS9jVUih1hEInUujejB43T7nkUJNab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/10/2014 12:03 PM, David Noel wrote: > I found a few bugs in portsnap and freebsd-update that I'd like to > bring to the community's attention and hopefully recruit people to > help fix. I mentioned them to Colin (their author) a few years ago and > he agreed that they're issues that need to be addressed, but in the > time since neither he nor I have been able to get around to fixing > them. I'm hoping that someone reading this is able and willing to > pitch in. I've also taken this to secteam@, but no one there's made > any progress on them in the past 6 months so I figured it was time to > approach the broader community. Surely there's a benevolent sh-savvy > hacker out there who has time to take these on. They're pretty simple > fixes -- the functionality that's needed exists in the scripts > already, it just needs to be reused in a few key places. >=20 > I also think it would be an appropriate time to discuss retiring portsn= ap. >=20 [snip] >=20 > With the inclusion of svnlite in 10 I think the valid question comes > up as to whether we really need the portsnap system or whether it > could be safely retired. Obviously if the conclusion of that > discussion is that we don't need it then these bug fixes would be > unnecessary. >=20 > The reason I see for it to be retired is that subversion allows us to > easily and securely check out the ports tree. It's a one-line command: > `svn co https://...`. Keeping it up-to-date it is another one-liner: > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > the portsnap code and servers acting as mirrors become redundant and > seem like a waste of resources. Your report aside, I find portsnap to be far superior in security for ports and users. I wish it knew how to checkout source as well. 1. It only allows a secure checkout. You can't accidentally checkout svn:// or http://. 2. It blows away directories with updates. I've witnessed a trojaned ports checkout before. 'svn update' does not remove unexpected files, nor remove changes. Yes this is a decrease in usability when you've modified the file and want to keep the changes, but you can easily make a wrapper script to merge in your changes, or use SVN if you really want.= 3. SVN too often gets into confusing situations on 'svn update' that require knowledge of how SVN works to resolve the conflict. Even I with my ~10 years of SVN experience I get confused often and frustrated when not even 'svn revert -R dir; svn up dir' will revert to the upstream version (I may have my example off, but that's the point, it's confusing.= ) 4. SVN asks the user to confirm the public key when first using the HTTPS repository. I worry this step will be done poorly by users. 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users= =2E 6. The way we do HTTPS is through mirrors only, if you pick the wrong mirror it's against hard for the user who doesn't know SVN to change to a different mirror. Portsnap already handles mirrors excellently by geo location. Teaching portsnap how to speak SVN, while still behaving the same, may cover my concerns. To be fair SVN does have its advantages: 1. Quicker updates for users. 2. Easier patch generation for PR submission. 3. Similarly, viewing your changes more easily. --=20 Regards, Bryan Drewery --912kS9jVUih1hEInUujejB43T7nkUJNab Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRyt/AAoJEDXXcbtuRpfPphoH/2s+W3l6QA5duWjXTdtSjsCW aG0m/K/Fs/rOw4NJcbTGYLucnxJV001ho6SnSQEPznS8V2zNMEueAnYhQDEj/58O s2RwLC4xdRxEWslOEnvXF+4pYVFH/SI75N7e09n8igPcnWJa/a9pwbluJSNAys+r Y2z8CbQEvsIh0/j/Jo2g4BgQm4cs5WvtoN7Wnk3++19VhRdmWH+/smLT9BGFDINi FbNk26h9prKBgMJs+1Sqgm4KB6UICVE/DByds96OrG+4A4MQYTQDP9hWNrgvySJd VZxJU67GhD+Cu5PmV+ryREFK9RSnCO/R5bs+R7P2zmPD+n+ha2+03QsYFMk3068= =Rh7W -----END PGP SIGNATURE----- --912kS9jVUih1hEInUujejB43T7nkUJNab-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 00:53:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BA14984 for ; Fri, 11 Apr 2014 00:53:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CE161967 for ; Fri, 11 Apr 2014 00:53:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3B0rrsg008341 for ; Fri, 11 Apr 2014 00:53:53 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3B0rrCe008340 for freebsd-security@freebsd.org; Fri, 11 Apr 2014 00:53:53 GMT (envelope-from bdrewery) Received: (qmail 33839 invoked from network); 10 Apr 2014 19:53:52 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 10 Apr 2014 19:53:52 -0500 Message-ID: <53473D1A.6010900@FreeBSD.org> Date: Thu, 10 Apr 2014 19:53:46 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: linux-f10-openssl References: <39203.1397081707@server1.tristatelogic.com> In-Reply-To: <39203.1397081707@server1.tristatelogic.com> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XrV8Tlf2xmJo0pbf2bx8lxvH2xPvJhObi" X-Mailman-Approved-At: Fri, 11 Apr 2014 02:08:52 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 00:53:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XrV8Tlf2xmJo0pbf2bx8lxvH2xPvJhObi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/9/2014 5:15 PM, Ronald F. Guilmette wrote: >=20 > Does this port (linux-f10-openssl) also need to be rebuilt/reinstalled?= >=20 No, but I did just update vuxml to reflect older vulnerabilities it does have. --=20 Regards, Bryan Drewery --XrV8Tlf2xmJo0pbf2bx8lxvH2xPvJhObi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTRz0bAAoJEDXXcbtuRpfPAOUIALQjFi7vay2ArhACcpS1bVp0 LdhzYsfDTw8KKXqD+aHv+Spja3PKiDQ/QSUpRhWjhtXSKiXHVZ5x+oybKTILl+vi IkNenA6Mn5oFBwHiz8SOmK+W45aT9Gb2GhjjnVe6DSDY/4Di/J6QrujSNUiXAUKt dNShOj8tY1rCAs/FzlQSg2abeH2xrGFIW6K8X95B9GrglGEnSlwUcX5hLQ1ZdJrF qcgiwEpg9VZmyCPMbn62AZwI6j9fB4RaNhKaYvpi4CJjbrJXbym1QIxIfICGCo4h /LfDLbrmEjmRmMOuW6/bQdYrIcYJVWIy6rtIYtJHbqIAX6k++rnNNxTZS/5hCBY= =q5XC -----END PGP SIGNATURE----- --XrV8Tlf2xmJo0pbf2bx8lxvH2xPvJhObi-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 05:48:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26BFBED4 for ; Fri, 11 Apr 2014 05:48:30 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D82D16A2 for ; Fri, 11 Apr 2014 05:48:29 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id hr17so3073285lab.4 for ; Thu, 10 Apr 2014 22:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=L8wuIniROSpK1PlTmsUaiwLcJnvpTqFcXl3rLNb/Xz0=; b=EDUYBTm9gCFMHbInTnndEsV3rIcJ1wyfG0qgXEA2dz77RQMsHmUYWtTT5ZbJcQbRAD dp/tr1+qJlXSAr1TzfVY6XKhFITpMUA21nm1Au0+vMgh15Iq4a/MT42JijAgU1h7xUX3 /CLgSPYBzWiOK1izsmObAj82Difw89r56r6mR9bmUdiTsQCQnc1oSiWzY7jSSaSaX7hA 43XrbEmbEzCx2w+T8zOnS5k69bxDCVoF8+XFjZ/zgVSagPb3FWJsFjBNVEfYDF+AVMXF dZatsynL7Q8RgUbiI3B3MHDZaPW9XRRNEeNgv2Q5LO9w/jOJNIYLjghdwH81mSX6joFy l24Q== X-Gm-Message-State: ALoCoQl/5AhmQDsY5rfsXw6gjvvyzt2O8Ttm0SqXggrGzqafE3Q/GtB0bY/fizf4i/RiX40hBd84 X-Received: by 10.152.115.178 with SMTP id jp18mr15105824lab.23.1397195300670; Thu, 10 Apr 2014 22:48:20 -0700 (PDT) MIME-Version: 1.0 Sender: edelkind@episec.com Received: by 10.114.170.194 with HTTP; Thu, 10 Apr 2014 22:48:00 -0700 (PDT) X-Originating-IP: [207.237.190.18] In-Reply-To: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> From: ari edelkind Date: Fri, 11 Apr 2014 01:48:00 -0400 X-Google-Sender-Auth: z8mNwkEe3hoi8iIyWXWOTC_dTA0 Message-ID: Subject: Re: A different proposal To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 05:48:30 -0000 On Thu, Apr 10, 2014 at 6:28 PM, Paul Hoffman wrote: > I have heard from others, less interested in self-aggrandizement than > Theo, that OpenSSL's malloc was significantly to blame. > OpenSSL's simplistic malloc implementation exacerbated the information exposure in this case, so you might well say that it had a hand in the _severity_ of the bug. Depending on your system malloc, using that instead may or may not have yielded any improvement (and in OpenBSD's case, it would have) -- but the cause was an incredibly silly programming bug that had nothing to do with malloc. I'll get to just how silly it was shortly. I'm not saying OpenBSD's is better, > I'll say that: OpenBSD's is better. :) On that note, re-reading my prior mail, i didn't mean to come off as unflattering toward OpenBSD's malloc. They did a pretty good job with it. > Amateurish failure to check the sanity of user-supplied input was to > > blame. > > Yes. > > > Idiotic, error-prone protocol specifications, written by > > non-programmers, were to blame. > > Not in this case. > I'm not sure how you came to this conclusion, but let me explain how i came to mine: The heartbeat protocol structure sits within the SSL3 record. In the code, you know the length of the data at this point. But instead of using the length of this data to determine the size of your payload, the spec _also_ makes the user supply his own length. This practice is error-prone, and i've seen it cause problems before (the SSH2 spec is also full of garbage like this -- in fact, observing a similar protocol in the SSH2 spec is precisely what led me to discover a remote-execution vulnerability in the cryptlib ssh code, circa 2006). Now, the spec tries to make up for this bizarre requirement by telling the programmer to discard the packet if the specified payload length is "too large", but this is essentially passing the buck: if the spec says, "the implementer MUST avoid all memory-related bugs," and the programmer introduces a bug, does this mean the spec authors are absolved because the program is non-compliant? The best way to avoid memory-related bugs is to avoid practices that commonly result in them. The apparent silliness of this bug then comes to a head when you realize that the programmer who introduced the heartbeat bug is the same person who wrote most of the heartbeat RFC. Updates to ports are inherently slower than patches from the OpenSSL team. > My point is not that either ports or distribution are "too slow" for > everyone: it is that if you are sure you need something faster than them, > there is another option. > I didn't claim that the ports update was or will be fast enough for everyone. What i was getting at was that if you want the new version, but a new port hasn't yet been released, you can update the port files in your local ports tree yourself; it takes a rudimentary knowledge of how the port system works. You are, quite literally, installing the most recent version from source (as you suggest), except that you get automatic package management. ari From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 08:46:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 763D1A07 for ; Fri, 11 Apr 2014 08:46:49 +0000 (UTC) Received: from n.0x5.de (n.0x5.de [217.197.85.144]) by mx1.freebsd.org (Postfix) with ESMTP id 32505195E for ; Fri, 11 Apr 2014 08:46:48 +0000 (UTC) Received: by pc5.i.0x5.de (Postfix, from userid 1003) id 3g4t0s6PDvz91C; Fri, 11 Apr 2014 10:38:37 +0200 (CEST) Date: Fri, 11 Apr 2014 10:38:37 +0200 From: Nicolas Rachinsky To: freebsd-security@freebsd.org Subject: freebsd openssh hole? Message-ID: <20140411083837.GA33433@mid.pc5.i.0x5.de> Mail-Followup-To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Powered-by: FreeBSD X-Homepage: http://www.rachinsky.de X-PGP-Keyid: 887BAE72 X-PGP-Fingerprint: 039E 9433 115F BC5F F88D 4524 5092 45C4 887B AE72 X-PGP-Keys: http://www.rachinsky.de/nicolas/gpg/nicolas_rachinsky.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 08:46:49 -0000 Hallo, http://thread.gmane.org/gmane.os.openbsd.tech/35722/focus=35731 confuses me a bit. Should this be taken serious? Nicolas From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 09:03:10 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 369BC95; Fri, 11 Apr 2014 09:03:10 +0000 (UTC) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.233.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB1981B0B; Fri, 11 Apr 2014 09:03:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=three; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Pz2y1Aw4PfEQcnznsy28ozDPG1n0D8E+Snmz3EM2C2k=; b=pjfjdpM84SkfpSdGaODrSLNe93tNVAD2sXpqTiMGQbbJUFxFtu6Jp59H4SJGliv210C7zpRwCCjslE5PCtdy8O6HY+BYeSj7KCbQuhLxQsbGZ96voXG1IUPSO0vUe0XsO3Ia3riTXIYlzvCwhTre33o+lsPCX+fCr7Vhkfc16HjPSL7lgqDXn3inJSmNKB77AspFIFcA1uUhOhoile0L65lHNzQKYDRZctrxG6w/6FgYnmqO1uAzWN5Qb8IIuKGYacNBFHXzzwnfaFh2Z1iW61aDwyoZVfh4d0oRqy9a80HL4VonriuJWd/hnfiI+/jMGa5pMnTGTS1ixNKurU7MmmRQQJRKW7O7fidvLwq2YHzPTuiGfIHsefsDoFRX0YKJUFHInp/onipJqCe5AvNbtKdIE8jSO8XT/NVfXv+TP166oZmqOcjQZNgjk62LmhfhwCEjUARKr6484nNDQUO/2w2J8IBQwOX0aTdqXghDNhw97xxL772wRAX3orydpcpm7vDRzoO+Wwfwm5ROH46y8BkurZCSKfTT4rz2+b7nsWt6rRZHrvYDmFJSFOHKiClG88LXl133uBfuTwqdxlHbE12n55OsQVS0WZoB337Hb/H8pUimhcAZChxbjVgsWvMRedPdLTlP+s00KA7DL5Q0xkBNud9Zah4299x2yxjoqxQ=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.233.66]) by 0.mx.codelabs.ru with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1WYXMZ-0001hU-OV; Fri, 11 Apr 2014 13:03:07 +0400 Date: Fri, 11 Apr 2014 13:03:05 +0400 From: Eygene Ryabinkin To: d@delphij.net Subject: Re: Heartbleed / r264266 / openssl version Message-ID: References: <20140408212917.GA9914@graf.pompo.net> <53447C81.6040106@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fKov5AqTsvseSZ0Z" Content-Disposition: inline In-Reply-To: <53447C81.6040106@delphij.net> Sender: rea@codelabs.ru Cc: Ben Laurie , Thierry Thomas , Bryan Drewery , freebsd-security@FreeBSD.ORG X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 09:03:10 -0000 --fKov5AqTsvseSZ0Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Apr 08, 2014 at 03:47:29PM -0700, Xin Li wrote: > I have done a quick check on Linux systems and found they don't carry > a patchlevel for "openssl" either however they do provide a way to > tell the patchlevel because it's a package. However, they do bump the > date as part of the update. >=20 > What would be the preferable way of representing the patchlevel? We > can do it as part of a EN batch at later time. (Note though, even > without this the user or an application can still use > freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out the > patchlevel for userland). I'd say that it will be good for admins to have just run 'openssl version' to determine which additional patches were applied. Since the current output is 'OpenSSL 1.0.1g-freebsd 7 Apr 2014', we probably can add the list of patches to the end of the string, e.g. making it to be {{{ OpenSSL 1.0.1g-freebsd 7 Apr 2014 patches: FreeBSD SA-14:06, CVE-20XX-NNN, = etc }}} Probably this won't break most users of 'openssl version' output and will give immediate visibility of which additional patches are applied on top of the vendor source. Another option will be to add an extra command-line flag to 'openssl version', but this will be rather non-standard and FreeBSD-specific. More sane option will be to introduce another line into output of 'openssl version -a' and telling people to analyze it. My 2 cents. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --fKov5AqTsvseSZ0Z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iL4EABEKAGYFAlNHr8lfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7PvudAD/fWY6LCvh6CMF1uC4wLNaoLFG xzC1iLT/Bw4NIAhD5L4A/25dIUTmbCYox0C2ZHLs+lRQY5sRXeUtqSaSEzJJHr6S =gYuG -----END PGP SIGNATURE----- --fKov5AqTsvseSZ0Z-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 11:36:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A7E087F for ; Fri, 11 Apr 2014 11:36:40 +0000 (UTC) Received: from dub0-omc3-s11.dub0.hotmail.com (dub0-omc3-s11.dub0.hotmail.com [157.55.2.20]) by mx1.freebsd.org (Postfix) with ESMTP id 20EAE1B09 for ; Fri, 11 Apr 2014 11:36:39 +0000 (UTC) Received: from DUB126-W5 ([157.55.2.7]) by dub0-omc3-s11.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Apr 2014 04:35:33 -0700 X-TMN: [RwG/ng18P9YIAIvDwg8NXNrZn+4MPAZF] X-Originating-Email: [sbremal@hotmail.com] Message-ID: From: To: "freebsd-security@freebsd.org" Subject: CVE-2014-0160? Date: Fri, 11 Apr 2014 11:35:32 +0000 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2014 11:35:33.0326 (UTC) FILETIME=[2641EEE0:01CF557A] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 11:36:40 -0000 Hello=0A= =0A= Could anyone comment this? Worry=2C not to worry=2C upgrade=2C upgrade to w= hat version?=0A= =0A= There are few contradicting information coming out in regards to the check = of my server related to the 'heartbleed' bug:=0A= =0A= 1. http://heartbleed.com/=0A= =0A= ...=0A= Status of different versions:=0A= =0A= --->=A0=A0=A0 OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable=0A= =A0=A0=A0 OpenSSL 1.0.1g is NOT vulnerable=0A= =A0=A0=A0 OpenSSL 1.0.0 branch is NOT vulnerable=0A= =A0=A0=A0 OpenSSL 0.9.8 branch is NOT vulnerable=0A= ...=0A= How about operating systems?=0A= =0A= Some operating system distributions that have shipped with potentially vuln= erable OpenSSL version:=0A= =0A= =A0=A0=A0 Debian Wheezy (stable)=2C OpenSSL 1.0.1e-2+deb7u4=0A= =A0=A0=A0 Ubuntu 12.04.4 LTS=2C OpenSSL 1.0.1-4ubuntu5.11=0A= =A0=A0=A0 CentOS 6.5=2C OpenSSL 1.0.1e-15=0A= =A0=A0=A0 Fedora 18=2C OpenSSL 1.0.1e-4=0A= =A0=A0=A0 OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c = 10 May 2012)=0A= --->=A0=A0=A0 FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013=0A= =A0=A0=A0 NetBSD 5.0.2 (OpenSSL 1.0.1e)=0A= =A0=A0=A0 OpenSUSE 12.2 (OpenSSL 1.0.1c)=0A= =0A= Operating system distribution with versions that are not vulnerable:=0A= =0A= =A0=A0=A0 Debian Squeeze (oldstable)=2C OpenSSL 0.9.8o-4squeeze14=0A= =A0=A0=A0 SUSE Linux Enterprise Server=0A= =A0=A0=A0 FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013=0A= =A0=A0=A0 FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013=0A= --->=A0=A0=A0 FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)= =0A= ...=0A= =0A= 2. lynx -dump -head http://localhost/=0A= =0A= HTTP/1.1 200 OK=0A= Date: Fri=2C 11 Apr 2014 08:10:11 GMT=0A= Server: Apache/2.2.26 (FreeBSD) PHP/5.4.24 SVN/1.7.14 mod_ssl/2.2.26=0A= ---> OpenSSL/1.0.1e-freebsd=0A= DAV/2 mod_python/3.3.1 Python/2.7.6 mod_perl/2.0.8 Perl/v5.16.3=0A= Last-Modified: Wed=2C 12 Feb 2014 13:29:34 GMT=0A= ETag: "278b56-2c-4f235903dcb80"=0A= Accept-Ranges: bytes=0A= Content-Length: 44=0A= Connection: close=0A= Content-Type: text/html=0A= =0A= 3. http://possible.lv/tools/hb/?domain=3Dxxx=0A= =0A= ext 65281 (renegotiation info=2C length=3D1)=0A= ext 00011 (EC point formats=2C length=3D4)=0A= ext 00035 (session ticket=2C length=3D0)=0A= ext 00015 (heartbeat=2C length=3D1) <-- Your server supports heartbeat. Bug= is possible when linking against OpenSSL 1.0.1f or older. Let me check.=0A= Actively checking if CVE-2014-0160 works: Server is vulnerable to all attac= ks tested=2C please upgrade software ASAP.=0A= =0A= 4. pkg audit=0A= =0A= 0 problem(s) in the installed packages found.=0A= =0A= =0A= Cheers=0A= B.=0A= = From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 11:46:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABC59DF9 for ; Fri, 11 Apr 2014 11:46:16 +0000 (UTC) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by mx1.freebsd.org (Postfix) with ESMTP id 36C2B1C1D for ; Fri, 11 Apr 2014 11:46:16 +0000 (UTC) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by strudel.ki.iif.hu (Postfix) with ESMTP id DD6664D4; Fri, 11 Apr 2014 13:46:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 3O4pW73Eei97; Fri, 11 Apr 2014 13:46:10 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id AAD164FD; Fri, 11 Apr 2014 13:46:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id A371B4D4; Fri, 11 Apr 2014 13:46:10 +0200 (CEST) Date: Fri, 11 Apr 2014 13:46:10 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: sbremal@hotmail.com Subject: Re: CVE-2014-0160? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-ID: Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 11:46:16 -0000 On Fri, 11 Apr 2014, sbremal@hotmail.com wrote: > Hello > > Could anyone comment this? Worry, not to worry, upgrade, upgrade to what version? > > There are few contradicting information coming out in regards to the check of my server related to the 'heartbleed' bug: > > 1. http://heartbleed.com/ > > ... > Status of different versions: > > --->    OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable >     OpenSSL 1.0.1g is NOT vulnerable >     OpenSSL 1.0.0 branch is NOT vulnerable >     OpenSSL 0.9.8 branch is NOT vulnerable > ... > How about operating systems? > > Some operating system distributions that have shipped with potentially vulnerable OpenSSL version: > >     Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 >     Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11 >     CentOS 6.5, OpenSSL 1.0.1e-15 >     Fedora 18, OpenSSL 1.0.1e-4 >     OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012) > --->    FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013 >     NetBSD 5.0.2 (OpenSSL 1.0.1e) >     OpenSUSE 12.2 (OpenSSL 1.0.1c) Consult: http://www.freebsd.org/security/advisories.html and http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc > > Operating system distribution with versions that are not vulnerable: > >     Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14 >     SUSE Linux Enterprise Server >     FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013 >     FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013 > --->    FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC) Freebsd ports updated: http://svnweb.freebsd.org/ports/head/security/openssl/ > ... > > 2. lynx -dump -head http://localhost/ > > HTTP/1.1 200 OK > Date: Fri, 11 Apr 2014 08:10:11 GMT > Server: Apache/2.2.26 (FreeBSD) PHP/5.4.24 SVN/1.7.14 mod_ssl/2.2.26 > ---> OpenSSL/1.0.1e-freebsd > DAV/2 mod_python/3.3.1 Python/2.7.6 mod_perl/2.0.8 Perl/v5.16.3 > Last-Modified: Wed, 12 Feb 2014 13:29:34 GMT > ETag: "278b56-2c-4f235903dcb80" > Accept-Ranges: bytes > Content-Length: 44 > Connection: close > Content-Type: text/html > > 3. http://possible.lv/tools/hb/?domain=xxx > > ext 65281 (renegotiation info, length=1) > ext 00011 (EC point formats, length=4) > ext 00035 (session ticket, length=0) > ext 00015 (heartbeat, length=1) <-- Your server supports heartbeat. Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check. > Actively checking if CVE-2014-0160 works: Server is vulnerable to all attacks tested, please upgrade software ASAP. > > 4. pkg audit > > 0 problem(s) in the installed packages found. Probably you use openssl form base system not from packages. > > > Cheers > B. > > _______________________________________________ > 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 Apr 11 12:52:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 035A4D63 for ; Fri, 11 Apr 2014 12:52:29 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4D911501 for ; Fri, 11 Apr 2014 12:52:28 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id ar20so5372579iec.2 for ; Fri, 11 Apr 2014 05:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=R7JWa0lv1hM0h7PaAcTzVeT6YiHY2iJrSwb88IPs4Y8=; b=WyMsQscRmSKQAjgSgMl41lWGXzKAkC8sCCvqxtWX5qOkFVP5WXAklEht1C8M8YPmLp YTbCokrHnTolWm3lASwP5CeVrJJYn7m4IhMf3h6+WPGYw36DmeJ6Vw6xXD/MqNNS2Xck NAN351rLiszsN7Bv0dGwyouOFG+pB8AbPii8M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=R7JWa0lv1hM0h7PaAcTzVeT6YiHY2iJrSwb88IPs4Y8=; b=YqgumWapWj1/14TVv7uDwnPwweryl9jZCw96UQNSCtuReWw+9ila8ZdYeQr7tyGkmH BW7fzKS0d9Qfvw5C210caEXV4jaRRlyRy8XxGnTXrbU4vJcD8udVlOZNEv3IMuOrhvXm p6zi/95u8ovPSxznrA8waTIHY7dHvJPQuWw9NFVpSllVogR6gVPn++fLqohps8pi5XSD +vmg3ETG+ZNLJM4MU7T4sDkzzemnd8OVjNavXm5msMPAqlIwhLdak+x7cL+iAN/Q0aiN QjQ0APc647Z48IV1GH/0pba0XMuVbGKs1Pdx7VwppiS7wo1Q4o65/2s71e4ZFcqNv/RH oQVw== X-Gm-Message-State: ALoCoQnbe30GMhNbtaRUvIjO++sgte1m6LOA8WARmd0YFIo6yY2fWvC95YPeu6AdgrmyLKTbcU/a X-Received: by 10.42.197.129 with SMTP id ek1mr19400201icb.9.1397220748041; Fri, 11 Apr 2014 05:52:28 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id r4sm5579882igh.1.2014.04.11.05.52.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 05:52:27 -0700 (PDT) References: <20140411083837.GA33433@mid.pc5.i.0x5.de> Mime-Version: 1.0 (1.0) In-Reply-To: <20140411083837.GA33433@mid.pc5.i.0x5.de> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-AE72396E-7D80-48FF-BEC3-CD077A7DA58C; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <38001801-0BAC-4DDC-A892-57365B5E56D5@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: freebsd openssh hole? Date: Fri, 11 Apr 2014 08:52:24 -0400 To: Nicolas Rachinsky X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 12:52:29 -0000 --Apple-Mail-AE72396E-7D80-48FF-BEC3-CD077A7DA58C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable What is so confusing about this ? I don't see anything here that would cause worry besides the zealot attitude= s you would typically find in the openbsd community. For them to be so secur= ity conscious and open source but yet not have the decency or common sense t= o mitigate major security concerns among other open source projects leaves q= uite the distasteful essence on my tongue to use any of their software in an= y corporate environment whatsoever. Guess maturity comes in just as many fla= vors as Linux these days. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Apr 11, 2014, at 4:38, Nicolas Rachinsky wrote: >=20 > Hallo, >=20 > http://thread.gmane.org/gmane.os.openbsd.tech/35722/focus=3D35731 > confuses me a bit. >=20 > Should this be taken serious? >=20 > Nicolas > _______________________________________________ > 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= " --Apple-Mail-AE72396E-7D80-48FF-BEC3-CD077A7DA58C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDQxMTEyNTIyNlowIwYJKoZIhvcN AQkEMRYEFDOZSrHUCVsqVxIV4bdTmoCoVcwvMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAs8evN/RwdDKoa+gUeZ1Y eA+KqithfECSm1gmzbSMfHWgKHCGXqSK0ZRt6NZb74PVxchZx+bYOsopLxbv2KSyHMWEVj8ml4Z2 y9QarYlKsQtc7qU5cGv1lk+5V73+9umiAZu19Dhnf5qhMlj+1gN9tgtOQqFp7N6rQC2KcDIKDkky SdodudACB4ZZMNSqG3PP3hvy2Vjy5+E7eHstSFvi4O6KnqYa1JZIUyA5KtSTEDyYGQporG3tsA7o nXLFykp5Z7rilJH5wBvhyuk7rk6vhpuXxUDojocooNVPe5Vf8FLofzBBClBSQFEK/v4wkUKb/tQX +PYEBI8TsCtBPqhyMQAAAAAAAA== --Apple-Mail-AE72396E-7D80-48FF-BEC3-CD077A7DA58C-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 12:54:37 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 633C1E80 for ; Fri, 11 Apr 2014 12:54:37 +0000 (UTC) Received: from dub0-omc3-s30.dub0.hotmail.com (dub0-omc3-s30.dub0.hotmail.com [157.55.2.39]) by mx1.freebsd.org (Postfix) with ESMTP id 07C34153E for ; Fri, 11 Apr 2014 12:54:36 +0000 (UTC) Received: from DUB126-W86 ([157.55.2.9]) by dub0-omc3-s30.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Apr 2014 05:53:29 -0700 X-TMN: [wIVIM942RMRG0jIFPs2lvyc1tMqhyZ+e] X-Originating-Email: [sbremal@hotmail.com] Message-ID: From: To: Mohacsi Janos Subject: RE: CVE-2014-0160? Date: Fri, 11 Apr 2014 12:53:29 +0000 Importance: Normal In-Reply-To: References: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2014 12:53:29.0669 (UTC) FILETIME=[09933F50:01CF5585] Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 12:54:37 -0000 ext 65281 (renegotiation info=2C length=3D1)=0A= ext 00011 (EC point formats=2C length=3D4)=0A= ext 00035 (session ticket=2C length=3D0)=0A= ext 00015 (heartbeat=2C length=3D1) <-- Your server supports heartbeat. Bug= is possible when linking against OpenSSL 1.0.1f or older. Let me check.=0A= Actively checking if CVE-2014-0160 works: Your server appears to be patched= against this bug.=0A= =0A= K=F6sz! =3B-)=0A= =0A= Is there any reason why nightly security patches are not enabled by default= in FreeBSD?=0A= =0A= =0A= Cheers=0A= B.=0A= =0A= ----------------------------------------=0A= > Date: Fri=2C 11 Apr 2014 13:46:10 +0200=0A= > From: mohacsi@niif.hu=0A= > To: sbremal@hotmail.com=0A= > CC: freebsd-security@freebsd.org=0A= > Subject: Re: CVE-2014-0160?=0A= >=0A= >=0A= >=0A= > On Fri=2C 11 Apr 2014=2C sbremal@hotmail.com wrote:=0A= >=0A= >> Hello=0A= >>=0A= >> Could anyone comment this? Worry=2C not to worry=2C upgrade=2C upgrade t= o what version?=0A= >>=0A= >> There are few contradicting information coming out in regards to the che= ck of my server related to the 'heartbleed' bug:=0A= >>=0A= >> 1. http://heartbleed.com/=0A= >>=0A= >> ...=0A= >> Status of different versions:=0A= >>=0A= >> ---> OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable=0A= >> OpenSSL 1.0.1g is NOT vulnerable=0A= >> OpenSSL 1.0.0 branch is NOT vulnerable=0A= >> OpenSSL 0.9.8 branch is NOT vulnerable=0A= >> ...=0A= >> How about operating systems?=0A= >>=0A= >> Some operating system distributions that have shipped with potentially v= ulnerable OpenSSL version:=0A= >>=0A= >> Debian Wheezy (stable)=2C OpenSSL 1.0.1e-2+deb7u4=0A= >> Ubuntu 12.04.4 LTS=2C OpenSSL 1.0.1-4ubuntu5.11=0A= >> CentOS 6.5=2C OpenSSL 1.0.1e-15=0A= >> Fedora 18=2C OpenSSL 1.0.1e-4=0A= >> OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 = May 2012)=0A= >> ---> FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013=0A= >> NetBSD 5.0.2 (OpenSSL 1.0.1e)=0A= >> OpenSUSE 12.2 (OpenSSL 1.0.1c)=0A= >=0A= > Consult:=0A= >=0A= > http://www.freebsd.org/security/advisories.html=0A= > and=0A= > http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc= =0A= >=0A= >=0A= >>=0A= >> Operating system distribution with versions that are not vulnerable:=0A= >>=0A= >> Debian Squeeze (oldstable)=2C OpenSSL 0.9.8o-4squeeze14=0A= >> SUSE Linux Enterprise Server=0A= >> FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013=0A= >> FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013=0A= >> ---> FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)=0A= >=0A= > Freebsd ports updated:=0A= > http://svnweb.freebsd.org/ports/head/security/openssl/=0A= >=0A= >> ...=0A= >>=0A= >> 2. lynx -dump -head http://localhost/=0A= >>=0A= >> HTTP/1.1 200 OK=0A= >> Date: Fri=2C 11 Apr 2014 08:10:11 GMT=0A= >> Server: Apache/2.2.26 (FreeBSD) PHP/5.4.24 SVN/1.7.14 mod_ssl/2.2.26=0A= >> ---> OpenSSL/1.0.1e-freebsd=0A= >> DAV/2 mod_python/3.3.1 Python/2.7.6 mod_perl/2.0.8 Perl/v5.16.3=0A= >> Last-Modified: Wed=2C 12 Feb 2014 13:29:34 GMT=0A= >> ETag: "278b56-2c-4f235903dcb80"=0A= >> Accept-Ranges: bytes=0A= >> Content-Length: 44=0A= >> Connection: close=0A= >> Content-Type: text/html=0A= >>=0A= >> 3. http://possible.lv/tools/hb/?domain=3Dxxx=0A= >>=0A= >> ext 65281 (renegotiation info=2C length=3D1)=0A= >> ext 00011 (EC point formats=2C length=3D4)=0A= >> ext 00035 (session ticket=2C length=3D0)=0A= >> ext 00015 (heartbeat=2C length=3D1) <-- Your server supports heartbeat. = Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check.= =0A= >> Actively checking if CVE-2014-0160 works: Server is vulnerable to all at= tacks tested=2C please upgrade software ASAP.=0A= >>=0A= >> 4. pkg audit=0A= >>=0A= >> 0 problem(s) in the installed packages found.=0A= >=0A= > Probably you use openssl form base system not from packages.=0A= >=0A= >=0A= >>=0A= >>=0A= >> Cheers=0A= >> B.=0A= >>=0A= >> _______________________________________________=0A= >> freebsd-security@freebsd.org mailing list=0A= >> http://lists.freebsd.org/mailman/listinfo/freebsd-security=0A= >> To unsubscribe=2C send any mail to "freebsd-security-unsubscribe@freebsd= .org"=0A= >>=0A= = From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 13:10:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF5EB546 for ; Fri, 11 Apr 2014 13:10:48 +0000 (UTC) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by mx1.freebsd.org (Postfix) with ESMTP id 995CC16FE for ; Fri, 11 Apr 2014 13:10:48 +0000 (UTC) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by strudel.ki.iif.hu (Postfix) with ESMTP id D8D424FD; Fri, 11 Apr 2014 15:10:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id A4PUJpFp6nsK; Fri, 11 Apr 2014 15:10:39 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 77384531; Fri, 11 Apr 2014 15:10:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 6F84D4FD; Fri, 11 Apr 2014 15:10:39 +0200 (CEST) Date: Fri, 11 Apr 2014 15:10:39 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: sbremal@hotmail.com Subject: RE: CVE-2014-0160? In-Reply-To: Message-ID: References: , User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:10:48 -0000 On Fri, 11 Apr 2014, sbremal@hotmail.com wrote: > ext 65281 (renegotiation info, length=1) > ext 00011 (EC point formats, length=4) > ext 00035 (session ticket, length=0) > ext 00015 (heartbeat, length=1) <-- Your server supports heartbeat. Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check. > Actively checking if CVE-2014-0160 works: Your server appears to be patched against this bug. > > Kösz! ;-) > > Is there any reason why nightly security patches are not enabled by default in FreeBSD? Very easy to configure download and notification if you use freebsd-update: Add to /etc/crontab: @daily root /usr/sbin/freebsd-update cron In your daily e-mail log you can see, if any changes happened in the freebsd-update reposity. Then you can decide when to up-date. Regards, Janos Mohacsi From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 13:13:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 068AA83F for ; Fri, 11 Apr 2014 13:13:02 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id C22E017B4 for ; Fri, 11 Apr 2014 13:13:01 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N3V001AUBD5D560@st11p09mm-asmtp001.mac.com> for freebsd-security@freebsd.org; Fri, 11 Apr 2014 13:12:44 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_6788341D-62A9-4D63-9D50-95C54FD54F1F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Re: CVE-2014-0160? From: Kimmo Paasiala In-reply-to: Date: Fri, 11 Apr 2014 16:12:36 +0300 Message-id: References: To: sbremal@hotmail.com X-Mailer: Apple Mail (2.1874) x-icloud-spam-score: 34444444 f=icloud.com; e=icloud.com; is=no; ir=yes; pp=ham; spf=n/a; dkim=n/a; dmarc=n/a; wl=n/a; pwl=n/a; clxs=n/a; clxl=n/a X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGxEKTEMXGx0EGx0YBBIZBBscEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsbGmJCH2lpG2scGXhzB xloGxkbGEMfEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxwQGx4aHxsRCl5ZF2FMcx1 EEQpMRhdsa2sRCkNaFxISBBsTHwQbGBIEGRkRCkRYFxgRCkRJFxgRCkJFF2Z9fxNNb1xgZRoSE QpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQpCQBdlGBl Ea1tzYHlPYhEKcGgXblhDZUBLT2BEYW4RCnBoF2BkXnJBGhJ6TRt8EQpwaBd6bWkbenBMXllrH REKcGgXaHJMXVJCRX15WFgRCnBoF2NiXVABTkBjSU54EQpwaxdif0lbTER9ZRgbBREKcEsXYml yE1hdXGdtU3MRCnBrF2hafhpSeVtyHVJnEQpwbBdtZ24FH2FOYRxbGxE= X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-11_04:2014-04-11,2014-04-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=5 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404110214 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:13:02 -0000 --Apple-Mail=_6788341D-62A9-4D63-9D50-95C54FD54F1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11.4.2014, at 15.53, sbremal@hotmail.com wrote: > ext 65281 (renegotiation info, length=3D1) > ext 00011 (EC point formats, length=3D4) > ext 00035 (session ticket, length=3D0) > ext 00015 (heartbeat, length=3D1) <-- Your server supports heartbeat. = Bug is possible when linking against OpenSSL 1.0.1f or older. Let me = check. > Actively checking if CVE-2014-0160 works: Your server appears to be = patched against this bug. >=20 > K=F6sz! ;-) >=20 > Is there any reason why nightly security patches are not enabled by = default in FreeBSD? >=20 >=20 > Cheers > B. >=20 Why do you make such claim? The security patches are very much = =93enabled=94 (by using your words) in FreeBSD by default. This assuming = that you are in fact aware of the update methods that are available and = how they work. And for the update methods and how they work there=92s a = tremendous amount of information out there, even translated to your = native language in some cases if the language barrier is a problem for = you. -Kimmo --Apple-Mail=_6788341D-62A9-4D63-9D50-95C54FD54F1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTR+pHAAoJEFvLZC0FWRVpeC8H/2TqUD9sGJSnOITspPYASBJZ 6mqH7sTNNZG0GoeYAaIyg5SAhG2pWRBSRrnT7wmWwWbbGDf20rTfyEkfIxwclkbB fRdfMVFKFDNYx2GmZWgAi7XZaZskMRxMIwlgOXGUc2EtluLJdTnHvbqThHgn3xB9 QarWxr61yqfArPkq5by0RvWIXoFMRE3bWevtkrdIwwIfQAVKaNFbhkvE+k6T7K5n lLDnEucvkADuUWUr9t2MKQ7Xd6/lLi2sdjnT24i6TxiQATJiquy/sIsq6unFmgMT rqWME4xJP3nG7Qb4lYSNxiYILbVGT1onxZ0zhvwyBY9OFlQDAL3Dw9c/7fDFngQ= =lXK5 -----END PGP SIGNATURE----- --Apple-Mail=_6788341D-62A9-4D63-9D50-95C54FD54F1F-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 13:28:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6F331FB for ; Fri, 11 Apr 2014 13:28:05 +0000 (UTC) Received: from dub0-omc1-s14.dub0.hotmail.com (dub0-omc1-s14.dub0.hotmail.com [157.55.0.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCDC1968 for ; Fri, 11 Apr 2014 13:28:05 +0000 (UTC) Received: from DUB126-W77 ([157.55.0.237]) by dub0-omc1-s14.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Apr 2014 06:26:58 -0700 X-TMN: [0dkHKhb8OMslnw3Pt8xtFVONN9I0hp0E] X-Originating-Email: [sbremal@hotmail.com] Message-ID: From: To: Kimmo Paasiala Subject: RE: CVE-2014-0160? Date: Fri, 11 Apr 2014 13:26:58 +0000 Importance: Normal In-Reply-To: References: , , , Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2014 13:26:58.0671 (UTC) FILETIME=[B7089FF0:01CF5589] Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 13:28:05 -0000 I receive daily email from the host which normally shows port audits and vu= lnerabilities. However=2C I did not sport anything related to CVE-2014-0160= in this email. I expected the same info comes in this email about the base= system as well.=0A= =0A= How do you normally inform about recent vulnerability in the base system? (= I believe newspaper and TV is not the best way...)=0A= =0A= =0A= Cheers=0A= B.=0A= =0A= ----------------------------------------=0A= > Subject: Re: CVE-2014-0160?=0A= > From: kpaasial@icloud.com=0A= > Date: Fri=2C 11 Apr 2014 16:12:36 +0300=0A= > To: sbremal@hotmail.com=0A= > CC: freebsd-security@freebsd.org=0A= >=0A= >=0A= > On 11.4.2014=2C at 15.53=2C sbremal@hotmail.com wrote:=0A= >=0A= >> ext 65281 (renegotiation info=2C length=3D1)=0A= >> ext 00011 (EC point formats=2C length=3D4)=0A= >> ext 00035 (session ticket=2C length=3D0)=0A= >> ext 00015 (heartbeat=2C length=3D1) <-- Your server supports heartbeat. = Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check.= =0A= >> Actively checking if CVE-2014-0160 works: Your server appears to be patc= hed against this bug.=0A= >>=0A= >> K=F6sz! =3B-)=0A= >>=0A= >> Is there any reason why nightly security patches are not enabled by defa= ult in FreeBSD?=0A= >>=0A= >>=0A= >> Cheers=0A= >> B.=0A= >>=0A= >=0A= > Why do you make such claim? The security patches are very much =93enabled= =94 (by using your words) in FreeBSD by default. This assuming that you are= in fact aware of the update methods that are available and how they work. = And for the update methods and how they work there=92s a tremendous amount = of information out there=2C even translated to your native language in some= cases if the language barrier is a problem for you.=0A= >=0A= > -Kimmo=0A= = From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 16:05:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B559103; Fri, 11 Apr 2014 16:05:49 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBD3C1C00; Fri, 11 Apr 2014 16:05:47 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s3BG5ltK039292; Fri, 11 Apr 2014 11:05:47 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s3BG5lRT039291; Fri, 11 Apr 2014 11:05:47 -0500 (CDT) (envelope-from brooks) Date: Fri, 11 Apr 2014 11:05:47 -0500 From: Brooks Davis To: Bryan Drewery Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] Message-ID: <20140411160547.GA38192@lor.one-eyed-alien.net> References: <53472B7F.5090001@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <53472B7F.5090001@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, secteam , Colin Percival , David.I.Noel@gmail.com, security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:05:49 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 10, 2014 at 06:38:39PM -0500, Bryan Drewery wrote: > On 4/10/2014 12:03 PM, David Noel wrote: > > I found a few bugs in portsnap and freebsd-update that I'd like to > > bring to the community's attention and hopefully recruit people to > > help fix. I mentioned them to Colin (their author) a few years ago and > > he agreed that they're issues that need to be addressed, but in the > > time since neither he nor I have been able to get around to fixing > > them. I'm hoping that someone reading this is able and willing to > > pitch in. I've also taken this to secteam@, but no one there's made > > any progress on them in the past 6 months so I figured it was time to > > approach the broader community. Surely there's a benevolent sh-savvy > > hacker out there who has time to take these on. They're pretty simple > > fixes -- the functionality that's needed exists in the scripts > > already, it just needs to be reused in a few key places. > >=20 > > I also think it would be an appropriate time to discuss retiring portsn= ap. > >=20 >=20 > [snip] >=20 > >=20 > > With the inclusion of svnlite in 10 I think the valid question comes > > up as to whether we really need the portsnap system or whether it > > could be safely retired. Obviously if the conclusion of that > > discussion is that we don't need it then these bug fixes would be > > unnecessary. > >=20 > > The reason I see for it to be retired is that subversion allows us to > > easily and securely check out the ports tree. It's a one-line command: > > `svn co https://...`. Keeping it up-to-date it is another one-liner: > > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > > the portsnap code and servers acting as mirrors become redundant and > > seem like a waste of resources. >=20 > Your report aside, I find portsnap to be far superior in security for > ports and users. I wish it knew how to checkout source as well. >=20 > 1. It only allows a secure checkout. You can't accidentally checkout > svn:// or http://. > 2. It blows away directories with updates. I've witnessed a trojaned > ports checkout before. 'svn update' does not remove unexpected files, > nor remove changes. Yes this is a decrease in usability when you've > modified the file and want to keep the changes, but you can easily make > a wrapper script to merge in your changes, or use SVN if you really want. > 3. SVN too often gets into confusing situations on 'svn update' that > require knowledge of how SVN works to resolve the conflict. Even I with > my ~10 years of SVN experience I get confused often and frustrated when > not even 'svn revert -R dir; svn up dir' will revert to the upstream > version (I may have my example off, but that's the point, it's confusing.) > 4. SVN asks the user to confirm the public key when first using the > HTTPS repository. I worry this step will be done poorly by users. > 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users. > 6. The way we do HTTPS is through mirrors only, if you pick the wrong > mirror it's against hard for the user who doesn't know SVN to change to > a different mirror. Portsnap already handles mirrors excellently by geo > location. >=20 > Teaching portsnap how to speak SVN, while still behaving the same, may > cover my concerns. >=20 > To be fair SVN does have its advantages: >=20 > 1. Quicker updates for users. > 2. Easier patch generation for PR submission. > 3. Similarly, viewing your changes more easily. I agree with your analysis. For systems where I'm not developing ports=20 I much prefer portsnap. I'd also add that SVN has limited integrity =20 insurance so even if you verify the certificate you're relying exclusively on SSL/TLS to ensure correct transmission. This year alone much less the whole history of SSL implementations suggests this isn't the best place to put a single point of failure. -- Brooks --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iKYEARECAGYFAlNIEtpfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDY1NUQ1MTlDMjZBNzgyRTcyNTI5OUJGMDVE OEU4QkU5RjIzODFBRDQACgkQXY6L6fI4GtTxSgCgu9oP6xhumbyu2xlFLLGbeUYg m24AnjXpLDUOSLqZH8UIzOGfUaNcKeK/ =xreO -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 16:08:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E94A4EC; Fri, 11 Apr 2014 16:08:27 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3B3A1C51; Fri, 11 Apr 2014 16:08:25 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so5638573wgh.27 for ; Fri, 11 Apr 2014 09:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CqSMelqTORavYfflG3kn+1HnOsNSkNL4JbrZSZu2+3U=; b=SizQxK/yE7ckERzn2FHiAbnF4fhrj9kd1JiNfeRxg49jQM22UsBngYttfdvH/5uVBX YHCdqEFC+0YOz0wgmhYLpqbNHD+iiIdb65c/LPL18G2POKXWANUAcUvZfugKjhcr7Zyu bCcwSnLPBOilaMUkH91CKlOdHMsfqvD9gix69mGWjTxoNWnQtLKhfEqavC0/rqsebSMw jyPAxvFrufrTL+v2FYWGMIx6p703jDVRHgOoxwqzBWHYh+VR8rBZhoMzPjBi27cplG6D SIFlHsuD5tDgZ/CyG8t0pzLVa15hJ1nmTRmBP34DHhMtCSvSjNR1Ad8eos93fNxg8XKo NSoQ== MIME-Version: 1.0 X-Received: by 10.194.94.39 with SMTP id cz7mr1378875wjb.78.1397232504044; Fri, 11 Apr 2014 09:08:24 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Fri, 11 Apr 2014 09:08:23 -0700 (PDT) In-Reply-To: <53472B7F.5090001@FreeBSD.org> References: <53472B7F.5090001@FreeBSD.org> Date: Fri, 11 Apr 2014 11:08:23 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, secteam , Colin Percival , security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:08:27 -0000 > Your report aside, I find portsnap to be far superior in security for > ports and users. If you look at the portsnap build code you'll see that the first thing portsnap does is pull the ports tree from Subversion. It uses the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh the entire ports archive is exposed to corruption right from the start. > I wish it knew how to checkout source as well. Aside from the fact that anyone sitting on a hop between svn.freebsd.org and the portsnap build server could MITM the entire ports tree, the main problem here is that the source would have to come from version control, and the version control system used by the FreeBSD project is Subversion. If you distrust Subversion you should be equally distrusting of portsnap and this hypothetical source checkout system. > 1. It only allows a secure checkout. See above. To be fair I think this perception has a lot to do with the fact that the server side code for portsnap and freebsd-update wasn't released publicly until a year ago (I'd requested it from Colin while attempting an audit two years ago). So you, like myself, never really had a fair chance to review it. I'd always just assumed it was rock solid. It was, after all, written by the FreeBSD Chief Security Officer! I'm sure your line of thinking was similar. Portsnap's first release was in 2005 and freebsd-update's was in 2006. That means we went a solid 7 years without a public review of either of those two core components. This is a huge problem, and an important lesson for the project on the subject of transparency; everything relating to FreeBSD needs to be open for review no matter who built it or what their credentials are. > You can't accidentally checkout svn:// or http://. You only have to check out the ports tree once so there's really only one time you're going to have to worry about correctly entering a URL. That and on the rare occasion that you have to call svn switch, which you shouldn't have to call to update ports unless one of the mirrors is down. Checking out /usr/ports creates a record of the URL used in /usr/ports/.svn/wc.db. If entering the https:// prefix is really that big of a deal, which I'm not convinced that it is, why not pre-load an .svn/ directory into the /usr/ports/ directory at the time the ports tree is installed? This would eliminate the need to call svn checkout altogether. > 2. It blows away directories with updates. I've witnessed a trojaned > ports checkout before. 'svn update' does not remove unexpected files, > nor remove changes. Yes this is a decrease in usability when you've > modified the file and want to keep the changes, but you can easily make > a wrapper script to merge in your changes, or use SVN if you really want. I'm not familiar with what you're talking about so I can't really respond to it. I guess I'm not clear: you're describing the process whereby a port containing malicious code is checked out by svn update? If the malicious code or metadata pointing to malicious code is on svn it's in portsnap too. I'm not clear on what a "trojaned ports checkout" is. > 3. SVN too often gets into confusing situations on 'svn update' that > require knowledge of how SVN works to resolve the conflict. Even I with > my ~10 years of SVN experience I get confused often and frustrated when > not even 'svn revert -R dir; svn up dir' will revert to the upstream > version (I may have my example off, but that's the point, it's confusing.) The only issue I've ever run into was an error message saying I needed to first run svn upgrade. Why were you using svn revert on your ports tree? Is that a common use case? Maintaining a local ports repository with Subversion requires knowledge of, at a minimum, two commands: svn co, and svn up. Actually you can get away with just one: `svn co https://... /usr/ports`. Any problem a user may encounter can be fixed with `rm -rf /usr/ports; svn co https://... /usr/ports`. If a person is using portsnap it means they're building their own ports. Make is immeasurably more difficult to use than subversion. If they're competent enough to wade through the nightmare that often is building ports on FreeBSD they're certainly competent enough to familiarize themselves with svn co. > 4. SVN asks the user to confirm the public key when first using the > HTTPS repository. I worry this step will be done poorly by users. If you look at the /root/.subversion/servers configuration file you'll see that one of its parameters is ssl-authority-files. Using this it would be simple to include the server's public keys in base, allowing users to call svn update without having to verify anything. Portsnap hard-codes the public key fingerprint in /etc/portsnap.conf. The line from the config file is: # ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem > 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users. > 6. The way we do HTTPS is through mirrors only, if you pick the wrong > mirror it's against hard for the user who doesn't know SVN to change to > a different mirror. Portsnap already handles mirrors excellently by geo > location. Again, if they're using `make` it's safe to say they can handle svn upgrade and svn switch. Worst case scenario we have to document the few edge cases svn can throw in the handbook. > Teaching portsnap how to speak SVN, while still behaving the same, may > cover my concerns. That may be simpler than patching portsnap and freebsd-update. I don't think it would be worth the effort though. I don't see how adding `0 0 * * * svn up /usr/ports` to crontab is any more difficult than adding `0 0 * * * portsnap cron`. -David From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 14:42:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38773FC8 for ; Fri, 11 Apr 2014 14:42:49 +0000 (UTC) Received: from lyra.its.uu.se (lyra.its.uu.se [130.238.7.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0B4A131B for ; Fri, 11 Apr 2014 14:42:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at uu.se X-DKIM: Sendmail DKIM Filter v2.8.3 lyra.its.uu.se 0E6E3E80EF DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uu.se; s=centralsmtp; t=1397226894; i=@uu.se; bh=eQn7WTB9QHaupX95tKPDcyp6dCEiJVs0AmDcQ92ramc=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jrxkpd4fgVmmz0onLn2HGr+C/uw49ekqQA9pxU6YMvyFxhStB79OeP6UUvmzAKi1V nGqQDCd1U62ThbrtyhPcjg5h3gFrfQEbaHWhb4kjJD2Bz9NA3cDl1C9zOm9NmQiDLu WInaMXfoTZzifE+2yX6XC/FiQ7qwMN/8wRw1JHuY= Received: from caligata.its.uu.se (caligata.its.uu.se [130.238.7.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lyra.its.uu.se (Postfix) with ESMTPS id 0E6E3E80EF; Fri, 11 Apr 2014 16:34:54 +0200 (CEST) Received: from jubula (localhost.localdomain [127.0.0.1]) by caligata.its.uu.se (8.13.8/8.13.8) with ESMTP id s3BEYr8d029582; Fri, 11 Apr 2014 16:34:53 +0200 Received: from h-197-74.a213.corp.bahnhof.se (h-197-74.a213.corp.bahnhof.se [85.24.197.74]) by webmail.uu.se (Horde Framework) with HTTP; Fri, 11 Apr 2014 16:34:53 +0200 Message-ID: <20140411163453.10305uc2u7ijvcst@webmail.uu.se> Date: Fri, 11 Apr 2014 16:34:53 +0200 From: Erik Trulsson To: sbremal@hotmail.com Subject: RE: CVE-2014-0160? References: , , , In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Mailman-Approved-At: Fri, 11 Apr 2014 16:38:43 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 14:42:49 -0000 Quoting sbremal@hotmail.com: > I receive daily email from the host which normally shows port audits > and vulnerabilities. However, I did not sport anything related to > CVE-2014-0160 in this email. I expected the same info comes in this > email about the base system as well. > > How do you normally inform about recent vulnerability in the base > system? (I believe newspaper and TV is not the best way...) No, the port audit system does not cover base system vulnerabilities. Security advisories regarding the base systems are supposed to be sent by e-mail to the following mailing lists: FreeBSD-security-notifications@FreeBSD.org FreeBSD-security@FreeBSD.org FreeBSD-announce@FreeBSD.org Personally I would recommend all FreeBSD users to subscribe to the freebsd-announce list at least. From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 16:39:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9169C761 for ; Fri, 11 Apr 2014 16:39:30 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18CAF116B for ; Fri, 11 Apr 2014 16:39:29 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id n15so3786541lbi.27 for ; Fri, 11 Apr 2014 09:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pNUYG+XfUoJOnXJT5kgl5Xz4BkcWo8VzUf3w9tvqePQ=; b=PDVpJDSEmyQq9FKJsCQGnVigGdvywVqk2zHhNz74gIoF8yl13H5HlYTZYuplFoITgE jw8XoUTzKwahXZmwf+1c4bs2pOuHlcMadtvzhGkEcqRmxDBQX8+9XFQoPndRgZ8aYUIX pKXo9Gi7wR/mULL3Jq8ChsVHJYFrARY5FfrnZ1JcaQ6Dir0LovHOHSuS5OXyVWKE7mzd I7Shpob6S3kx8Ii9ncnilu1gRzEKBmzEHMPzaBw8Hv/gv+CzBQeJFaYFG/COn9GHArEv 6fwSW014/vlUR+CbYThuW4svTJ9dQdrQTevxVunx428j1rNlHwxbXMktm9Dw8Ok3i0Fn tDNw== MIME-Version: 1.0 X-Received: by 10.152.116.99 with SMTP id jv3mr17359419lab.19.1397234367912; Fri, 11 Apr 2014 09:39:27 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Fri, 11 Apr 2014 09:39:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 17:39:27 +0100 Message-ID: Subject: Re: CVE-2014-0160? From: Tom Evans To: sbremal@hotmail.com Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org" , Kimmo Paasiala X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:39:30 -0000 On Fri, Apr 11, 2014 at 2:26 PM, wrote: > I receive daily email from the host which normally shows port audits and vulnerabilities. However, I did not sport anything related to CVE-2014-0160 in this email. I expected the same info comes in this email about the base system as well. > > How do you normally inform about recent vulnerability in the base system? (I believe newspaper and TV is not the best way...) If you use or administer FreeBSD you should subscribe to (and read daily!) security@ and stable@. Cheers Tom From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 18:12:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 306CDEE4; Fri, 11 Apr 2014 18:12:09 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 124E41B30; Fri, 11 Apr 2014 18:12:08 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 5BD12477C; Fri, 11 Apr 2014 11:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397239927; bh=SgfmutnDiezbxz2NGF5hu2M1BM3Fcev55cHm72tihCQ=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=By7z98Ym1dk5bmx0coEk/IXdbEvH4bWEJ8TRmOfVckC6M2jyecZxzuvkuHXKx/RrT G8uZfVLxKhycOrSvY15Bj8rfflX42B1CJzLcTgcaOvzMMUcG2s5AeCjEGhFvn8HV1k Qv5mvtB/EHH/hPLtpyt/6g5DP44HXA/vZqj6YFRg= Message-ID: <53483074.1050100@delphij.net> Date: Fri, 11 Apr 2014 11:12:04 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: David.I.Noel@gmail.com, Bryan Drewery Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] References: <53472B7F.5090001@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, secteam , security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:12:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/11/14 09:08, David Noel wrote: >> Your report aside, I find portsnap to be far superior in security >> for ports and users. > > If you look at the portsnap build code you'll see that the first > thing portsnap does is pull the ports tree from Subversion. It uses > the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh > the entire ports archive is exposed to corruption right from the > start. Just to clarify -- this is not entirely true. I have double checked and confirmed that the snapshot builder of portsnap at FreeBSD.org uses svn over spiped transport. The configuration on svn do not necessarily reflect what's running in production (however you brought a very good point that it's a good idea to bring them public assuming there is no sensitive information in them so anyone can review them). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTSDB0AAoJEJW2GBstM+nsuWYP/1e49M6TfYQpDwr2ufOuF+a5 IfDcgRyFrW/aPEoJwF6zqCNCyz9HhBxyoj8UkHqp371gjq1SSeHm7mx3/Md10rFX Y9kwwVFNUelN3Xa4a158o2m3/rxWiJaloTLPI75q6WhQnXQlgxYmsqiPywiRXRUk 0jQI7OkzEa3f2ntC4oCEKdBkwPxpcI+FGFk7jI/1NofzPZpZqDxDXsgzRoWe1Xvc lH6uFOH3dxa6xGA2/zq9Av8NgqcS3ka9drcMrqWpMixWKT6btTjJ4hnqoZ2riFtO /FZ93TZs8Kydivk4N//qSR86a6T+Yg53zYMiSrobkOphTDk8ON4ooA8o689IWF1Y JZz20ROeTZ8BnEhK4TEm4yXGX3Py6DScfyklyFQfH3La8zOsZfYa1mwyy/9hYc/u xSZm4QKsQhKq4ou68UyFV1F2/gpEfrbYIpd4ybTnMpC8umE86tjBmFmCDoqf7uKW z5aKwdMQOa3CWSC0RrT9W55wNVO/R0YGM7qG5nqm1YjQajUGMlub2ntLiOTt3STT 2VMDHP7YzNRQU7SDbGCqA2NrVPur57I7uavHgEbKiwtKmuWWip1Nlyv3tyFZvwIZ 8X6pBpi1Ddj06Vy/KydKomn4zBvw1bZ4l/I55yF7/QAgbkW64brbdx/TGLmItHNP bclldphPPDj12yzaz1so =ofjA -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 20:23:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E6C2B5D; Fri, 11 Apr 2014 20:23:04 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B429192E; Fri, 11 Apr 2014 20:23:03 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id x48so5919614wes.35 for ; Fri, 11 Apr 2014 13:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8ThZ68aG/tXTDSjR/cm9Wotmx2NAczAr7FTy5xcMGag=; b=smGu7gDD5/OOwSMeGvG3M3QFyDd9bPvNDi6c1D+ODEs+Tm2OO/QuzpSkjr7ypDLCcy f8C60YSni2N+fiV3+5ue83yRpCAt5JQUlrNUb6VNWPJrKHyeZhyS/mR0aOjjSY3D43Ts mJ2a+/x2QXiYO8R6JY9VLexYBqV6+LnZUxcxciyid4fW5iCXzUyfQQsHOQ8u+tb/BBos W7fiEE8PBbaQs3ba7dPnaoPNTwR/QL+3q6dJOQvRhlGYYcMYaLrJAbg3KtB3+cEnoolL oBdXeXB7nzE0stpfAuEmCMl/1/Q+5R3ofoGMafXT1he8FLBfwHUHJsxcoFskapNDAoD7 zHWQ== MIME-Version: 1.0 X-Received: by 10.194.94.39 with SMTP id cz7mr175447wjb.78.1397247781777; Fri, 11 Apr 2014 13:23:01 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Fri, 11 Apr 2014 13:23:01 -0700 (PDT) In-Reply-To: <53483074.1050100@delphij.net> References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> Date: Fri, 11 Apr 2014 15:23:01 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, security@freebsd.org, secteam , Bryan Drewery X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:23:04 -0000 >> If you look at the portsnap build code you'll see that the first >> thing portsnap does is pull the ports tree from Subversion. It uses >> the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh >> the entire ports archive is exposed to corruption right from the >> start. > > Just to clarify -- this is not entirely true. I have double checked > and confirmed that the snapshot builder of portsnap at FreeBSD.org > uses svn over spiped transport. > > The configuration on svn do not necessarily reflect what's running in > production (however you brought a very good point that it's a good > idea to bring them public assuming there is no sensitive information > in them so anyone can review them). Thanks for checking on that. I don't have production access so I could only assume that what was in /user/cperciva/portsnap-build was what we were running. I'm surprised to find out that it's not. My main point was that if you don't trust Subversion it makes no sense to say you trust portsnap. Portsnap pulls the ports tree from Subversion. Using Subversion! The portsnap system relies on the trust of both svnadmin and svn. Just as it does when you run svn co and svn up. If you say you don't trust Subversion, essentially what you're saying is that you don't trust anything running on your computer. > you brought a very good point that it's a good > idea to bring them public assuming there is no sensitive information > in them so anyone can review them). Thank you. I hope something comes of this conversation. I have no access to production so for these sorts of things all I can do is mail this list and hope that someone makes the requested changes. From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 20:57:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 712808C7 for ; Fri, 11 Apr 2014 20:57:08 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 18F4E1C0E for ; Fri, 11 Apr 2014 20:57:07 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s3BKv1Yq094154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2014 21:57:02 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s3BKv1Yq094154 Authentication-Results: smtp.infracaninophile.co.uk/s3BKv1Yq094154; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <5348571A.9060703@FreeBSD.org> Date: Fri, 11 Apr 2014 21:56:58 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Erik Trulsson , sbremal@hotmail.com Subject: Re: CVE-2014-0160? References: , , , <20140411163453.10305uc2u7ijvcst@webmail.uu.se> In-Reply-To: <20140411163453.10305uc2u7ijvcst@webmail.uu.se> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k68gKep2f1QRlfniUsvn4GvPW3PNsbqp1" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-Mailman-Approved-At: Fri, 11 Apr 2014 21:05:02 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:57:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k68gKep2f1QRlfniUsvn4GvPW3PNsbqp1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/04/2014 15:34, Erik Trulsson wrote: > Quoting sbremal@hotmail.com: >=20 >> I receive daily email from the host which normally shows port audits >> and vulnerabilities. However, I did not sport anything related to >> CVE-2014-0160 in this email. I expected the same info comes in this >> email about the base system as well. >> >> How do you normally inform about recent vulnerability in the base >> system? (I believe newspaper and TV is not the best way...) >=20 > No, the port audit system does not cover base system vulnerabilities. >=20 > Security advisories regarding the base systems are supposed to be sent = by > e-mail to the following mailing lists: >=20 > FreeBSD-security-notifications@FreeBSD.org > FreeBSD-security@FreeBSD.org > FreeBSD-announce@FreeBSD.org >=20 > Personally I would recommend all FreeBSD users to subscribe to the > freebsd-announce list at least. portaudit is rapidly becoming obsolete. Today's alternative is pkg-audit= (8) One of the non obvious things about the switch from portaudit to pkg audit is that pkg audit uses the standard vuxml vulnerability database directly, whereas portaudit used it's own vulnerability data which was essentially a heavily trimmed extract from vuxml. The interesting thing about vuxml is that it is quite possible to write vulnerability entries for the base system. Eg. http://vuxml.freebsd.org/freebsd/b72bad1c-20ed-11e3-be06-000c29ee3065.htm= l This is applied inconsistently though. While there is an entry for OpenSSL Heartbleed, it doesn't contain any reference to the FreeBSD base system and the security advisories (at least, not at the time I was writing this...) It's also not a feature of pkg audit or any other tool I am aware of that it can warn about base system vulnerabilities. Such functionality would be very welcome though. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --k68gKep2f1QRlfniUsvn4GvPW3PNsbqp1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTSFccXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATAlgQAKlcZafxYGsjyzRbvnwniRgN WQuCeUYW8E2lgFrnQz3DnVaGWXxgEdCrk8+b09I4udd+4s33UqfLOw49RSq/RCI9 UTGpKowCtOFrbyvuHuiVfW1qoClmnDycbyESRWD0vJAQ1pOSnMxsht/tMJd3Fqm5 h6ESyGKWHwcfgJLyERnm88E5k3ISX8B7g9cqpAvjJv5STWJFyLXSWG0xJnav8B4J 07LVGiNnBhuTvt2w1yBPhgiReIj2eDI8XE5pREgtoBaZo0EzFspJCqwPdkkfhwtp EcQWQSRO2P2ubrv9k/Mv8CZK4SOZRmZcAp6KIsclWOidiSwjhdafUmzokbfAxdZA 0trjIkr0y1UNGkoIzpO1qWVMWZfkEGyhhMfqStFG/pXeD6D/3cn6DSP/darbJL13 jlFMpVK5ijZ+asHWFdargHNuTd//Utquo4pHtAP20i0s6uqMKpZXueDlTANThGOV jAb09QT6s5FWUelpBZaUbHuj76wnJtf82Uoz2ytK0xccMwktSxFSjjG+swsP7ef8 R5t0KraVZWCfBuwqKS7LYMjeQPP0nONBfgmvkzw9GesPnl1SGI4aWB/Fqctm8udt Q2SKYbt/Gma10GWPUdTgPw1emkYyfJMg78afeM4WaHxXXXjNfIiOcjdzw3LEgE1Y V1zgQyRjCH3ZZQDs/FSn =Buqo -----END PGP SIGNATURE----- --k68gKep2f1QRlfniUsvn4GvPW3PNsbqp1-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 21:13:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57715D5C; Fri, 11 Apr 2014 21:13:21 +0000 (UTC) Received: from exodus.zi0r.com (exodus.zi0r.com [71.245.171.203]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "exodus.zi0r.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2519C1DA0; Fri, 11 Apr 2014 21:13:21 +0000 (UTC) Received: from exodus.zi0r.com (localhost [127.0.0.1]) by exodus.zi0r.com (Postfix) with ESMTP id DB0813DC59; Fri, 11 Apr 2014 17:13:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at zi0r.com Received: from exodus.zi0r.com ([127.0.0.1]) by exodus.zi0r.com (exodus.zi0r.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id RD9c0RIE8U_s; Fri, 11 Apr 2014 17:13:18 -0400 (EDT) Received: from exodus.zi0r.com (syn.zi0r.com [71.245.171.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by exodus.zi0r.com (Postfix) with ESMTPSA id 212643DC57; Fri, 11 Apr 2014 17:13:18 -0400 (EDT) Date: Fri, 11 Apr 2014 17:13:12 -0400 From: Ryan Steinmetz To: Matthew Seaman Subject: Re: CVE-2014-0160? Message-ID: <20140411211312.GA82093@exodus.zi0r.com> References: <20140411163453.10305uc2u7ijvcst@webmail.uu.se> <5348571A.9060703@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5348571A.9060703@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-security@freebsd.org, sbremal@hotmail.com, Erik Trulsson X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:13:21 -0000 On (04/11/14 21:56), Matthew Seaman wrote: >http://vuxml.freebsd.org/freebsd/b72bad1c-20ed-11e3-be06-000c29ee3065.html > >This is applied inconsistently though. While there is an entry for >OpenSSL Heartbleed, it doesn't contain any reference to the FreeBSD base >system and the security advisories (at least, not at the time I was >writing this...) > Entry updated, thank you for pointing this out. http://svnweb.freebsd.org/ports/head/security/vuxml/vuln.xml?r1=351042&r2=351041&pathrev=351042 -r >It's also not a feature of pkg audit or any other tool I am aware of >that it can warn about base system vulnerabilities. Such functionality >would be very welcome though. > > Cheers, > > Matthew > >-- >Dr Matthew J Seaman MA, D.Phil. >PGP: http://www.infracaninophile.co.uk/pgpkey > > -- Ryan Steinmetz PGP: 9079 51A3 34EF 0CD4 F228 EDC6 1EF8 BA6B D028 46D7 From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 21:44:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7288AD05; Fri, 11 Apr 2014 21:44:30 +0000 (UTC) Received: from exodus.zi0r.com (exodus.zi0r.com [71.245.171.203]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "exodus.zi0r.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF8511ED; Fri, 11 Apr 2014 21:44:29 +0000 (UTC) Received: from exodus.zi0r.com (localhost [127.0.0.1]) by exodus.zi0r.com (Postfix) with ESMTP id A91323DC59; Fri, 11 Apr 2014 17:44:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at zi0r.com Received: from exodus.zi0r.com ([127.0.0.1]) by exodus.zi0r.com (exodus.zi0r.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id RHCPSKQalC2s; Fri, 11 Apr 2014 17:44:27 -0400 (EDT) Received: from exodus.zi0r.com (syn.zi0r.com [71.245.171.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by exodus.zi0r.com (Postfix) with ESMTPSA id DE0373DC57; Fri, 11 Apr 2014 17:44:27 -0400 (EDT) Date: Fri, 11 Apr 2014 17:44:22 -0400 From: Ryan Steinmetz To: Matthew Seaman Subject: Re: CVE-2014-0160? Message-ID: <20140411214421.GB83317@exodus.zi0r.com> References: <20140411163453.10305uc2u7ijvcst@webmail.uu.se> <5348571A.9060703@FreeBSD.org> <20140411211312.GA82093@exodus.zi0r.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20140411211312.GA82093@exodus.zi0r.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-security@freebsd.org, sbremal@hotmail.com, Erik Trulsson X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:44:30 -0000 I've also added the affected system information for CVE-2014-0076 and corrected a issue with the affected values. -r On (04/11/14 17:13), Ryan Steinmetz wrote: > >On (04/11/14 21:56), Matthew Seaman wrote: >>http://vuxml.freebsd.org/freebsd/b72bad1c-20ed-11e3-be06-000c29ee3065.html >> >>This is applied inconsistently though. While there is an entry for >>OpenSSL Heartbleed, it doesn't contain any reference to the FreeBSD base >>system and the security advisories (at least, not at the time I was >>writing this...) >> > >Entry updated, thank you for pointing this out. > >http://svnweb.freebsd.org/ports/head/security/vuxml/vuln.xml?r1=351042&r2=351041&pathrev=351042 > >-r > >>It's also not a feature of pkg audit or any other tool I am aware of >>that it can warn about base system vulnerabilities. Such functionality >>would be very welcome though. >> >> Cheers, >> >> Matthew >> >>-- >>Dr Matthew J Seaman MA, D.Phil. >>PGP: http://www.infracaninophile.co.uk/pgpkey >> >> > > > >-- >Ryan Steinmetz >PGP: 9079 51A3 34EF 0CD4 F228 EDC6 1EF8 BA6B D028 46D7 >_______________________________________________ >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" -- Ryan Steinmetz PGP: 9079 51A3 34EF 0CD4 F228 EDC6 1EF8 BA6B D028 46D7 From owner-freebsd-security@FreeBSD.ORG Fri Apr 11 21:55:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57B8A5D6 for ; Fri, 11 Apr 2014 21:55:07 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22C871309 for ; Fri, 11 Apr 2014 21:55:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3BLt67x035926 for ; Fri, 11 Apr 2014 21:55:06 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3BLt6gA035925 for freebsd-security@freebsd.org; Fri, 11 Apr 2014 21:55:06 GMT (envelope-from bdrewery) Received: (qmail 6771 invoked from network); 11 Apr 2014 16:55:04 -0500 Received: from unknown (HELO roundcube.xk42.net) (10.10.5.5) by sweb.xzibition.com with SMTP; 11 Apr 2014 16:55:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 11 Apr 2014 16:55:04 -0500 From: Bryan Drewery To: David.I.Noel@gmail.com Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] Organization: FreeBSD In-Reply-To: References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> Message-ID: <9a96e11b0edf412d0a3f79afdbecc4fd@shatow.net> X-Sender: bdrewery@FreeBSD.org User-Agent: Roundcube Webmail/0.9.5 X-Mailman-Approved-At: Fri, 11 Apr 2014 22:03:47 +0000 Cc: freebsd-security@freebsd.org, d@delphij.net, secteam , security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:55:07 -0000 On 2014-04-11 15:23, David Noel wrote: >>> If you look at the portsnap build code you'll see that the first >>> thing portsnap does is pull the ports tree from Subversion. It uses >>> the URL svn://svn.freebsd.org/ports. By not using ssl or svn+ssh >>> the entire ports archive is exposed to corruption right from the >>> start. >> >> Just to clarify -- this is not entirely true. I have double checked >> and confirmed that the snapshot builder of portsnap at FreeBSD.org >> uses svn over spiped transport. >> >> The configuration on svn do not necessarily reflect what's running in >> production (however you brought a very good point that it's a good >> idea to bring them public assuming there is no sensitive information >> in them so anyone can review them). > > Thanks for checking on that. I don't have production access so I could > only assume that what was in /user/cperciva/portsnap-build was what we > were running. I'm surprised to find out that it's not. > > My main point was that if you don't trust Subversion it makes no sense > to say you trust portsnap. Portsnap pulls the ports tree from > Subversion. Using Subversion! The portsnap system relies on the trust > of both svnadmin and svn. Just as it does when you run svn co and svn > up. If you say you don't trust Subversion, essentially what you're > saying is that you don't trust anything running on your computer. > >> you brought a very good point that it's a good >> idea to bring them public assuming there is no sensitive information >> in them so anyone can review them). > > Thank you. I hope something comes of this conversation. I have no > access to production so for these sorts of things all I can do is mail > this list and hope that someone makes the requested changes. Who said we don't trust subversion? I certainly was not meaning that. -- Regards, Bryan Drewery From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 08:09:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B68A6F1 for ; Sun, 13 Apr 2014 08:09:44 +0000 (UTC) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E87491471 for ; Sun, 13 Apr 2014 08:09:43 +0000 (UTC) Received: from m.cksoft.de (unknown [IPv6:2003:41:c010:8001::143:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id 8EEEA2EBBFD for ; Sun, 13 Apr 2014 10:09:40 +0200 (CEST) Received: from amavis.ahti.cksoft.de (unknown [IPv6:fdfe:5560:83f7:8001::143:2]) by m.cksoft.de (Postfix) with ESMTP id 151EFED7FC for ; Sun, 13 Apr 2014 10:09:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:fdfe:5560:83f7:8001::143:1]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [fdfe:5560:83f7:8001::143:2]) (amavisd-new, port 10024) with ESMTP id Uc7DI+tMBqQl; Sun, 13 Apr 2014 10:09:37 +0200 (CEST) Received: from pohjola.cksoft.de (unknown [IPv6:fdfe:5560:83f7:8001:d899:97e:8e91:f22d]) by m.cksoft.de (Postfix) with ESMTP id E8B6BED7F7; Sun, 13 Apr 2014 10:09:36 +0200 (CEST) Received: by pohjola.cksoft.de (Postfix, from userid 1000) id D9D03D7902; Sun, 13 Apr 2014 10:09:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pohjola.cksoft.de (Postfix) with ESMTP id D7A3DD7891; Sun, 13 Apr 2014 10:09:36 +0200 (CEST) Date: Sun, 13 Apr 2014 10:09:36 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@pohjola.cksoft.de To: freebsd-security@freebsd.org Subject: OpenSSL followup SSL_MODE_RELEASE_BUFFERS Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Christian Kratzer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Christian Kratzer List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 08:09:44 -0000 Hi, apparentyly openbsd has more or less silently fixed an older openssl issue that has been stuck in the openssl bug tracker: The openbsd patch: http://www.openbsd.org/errata55.html#004_openssl http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/004_openssl.patch.sig The original issue: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse Here is the openssl bug: http://rt.openssl.org/Ticket/Display.html?id=2167 The patch; diff -u -p -u -r1.20 -r1.20.4.1 --- lib/libssl/src/ssl/s3_pkt.c 27 Feb 2014 21:04:57 -0000 1.20 +++ lib/libssl/src/ssl/s3_pkt.c 12 Apr 2014 17:01:14 -0000 1.20.4.1 @@ -1054,7 +1054,7 @@ start: { s->rstate=SSL_ST_READ_HEADER; rr->off=0; - if (s->mode & SSL_MODE_RELEASE_BUFFERS) + if (s->mode & SSL_MODE_RELEASE_BUFFERS && s->s3->rbuf.left == 0) ssl3_release_read_buffer(s); } } Can somebody rattle openssl upstream to get them to comment on this ? Should freebsd roll out a patch ? Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 14:34:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3754B73; Sun, 13 Apr 2014 14:34:00 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id C573114C1; Sun, 13 Apr 2014 14:34:00 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 4927933C49; Sun, 13 Apr 2014 10:33:55 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 1C82039846; Sun, 13 Apr 2014 10:33:53 -0400 (EDT) From: Lowell Gilbert To: David.I.Noel@gmail.com Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> Date: Sun, 13 Apr 2014 10:33:53 -0400 In-Reply-To: (David Noel's message of "Fri, 11 Apr 2014 15:23:01 -0500") Message-ID: <44bnw5uwmm.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-security@freebsd.org, security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 14:34:01 -0000 David Noel writes: > My main point was that if you don't trust Subversion it makes no sense > to say you trust portsnap. Portsnap pulls the ports tree from > Subversion. Using Subversion! The portsnap system relies on the trust > of both svnadmin and svn. Just as it does when you run svn co and svn > up. If you say you don't trust Subversion, essentially what you're > saying is that you don't trust anything running on your computer. You were talking about MITM attacks. Portsnap uses secured access for getting updates out of Subversion, whereas doing "svn co" remotely generally does not. This is not a trivial point. From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 21:07:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0565780; Sun, 13 Apr 2014 21:07:11 +0000 (UTC) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6502115C1; Sun, 13 Apr 2014 21:07:11 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id x48so7320854wes.38 for ; Sun, 13 Apr 2014 14:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=visBOqDlkSx15piwinNfzMykRUJi7Jz/ZaaN6HdhvlU=; b=QMZWwkXBxo2O9RBwjjbI/3pYMPxNX+AHxl+d1PdAE9GCREpQV8x4SddcxCxFV9KZIb OQ9Peqs7rc9FP9kf2UWot6R9BtMQMP99AEyfxJxQqo8JxTrpAY+fkMdUdFvsjAuG2p4C hILyMem4h7MjP/P5LUJkZXmKBNBumycTRGlXZpjeto9Ke+NL+ZpapG10t3VM2aeDbBjt 1Al2sQvKuog0jo+wzUSkhzsoNcjrrwzVfsNVeVwSlNRCkwmn4kiJVoQAq0YEetJic5pS 41GaTP7vfqrSW1bjrDtThU4IymLGYfa6EYYoU+2sKdSVKWMuWUDyLStBYKPzDMiPqQOr /j6Q== MIME-Version: 1.0 X-Received: by 10.194.1.242 with SMTP id 18mr30332986wjp.22.1397423229493; Sun, 13 Apr 2014 14:07:09 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Sun, 13 Apr 2014 14:07:09 -0700 (PDT) In-Reply-To: <44bnw5uwmm.fsf@lowell-desk.lan> References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> Date: Sun, 13 Apr 2014 16:07:09 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: Lowell Gilbert Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 21:07:12 -0000 > Portsnap uses secured access for getting updates out of Subversion The portsnap open source project pulls data insecurely using the url svn://svn.freebsd.org. The server-side code of the FreeBSD portsnap system -- a closed source fork of the open source portsnap project -- happens to use secured access for pulling data from svn. This is not a trivial point. > whereas doing "svn co" remotely generally does not. Without knowing usage statistics there is no way to describe a "general" use case for `svn co`. The security of access of that command is entirely dependent on how it is parameterized. From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 21:47:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19BA11F4; Sun, 13 Apr 2014 21:47:51 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C886D18EB; Sun, 13 Apr 2014 21:47:50 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 92E546592; Sun, 13 Apr 2014 21:47:49 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 707FABBA; Sun, 13 Apr 2014 23:47:49 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: David.I.Noel@gmail.com Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> Date: Sun, 13 Apr 2014 23:47:49 +0200 In-Reply-To: (David Noel's message of "Sun, 13 Apr 2014 16:07:09 -0500") Message-ID: <86zjjosxyy.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: Lowell Gilbert , freebsd-security@freebsd.org, security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 21:47:51 -0000 David Noel writes: > The server-side code of the FreeBSD portsnap system -- a closed source > fork of the open source portsnap project -- happens to use secured > access for pulling data from svn. So by your definition, every single Apache server on the planet runs "a closed source fork of the open source Apache project" because they do not use the exact same httpd.conf? Do you understand the concept of a configuration file? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 22:40:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1AFC531; Sun, 13 Apr 2014 22:40:51 +0000 (UTC) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6803B1D16; Sun, 13 Apr 2014 22:40:51 +0000 (UTC) Received: from nskntcmgw05p ([61.9.169.165]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20140413224044.BWPM17495.nskntmtas04p.mx.bigpond.com@nskntcmgw05p>; Sun, 13 Apr 2014 22:40:44 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nskntcmgw05p with BigPond Outbound id pagk1n00829zwdD01agkXl; Sun, 13 Apr 2014 22:40:44 +0000 X-Authority-Analysis: v=2.0 cv=W5W6pGqk c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=e2fqWSVUWYYA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=3tcz3bTJAAAA:8 a=OxEAv6DlAAAA:8 a=Ntg_Zx-WAAAA:8 a=6I5d2MoRAAAA:8 a=4tlpSyZ5_jFHVkki-E8A:9 a=wPNLvfGTeEIA:10 a=jPEJIK0TjPAA:10 a=OrBpBuw_MJkA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s3DMea1N016097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Apr 2014 08:40:37 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <534B125C.90000@heuristicsystems.com.au> Date: Mon, 14 Apr 2014 08:40:28 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org, dinoex@freebsd.org Subject: Re: OpenSSL followup SSL_MODE_RELEASE_BUFFERS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 22:40:52 -0000 On 13/04/2014 6:09 PM, Christian Kratzer wrote: > Hi, > > apparentyly openbsd has more or less silently fixed an older openssl > issue that has been stuck in the openssl bug tracker: > > The openbsd patch: > > http://www.openbsd.org/errata55.html#004_openssl > > > http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/004_openssl.patch.sig > > The original issue: > > > http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse > > Here is the openssl bug: > > http://rt.openssl.org/Ticket/Display.html?id=2167 > > The patch; > > diff -u -p -u -r1.20 -r1.20.4.1 > --- lib/libssl/src/ssl/s3_pkt.c 27 Feb 2014 21:04:57 -0000 1.20 > +++ lib/libssl/src/ssl/s3_pkt.c 12 Apr 2014 17:01:14 -0000 > 1.20.4.1 > @@ -1054,7 +1054,7 @@ start: > { > s->rstate=SSL_ST_READ_HEADER; > rr->off=0; > - if (s->mode & SSL_MODE_RELEASE_BUFFERS) > + if (s->mode & SSL_MODE_RELEASE_BUFFERS && > s->s3->rbuf.left == 0) > ssl3_release_read_buffer(s); > } > } > > Can somebody rattle openssl upstream to get them to comment on this ? > > Should freebsd roll out a patch ? > > Greetings > Christian > Thank-you Dirk for promptly deploying the patch to openssl port: http://svnweb.freebsd.org/ports/head/security/openssl/files/patch-ssl-s3_pkt.c?revision=351191&view=markup Regards, Dewayne From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 22:44:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B52FAC8A for ; Sun, 13 Apr 2014 22:44:35 +0000 (UTC) Received: from mail.prolet.org (mail.prolet.org [195.24.42.5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC101DC3 for ; Sun, 13 Apr 2014 22:44:34 +0000 (UTC) Received: from amorphis.prolet.org (localhost [127.0.0.1]) by mail.prolet.org (Postfix) with ESMTP id CB19A3380C3F for ; Mon, 14 Apr 2014 01:38:42 +0300 (EEST) X-Virus-Scanned: amavisd-new at mail.prolet.org Received: from mail.prolet.org ([127.0.0.1]) by amorphis.prolet.org (amorphis.prolet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYmt4wrgjQgo for ; Mon, 14 Apr 2014 01:38:40 +0300 (EEST) Received: from [192.168.10.16] (unknown [77.70.57.248]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.prolet.org (Postfix) with ESMTPSA id 7C2433380C3B for ; Mon, 14 Apr 2014 01:38:40 +0300 (EEST) Message-ID: <534B11F0.9040400@paladin.bulgarpress.com> Date: Mon, 14 Apr 2014 01:38:40 +0300 From: Todor Todorov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: De Raadt + FBSD + OpenSSH + hole? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 22:44:35 -0000 Hi everyone, I came across this : https://groups.google.com/forum/#!topic/mailing.openbsd.tech/xALfxxR3oKo " You are welcome. Stuart Henderson wrote the draft, but he forgot that part, and Damien Miller and I realized it was needed. We sensed there might be some ambiguity... we'll take care the next time an OpenOffice problem also. ... as long as you aren't using FreeBSD or a derivative (hint: Jupiper), you are fine. That's the only place I know of an OpenSSH hole. Oh now I sense some angst. Please ask Kirk McKusick, he knows the story about why this is not being disclosed to FreeBSD. Sometimes I feel a bit sorry for them (and for him), but then the next minute I don't feel sorry because there's damn good reasons they won't be told about what I found. Does that answer help? Hope so." Any guidance here? From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 22:27:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF633CF for ; Sun, 13 Apr 2014 22:27:30 +0000 (UTC) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1CD1C40 for ; Sun, 13 Apr 2014 22:27:30 +0000 (UTC) Received: by mail-ee0-f53.google.com with SMTP id b57so5922614eek.40 for ; Sun, 13 Apr 2014 15:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=h/SHCY9OhgczWMG+L5rRPkYHFuqvUmekhW2Tjc3mj1k=; b=G5LuhjkJ1EFcKYCMpXYy/jYowlGCWk+phdxX2QzsrKOn2YM3FNcPZ4jQ1KhBdYQalT m2t0idly7xGbZt/cI6Jp5gONfqXNy6wd7YYv+emEKgnNPt6Lgbjdyc6qxiL05Jura4J0 JFO37WREYIHzUPPEdYyCYekkCAU+sBthkLP458yu5kjDtjfshFwkF4VjkrS+h1PGEcoA dsRmKyTKyfnregjSSZJzWDW04G32JNiDnkoq5edXjT5KVoHIzG4/AJDccFJnrJzJI2Cn KpFUVxgOCPMAu+vhTpuprEFaifx069EMP8cmjyUkj+I9GDd4GuUz4qcnS1V5cqyGGgT0 OWQw== X-Received: by 10.14.183.7 with SMTP id p7mr72242eem.107.1397428048646; Sun, 13 Apr 2014 15:27:28 -0700 (PDT) Received: from [192.168.10.16] ([77.70.57.248]) by mx.google.com with ESMTPSA id 4sm36159185eeq.33.2014.04.13.15.27.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Apr 2014 15:27:27 -0700 (PDT) Message-ID: <534B0F4D.9030508@paladin.bulgarpress.com> Date: Mon, 14 Apr 2014 01:27:25 +0300 From: Mailing lists User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: De Raadt + FBSD + OpenSSH + hole? X-Mailman-Approved-At: Sun, 13 Apr 2014 22:53:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 22:27:30 -0000 Hi everyone, I came across this : https://groups.google.com/forum/#!topic/mailing.openbsd.tech/xALfxxR3oKo " You are welcome. Stuart Henderson wrote the draft, but he forgot that part, and Damien Miller and I realized it was needed. We sensed there might be some ambiguity... we'll take care the next time an OpenOffice problem also. ... as long as you aren't using FreeBSD or a derivative (hint: Jupiper), you are fine. That's the only place I know of an OpenSSH hole. Oh now I sense some angst. Please ask Kirk McKusick, he knows the story about why this is not being disclosed to FreeBSD. Sometimes I feel a bit sorry for them (and for him), but then the next minute I don't feel sorry because there's damn good reasons they won't be told about what I found. Does that answer help? Hope so." Any guidance here? From owner-freebsd-security@FreeBSD.ORG Sun Apr 13 22:38:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AC7A449 for ; Sun, 13 Apr 2014 22:38:38 +0000 (UTC) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9D191CF9 for ; Sun, 13 Apr 2014 22:38:37 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id e49so6057264eek.3 for ; Sun, 13 Apr 2014 15:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=sb+XcKqBFz0rIk2Ft9F+Ru28xCgtsBd7WJvObKHYpv0=; b=L6x21MPtJYgH/Piowyi697/NSTQz5Rl5AwfFYG5Dsvpi3FXJOnCPwamQGxB8nbKkDZ 6vHCi2PH50WLaQA+EQnYNOmEpltObZ7OhGOOYiU7EKiFPf9tQ927GkckCu1BNGDsXj49 3iaqu+IkRpn5Xd+Pyi1tjp6IHtnH3zBXD3uzvJs5qWBpJ9chLXh8u2l11i62+jQkj9Wl VPoKm0FxjA/HJ50eDSjRgNn8b3pYVpDfejaVAXMT0nrFOq3+MukW213VRAz25fZWAt9t q7+nB7dXOOpl+EMYzmZ8TjyXkodYVSPhyisrPVa3GF3w+/Ni1H5KgIVqWGdEH05PEPIU oluQ== X-Received: by 10.14.48.2 with SMTP id u2mr41578743eeb.5.1397428714612; Sun, 13 Apr 2014 15:38:34 -0700 (PDT) Received: from [192.168.10.16] ([77.70.57.248]) by mx.google.com with ESMTPSA id q49sm36208558eem.34.2014.04.13.15.38.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Apr 2014 15:38:33 -0700 (PDT) Message-ID: <534B11E7.7080207@paladin.bulgarpress.com> Date: Mon, 14 Apr 2014 01:38:31 +0300 From: Mailing lists User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: De Raadt + FBSD + OpenSSH + hole? X-Mailman-Approved-At: Sun, 13 Apr 2014 23:59:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 22:38:38 -0000 Hi everyone, I came across this : https://groups.google.com/forum/#!topic/mailing.openbsd.tech/xALfxxR3oKo " You are welcome. Stuart Henderson wrote the draft, but he forgot that part, and Damien Miller and I realized it was needed. We sensed there might be some ambiguity... we'll take care the next time an OpenOffice problem also. ... as long as you aren't using FreeBSD or a derivative (hint: Jupiper), you are fine. That's the only place I know of an OpenSSH hole. Oh now I sense some angst. Please ask Kirk McKusick, he knows the story about why this is not being disclosed to FreeBSD. Sometimes I feel a bit sorry for them (and for him), but then the next minute I don't feel sorry because there's damn good reasons they won't be told about what I found. Does that answer help? Hope so." Any guidance here? From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 04:38:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCF2DA8F; Mon, 14 Apr 2014 04:38:56 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30FBE1CA7; Mon, 14 Apr 2014 04:38:56 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n12so7526604wgh.0 for ; Sun, 13 Apr 2014 21:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JRJXhBDD8ZCFEMPrRVDcFsmSI7eQp26jwKm61Q6Kyok=; b=jFBb99G9Y/XM/XX4frN+NrGP/wvOvRRT9+fz1D4l1JTUzUssdGx3Y9HWiBIO4HZHwR RYUMI08CfsIgK1PyVd2feSyhz05IEi5IXo5qJHjFsnV4jv2FshibOhpEM3b5Co5KFGBt YlrIG8o780YbRC34vPvck+hJJGGmbXhafEyTVspiy0ZQYRj4icVnGjIkru1LA0CNq9+p dmepuFXTxvWRYXdhllxnTHF5ZlHUgepbxyQiET23cc/wRDMfpa01g9naeKtuw6PJnrA/ x/8BL8dkSyVUkooo2rTvi3v87PH57ZZJI4S8YTh1ElxvDPEaBcKhlxzV7+HgzBf4t/Wr K6Vw== MIME-Version: 1.0 X-Received: by 10.180.211.239 with SMTP id nf15mr7855201wic.9.1397450334367; Sun, 13 Apr 2014 21:38:54 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Sun, 13 Apr 2014 21:38:54 -0700 (PDT) In-Reply-To: <86zjjosxyy.fsf@nine.des.no> References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <86zjjosxyy.fsf@nine.des.no> Date: Sun, 13 Apr 2014 23:38:54 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Lowell Gilbert , freebsd-security@freebsd.org, security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 04:38:56 -0000 > So by your definition, every single Apache server on the planet runs "a > closed source fork of the open source Apache project" because they do > not use the exact same httpd.conf? Ah, you're right. That's from build.conf. My mistake. From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 05:04:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA2E6501; Mon, 14 Apr 2014 05:04:28 +0000 (UTC) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C2941048; Mon, 14 Apr 2014 05:04:28 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id q58so7708057wes.34 for ; Sun, 13 Apr 2014 22:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JtwrsHIBN/pCrDqJVID9mcMhIfbVvAw22Yj2E5Wdxlc=; b=BcBwjbx3BPBi9qtjtseIr80ERFBni5ae2y4T/jhEaCO3trDXKnvi7zCxlnURZHQyjn QG+ZhykRqUcyZ5q8smjqbEJ5BRmu2vKqM6a+ZszCVa+qAUrduwzr8FecLQHcyZWSOMUX guzwp6QNLYgz/waSmmw1iGOi16u3/6Ly+JqvrZAp8xhGhJFMHVkBgFYXMm5dcIgsqjwa 1ay4jYVq+2i6nxN+46uAiUFFg7FUc9Rms7dGsObYTxoC1EPi4T9Gczo4SMu3nl7hi6vU Dz/tM5QYwf+UjzuCJnxxG2a2A6Adk/5XIc80Uoytq9GyJVJtPq84J+nNuw0YW5++voPF 3dhg== MIME-Version: 1.0 X-Received: by 10.180.23.99 with SMTP id l3mr7923126wif.47.1397451866371; Sun, 13 Apr 2014 22:04:26 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Sun, 13 Apr 2014 22:04:26 -0700 (PDT) In-Reply-To: References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <86zjjosxyy.fsf@nine.des.no> Date: Mon, 14 Apr 2014 00:04:26 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Cc: Lowell Gilbert , freebsd-security@freebsd.org, security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:04:28 -0000 On 4/13/14, David Noel wrote: >> So by your definition, every single Apache server on the planet runs "a >> closed source fork of the open source Apache project" because they do >> not use the exact same httpd.conf? > > Ah, you're right. That's from build.conf. My mistake. Though if it's using spiped I'm not sure how it would doing that from purely a config file change. From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 05:09:43 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FE01798 for ; Mon, 14 Apr 2014 05:09:43 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCA6E10A9 for ; Mon, 14 Apr 2014 05:09:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s3E59OsS043832; Mon, 14 Apr 2014 15:09:24 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 14 Apr 2014 15:09:24 +1000 (EST) From: Ian Smith To: Lowell Gilbert Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] In-Reply-To: <44bnw5uwmm.fsf@lowell-desk.lan> Message-ID: <20140414144155.C55844@sola.nimnet.asn.au> References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org, David.I.Noel@gmail.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:09:43 -0000 On Sun, 13 Apr 2014 10:33:53 -0400, Lowell Gilbert wrote: > David Noel writes: > > > My main point was that if you don't trust Subversion it makes no sense > > to say you trust portsnap. Portsnap pulls the ports tree from > > Subversion. Using Subversion! The portsnap system relies on the trust > > of both svnadmin and svn. Just as it does when you run svn co and svn > > up. If you say you don't trust Subversion, essentially what you're > > saying is that you don't trust anything running on your computer. > > You were talking about MITM attacks. Portsnap uses secured access for > getting updates out of Subversion, whereas doing "svn co" remotely > generally does not. This is not a trivial point. Indeed it is not. David's solution - which seems to amount to removing portsnap and herding the cats at home to DTRT about using svn securely - relies on other cats being as smart and aware of the ramifications as he is - a highly questionable proposition especially for the numerous more naive users that portsnap renders the process of securely upgrading the ports tree just about as simple and consistent as it can be. David, perhaps your obvious talent for auditing the portsnap code and its server-side configuration might be better applied to remedying any perceived vulnerabilities in conjunction with present and past security officers and teams? cheers, Ian From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 05:24:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F411B95B; Mon, 14 Apr 2014 05:24:47 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CA34111FD; Mon, 14 Apr 2014 05:24:47 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id DD52573CC; Sun, 13 Apr 2014 22:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1397453087; bh=1wglqrEUC6/wNdxhq+WA1XXaqcNtFu4R9/eX8wiXcDA=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=Z4wCyxX3QRidVFleBzPQ9wLmlliqyCkfgiDjvC30j7jvz95qkxRFwP7n28ruLotWR cUwKhs4FuzAd2wlRVoaQF43MH/Ehmdw3lAh7Vmf72fkWSTYlyF5LoAIar+jZZJ4CPK mj35jUX1vlXfMhWzUJSPyMzn/+4JKjlxL7v16ilk= Message-ID: <534B711D.5060109@delphij.net> Date: Sun, 13 Apr 2014 22:24:45 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: David.I.Noel@gmail.com, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <86zjjosxyy.fsf@nine.des.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lowell Gilbert , freebsd-security@freebsd.org, security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:24:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 4/13/14, 10:04 PM, David Noel wrote: > On 4/13/14, David Noel wrote: >>> So by your definition, every single Apache server on the planet >>> runs "a closed source fork of the open source Apache project" >>> because they do not use the exact same httpd.conf? >> >> Ah, you're right. That's from build.conf. My mistake. > > Though if it's using spiped I'm not sure how it would doing that > from purely a config file change. Let's focus on the more important points :) To answer your question -- The actual portsnap build server setup is more complex than the one in svn repository. Using spiped needs the other side of server (which serves svn repository). So no, it's not a pure configuration change, but a configuration change plus other setup to support it. That's said, we can confidently say "Yes" if the question is whether portsnap build server have trustworthy direct access to FreeBSD ports subversion repository. No MITM attack can happen without being noticed almost immediately in this chain. The other points you have raised are more important, though. One thing that we can easily implement to mitigate the freeze attack would probably to make portsnap snapshots expire after a reasonable amount of time (that is, publish a timestamp signed with the portsnap key, e.g. expires after 4 hours, so instead of "No updates found" you get "Snapshot was expired, something bad happen"), but that only narrows down the window and does not fully eliminate it. For freebsd-update I don't have a good idea at this time for the freeze attack. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTS3EdAAoJEJW2GBstM+nss60P/1nHbnjp09Qmtev6zGUJv979 yKNZNYTKY8wLtVrA/Y/nasW7oWwf37etFRrBiLds22F2wDRAVobEUVURoYAJJKMp +QRcQPaxMVPU5rZnF1+eHqp+n8LeTCfWrIaoHM3yeW/xD8O2tBgG7+YdOcIzCud8 OR3bOPwToebMnjck00fmYE8bxMs2vzJrDZCaY7b+6jrbNVbnPBZIywB50QaaaQih +I8Qekg6zBGWXciGaVISKMUTcAVXGFhN3qxsRisBvIxIOzBeho/EwwW+3ZW0LxfY 4pZouf6++HOhSh4Jf++TtgPjwmBgFWeZxTvTtag3VzEun9KXqVGvKQnUUj508Te/ GJA/pPAIDOqvxwaVi47EZD5aVd3xmgIUy/a1x8PS+iN3REvqh+y4dOYlTl2GqG7+ 5piWBygC+tqGV5oiXLKdzqnshN5KxY+lX3aCfXWlXEtH6Nnb8C+GmyA46XzNqP6N WYAmKPqC9Zv+z0nYJxy+nNoDpAiMmj/BjhtBkDSkEYoHx8d4bT5YUotiX43V2lnZ duJPyLbXfk4gUi7UrezOu3rQ2Cxxw/adsklVxKiEb6vzFby2+0C/PS8dOX12Gw1R XJ6vgviXjjxGQnuhyRf+7gyXEBZ5Hpk6B2Yfbt8+WORwnREk1anp0SsrJ4llBO0M AWwM/g92+yToCsP7CC4D =YOTq -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 05:36:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D285C3C for ; Mon, 14 Apr 2014 05:36:31 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97B1912D3 for ; Mon, 14 Apr 2014 05:36:30 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id b13so7715941wgh.29 for ; Sun, 13 Apr 2014 22:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q8PFKkSMQUCC3WWZESsLNH2otJbfht+138+tdXeauN0=; b=SdTLdOo5WjR4gmWpPEgnTTZJpJloZUAkVpIgUY5bYEyDsrCOkf3loG7eYeI4jJe8of KT8gFg2/0wljiq3LH32FdKwtCmeCQjW0Km0bSwJzEFz2+0fO00uBX07SSTEsk2wRDvKt +7GtHg0erdPnO5feIcpJ8SrEbfDNUTiV5AV2tKg2c1dr6iF1nBCpMqjKyyAP5PdOnfQ3 VuIuy9lFKtAO01/f/z82Vl1LIQTXuO0PPdnbg5/cZSRiCJODxrgjXjwmhe0dl5z64Y9N KNUMCG+cRayxVO7C/FLjcURirpmtnC+/eIoXDMbYbtqflivxafWtM5MQ14Ws7B4T5N9X sQhA== MIME-Version: 1.0 X-Received: by 10.180.93.133 with SMTP id cu5mr8026602wib.47.1397453788835; Sun, 13 Apr 2014 22:36:28 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Sun, 13 Apr 2014 22:36:28 -0700 (PDT) In-Reply-To: <20140414144155.C55844@sola.nimnet.asn.au> References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <20140414144155.C55844@sola.nimnet.asn.au> Date: Mon, 14 Apr 2014 00:36:28 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Lowell Gilbert , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:36:31 -0000 > Indeed it is not. David's solution - which seems to amount to removing > portsnap and herding the cats at home to DTRT about using svn securely - > relies on other cats being as smart and aware of the ramifications as he > is - a highly questionable proposition especially for the numerous more > naive users that portsnap renders the process of securely upgrading the > ports tree just about as simple and consistent as it can be. On the one hand I do get what you're saying. On the other I don't know that you're fairly characterizing the typical portsnap user. Building ports from source is not something I would think a novice FreeBSD user would do (make can be--and often is--an absolute nightmare!). Rather, I would imagine a novice would be using something like pkgng. > David, perhaps your obvious talent for auditing the portsnap code and > its server-side configuration might be better applied to remedying any > perceived vulnerabilities in conjunction with present and past security > officers and teams? Thanks. I'm happy to, and it's on my to-do list, the only problem is that I'm swamped with other projects and it's been sitting on that list for the past 2 years. It seems to be a similar problem for Colin and the Security Team. I'm hoping that by bringing this bug to the list that someone with more free time will be able to patch it. -David From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 08:20:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AA42218 for ; Mon, 14 Apr 2014 08:20:41 +0000 (UTC) Received: from mail.as41113.net (mail.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC6111F4 for ; Mon, 14 Apr 2014 08:20:40 +0000 (UTC) Received: from [172.21.87.41] (195.98.9.212.in-addr.arpa [212.9.98.195]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.as41113.net (Postfix) with ESMTPSA id 3g6jSd2lPnz7rBX; Mon, 14 Apr 2014 08:20:33 +0000 (UTC) Message-ID: <534B9A4D.5070404@rewt.org.uk> Date: Mon, 14 Apr 2014 09:20:29 +0100 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= Subject: Re: Proposal References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <86d2gqz2he.fsf@nine.des.no> <5345C98D.7030907@rewt.org.uk> <86bnw95um7.fsf@nine.des.no> In-Reply-To: <86bnw95um7.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 08:20:41 -0000 On 10/04/2014 11:47, Dag-Erling SmĆørgrav wrote: > Joe Holden writes: >> IME issues like this need to be patched first, tested later [...] > > If we'd done that and screwed up, you'd be on the barricades demanding > our heads. > > DES > Given the nature of the patch, and it being experimental (but still probably not as bad as leaving it unpatched) that wouldn't be the case, to be fair. From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 12:07:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4B9DC0B for ; Mon, 14 Apr 2014 12:07:23 +0000 (UTC) Received: from chronos.org.uk (vps.chronos.org.uk [IPv6:2001:470:1f09:cbf::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "chronos.org.uk", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4423D1FC5 for ; Mon, 14 Apr 2014 12:07:22 +0000 (UTC) Received: from workstation1.local.chronos.org.uk (workstation1.local.chronos.org.uk [IPv6:2001:470:1f09:12b::20]) (authenticated bits=0) by chronos.org.uk (8.14.7/8.14.7) with ESMTP id s3EC7IvT085450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 14 Apr 2014 13:07:19 +0100 (BST) (envelope-from matt@chronos.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at vps.chronos.org.uk DKIM-Filter: OpenDKIM Filter v2.8.3 chronos.org.uk s3EC7IvT085450 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=chronos.org.uk; s=mail; t=1397477239; bh=xDwl8BuWmEXUUrrnXJImSF48Cp1cKF467+1w7ekBhBc=; h=Date:From:To:Subject:In-Reply-To:References; b=Cupt6UiOSBZrfYcpswOrYvpniqgo1/11fyZmTCyXWJs9Y9fOIZNON7QgkKtOYCCTQ kCLfGB8Y7F5S7dDx/Zm4L5pFbAUXBKJWJXG5uWxvKrMVe8uI/YtSieeBuevgNNgSOt vTrcFDjqfKfFKd+PBrB729kE86XUaDZriJIwRU/w= Message-Id: <201404141207.s3EC7IvT085450@chronos.org.uk> Date: Mon, 14 Apr 2014 13:07:11 +0100 From: Matt Dawson To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <534B11F0.9040400@paladin.bulgarpress.com> References: <534B11F0.9040400@paladin.bulgarpress.com> X-Face: ZC(F49t2uSJE}/7#!TBN:A\3:0wCZNx7YbLr6|9~$^!V&Q, q&]T:H>?\|ZZUt:{]iKK'f.( g-{z6!F@Wt#^bC-X8J4ZW2}RKBA"ak_zQMGw\YT"R%aL+?kk_mnXchE8VSy^<7I5]Z@p/\B. h"4xoqXS)n^eTJL4BeAz1&b`_Jwb\s3M626%1{X4s>A>56]Sn$b0nRFhfrTk]]Njd|!O MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-99.5 required=3.0 tests=BAYES_00, DATE_IN_FUTURE_48_96,MISSING_MID,RP_MATCHES_RCVD,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on vps.chronos.org.uk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 12:07:23 -0000 On Mon, 14 Apr 2014 01:38:40 +0300 Todor Todorov wrote: > Oh now I sense some angst. Please ask Kirk McKusick, he knows the > story about why this is not being disclosed to FreeBSD. Sometimes I > feel a bit sorry for them (and for him), but then the next minute I > don't feel sorry because there's damn good reasons they won't be > told about what I found. My first thought when I saw this was "ego over ethics," which says more about Theo than FreeBSD. *If* there's an issue it'll come out eventually regardless of any little games the pseudo-deities wish to play. In the meantime, follow best practice, lock down your SSH, use keys rather than passwords, password protect the private key, ensure that only trusted people who need it get shell access and disable anything that isn't absolutely necessary. -- Safer alternative to smoking under threat from over-regulation due to pseudo-science and puritanism. Please help keep personal vapourisers available for ex and potential ex-smokers at http://www.efvi.eu/ by showing your support for this citizens' initiative. From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 12:32:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08F3C1D4 for ; Mon, 14 Apr 2014 12:32:34 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9844F125E for ; Mon, 14 Apr 2014 12:32:33 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3ECWF2B081179; Mon, 14 Apr 2014 13:32:16 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3ECWFQ1081178; Mon, 14 Apr 2014 13:32:15 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> Date: Mon, 14 Apr 2014 13:32:15 +0100 To: matt@chronos.org.uk, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> In-Reply-To: <201404141207.s3EC7IvT085450@chronos.org.uk> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Mon, 14 Apr 2014 13:32:16 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 12:32:34 -0000 Matt Dawson wrote: > My first thought when I saw this was "ego over ethics," which says more > about Theo than FreeBSD. Totally. I know Theo has a reputation for being 'difficult', but in my opinion, this outburst really calls into question his perceived motivations regarding secure software. As to the specific question, I don't think his ego would allow a bug in openssh to persist, so even if it does, I'd suspect it's not too serious (or it's non-trivial to exploit), and it's related to FreeBSD produced 'glue'. This is total guesswork on my part, but I'd therefore assume he was talkining about openssh in base, rarther than openssh-portable in ports. From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 20:42:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A0D9B89 for ; Mon, 14 Apr 2014 20:42:57 +0000 (UTC) Received: from nm3-vm5.bullet.mail.ne1.yahoo.com (nm3-vm5.bullet.mail.ne1.yahoo.com [98.138.91.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E298F18C8 for ; Mon, 14 Apr 2014 20:42:56 +0000 (UTC) Received: from [98.138.226.180] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 14 Apr 2014 20:41:03 -0000 Received: from [98.138.101.182] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 14 Apr 2014 20:41:03 -0000 Received: from [127.0.0.1] by omp1093.mail.ne1.yahoo.com with NNFMP; 14 Apr 2014 20:41:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 18541.41340.bm@omp1093.mail.ne1.yahoo.com Received: (qmail 34683 invoked by uid 60001); 14 Apr 2014 20:41:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397508062; bh=1cYJIMrpJJUL/kO/ZbNqpMbAmSc7WksRfLR25sMiSlo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=JEYdInowxTgITVj6q2rEWE2ZYspVG3IKVhB46xC2o3xTZNj3M3z4IkRiyNHjQzM0a1NKjyKLBfgJOIsKsV3I0ZBSN4lCVskxQ01elh16o5fER1n3uWXcqNID762zmw2GTCXjVzlnWEqES7+mUU0GwzzwTIuzT0GnYASGuqhIkSk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Hz3bCNnzHfvyUpJyVF0PO/SJdlyfzsSn1/GqfWJQoBon8nWauhX1O7RqDlDuhrnPsGwo6xWxSfTxSs0kjyE5wA9lZWzHwHYQ+TiiGZeLBKU0ygKSnNywBzCeByD+jtzYfQZ6xICNVKaqksJmSKYKFfJoY5T4BWGE/pnjzqI1HN4=; X-YMail-OSG: DNaUFBwVM1mo61mb1rVy_NReS5PwTpKWtdqt36vZeLS_CJn 0V53n5E8sEwlM9UITPpAdnscXR0Yro_RSEqW5RYHNud17R1TukZnXRa3u7ot qPwIjtmag6jao7X6WItf9Z.X.D2PueGoAGf.zGhvUj4PWOxEkBfP4W6pw8So G6nJxmAjnI.OlVDjUP36iHQD3LW4kr8VuvMlhraZzb0QBwCAScxD3FfeHubb ZfkHLfcj.6qYyFuQEo2xaOmd35JhGEOBEpiKS4yKNXAnDfuiDxpEstb6Do11 onD7hXFvq2WH17ieELYeFm35K_tdoT3B1L9kb7by6fKLS7LN79CWskA.708P cUXi1OXDP8QFgaSSVGFBzbphnL4leI_w8cTTBEUX3cAaFw1udiH1LxfrzINn Nq6AZDwuicgYbnmUntsvMH0zwYaqeY4yiVvP2O6DoJzbdPAOpCKFH00qDyWS mR09Ju_SrhC1sA8RqBmRjLaZr8WXjmubUiFTlcX_w9DUXoyPUSt33jFL0zti tK19dmlYnczOyxZaICrkUxzj9FGIKplPz.1lPYBhx_HsnYg-- Received: from [66.129.241.11] by web122306.mail.ne1.yahoo.com via HTTP; Mon, 14 Apr 2014 13:41:02 PDT X-Rocket-MIMEInfo: 002.001, aGksIGFsbDoKCmFyZSB0aGVyZSBhbnkgdWRwIGZsb29kaW5nIHRvb2xzIHVuZGVyIGZyZWVic2Q_IHdlIGhhdmUgd2luNyBiYXNlZCB1bmljb3JuIG1hY2hpbmUgcnVubmluZyBpbiB0aGUgbGFiLCB3b25kZXJpbmcgd2hhdCBpcyBlcXVpdmFsZW50IHVuZGVyIGZyZWVic2QuCgp0aGFua3MKATABAQEB X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1397508062.26125.YahooMailNeo@web122306.mail.ne1.yahoo.com> Date: Mon, 14 Apr 2014 13:41:02 -0700 (PDT) From: gahn Subject: udp flood tools for freebsd To: freebsd security MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gahn List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:42:57 -0000 hi, all: are there any udp flooding tools under freebsd? we have win7 based unicorn machine running in the lab, wondering what is equivalent under freebsd. thanks From owner-freebsd-security@FreeBSD.ORG Mon Apr 14 20:46:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A4A2D12 for ; Mon, 14 Apr 2014 20:46:25 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C89C8191C for ; Mon, 14 Apr 2014 20:46:24 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s3EKkK74091605; Mon, 14 Apr 2014 16:46:20 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <534C4911.9010800@sentex.net> Date: Mon, 14 Apr 2014 16:46:09 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: gahn , freebsd security Subject: Re: udp flood tools for freebsd References: <1397508062.26125.YahooMailNeo@web122306.mail.ne1.yahoo.com> In-Reply-To: <1397508062.26125.YahooMailNeo@web122306.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:46:25 -0000 On 4/14/2014 4:41 PM, gahn wrote: > are there any udp flooding tools under freebsd? we have win7 based unicorn machine running in the lab, wondering what is equivalent under freebsd. Try the tools in /usr/src/tools/tools/netrate and netmap. Netmap is handy if you want really high pps rates ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Sat Apr 19 10:02:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB7CF266; Sat, 19 Apr 2014 10:02:32 +0000 (UTC) Received: from chronos.org.uk (vps.chronos.org.uk [IPv6:2001:470:1f09:cbf::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "chronos.org.uk", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 70FFA12D0; Sat, 19 Apr 2014 10:02:32 +0000 (UTC) Received: from workstation1.local.chronos.org.uk (workstation1.local.chronos.org.uk [IPv6:2001:470:1f09:12b::20]) (authenticated bits=0) by chronos.org.uk (8.14.7/8.14.7) with ESMTP id s3JA2KhF047708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 19 Apr 2014 11:02:22 +0100 (BST) (envelope-from matt@chronos.org.uk) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at vps.chronos.org.uk DKIM-Filter: OpenDKIM Filter v2.8.3 chronos.org.uk s3JA2KhF047708 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=chronos.org.uk; s=mail; t=1397901742; bh=sTEqPWf6IFwbKZ5VUu0PtN4wsSbSxpUCoD8ccAGX2ew=; h=Date:From:To:Subject:In-Reply-To:References; b=XqvILqGtB9K5+jSwEdcKZ14Tkqu6x5J/paz6ns/tztIz7JWSpYwQqsOpe857meO91 qExjNkJf8fTws90EPSSEfRrh3AKkflqT3KBLeCPveBA5ixEYYeNH1WSVoDkVyzsFNc EKdJvbbpneHJwm1AezyHys8YQUHS+ymk3LjTMziM= Message-Id: <201404191002.s3JA2KhF047708@chronos.org.uk> Date: Sat, 19 Apr 2014 11:02:03 +0100 From: Matt Dawson To: Bryan Drewery , Jamie Landeg-Jones , Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <53522186.9030207@FreeBSD.org> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> X-Face: ZC(F49t2uSJE}/7#!TBN:A\3:0wCZNx7YbLr6|9~$^!V&Q, q&]T:H>?\|ZZUt:{]iKK'f.( g-{z6!F@Wt#^bC-X8J4ZW2}RKBA"ak_zQMGw\YT"R%aL+?kk_mnXchE8VSy^<7I5]Z@p/\B. h"4xoqXS)n^eTJL4BeAz1&b`_Jwb\s3M626%1{X4s>A>56]Sn$b0nRFhfrTk]]Njd|!O MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Spam-Status: No, score=-98.5 required=3.0 tests=BAYES_00, DATE_IN_FUTURE_48_96,MIME_BASE64_TEXT,MISSING_MID,RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on vps.chronos.org.uk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 10:02:32 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTYXQs IDE5IEFwciAyMDE0IDAyOjExOjAyIC0wNTAwDQpCcnlhbiBEcmV3ZXJ5IDxiZHJld2VyeUBGcmVl QlNELm9yZz4gd3JvdGU6DQoNCj4gQXMgdGhlIG1haW50YWluZXIgb2YgdGhlIHBvcnQgSSB3aWxs IHNheSB0aGF0IHlvdXIgc2VjdXJpdHkgZGVjcmVhc2VzDQo+IHdpdGggZWFjaCBPUFRJT04vcGF0 Y2ggeW91IGFwcGx5LiBJIHJlYWxseSB3b3VsZCBub3QgYmUgc3VycHJpc2VkIGlmDQo+IG9uZSBv ZiB0aGUgb3B0aW9uYWwgcGF0Y2hlcyBhdmFpbGFibGUgaW4gdGhlIHBvcnQgaGFkIGlzc3Vlcy4N Cg0KSW4gYWxsIGhvbmVzdHksIGNvZGUgaXMgbm93IHNvIGNvbXBsZXggdGhhdCB0aGVyZSBhcmUg YWx3YXlzIGdvaW5nIHRvDQpiZSBpc3N1ZXMgdGhhdCB3b24ndCBiZWNvbWUgYXBwYXJlbnQgdW50 aWwgYW4gZXhwbG9pdCBpcyBmb3VuZC4gVGhlc2UNCmFyZSB0aGUgcmlza3Mgd2UgdGFrZSB3aGVu IGFsbG93aW5nIHN5c3RlbXMgdG8gY29tbXVuaWNhdGUuIFRoZSBwZW9wbGUNCmZvbWVudGluZyBk aXNjb3JkIGFyZSBzaW1wbHkgdGFraW5nIGFkdmFudGFnZSBvZiB0aGUgc2l0dWF0aW9uIHRvDQpp bmZsYXRlIHRoZWlyIGVnb3MgYW5kIGZvbGxvdyBvdGhlciBhZ2VuZGFzLCB3aGV0aGVyIHRoYXQg YmUgYXR0YWNraW5nDQpvcGVuIHNvdXJjZSwgYXR0YWNraW5nIEZyZWVCU0QsIGp1c3RpZnlpbmcg dGhlaXIgb3duIGV4aXN0ZW5jZSBvcg0Kc2ltcGx5IGRldmlsdHJ5LiBPaCwgYW5kIGl0IG1ha2Vz IGZvciBnb29kIGNvcHksIG9mIGNvdXJzZS4gV291bGRuJ3QNCndhbnQgcGVvcGxlIHRvIGZvcmdl dCB5b3UncmUgdGhlcmUsIGVoPw0KDQpBbGwgd2UgYXMgdXNlcnMgY2FuIGRvIGlzIGFwcGx5IGNv bW1vbiBzZW5zZSB3aGVuIGRlcGxveWluZyBjcml0aWNhbA0Kc2VydmljZXMgc3VjaCBhcyB0aGVz ZSBhbmQgcmVkdWNlIHRoZSBhdHRhY2sgdmVjdG9yIHN1cmZhY2UgYXJlYSAocmUNCkJyeWFuJ3Mg bm90ZSBvbiB0aGUgcG9ydCBvcHRpb25zKSBhcyBtdWNoIGFzIHBvc3NpYmxlLiBBc3N1bWUgaXQg aGFzDQpob2xlcywgZGVwbG95IG9uIHRoYXQgYmFzaXMsIGluc3RhbGwgZGlnaXRhbCByb3R0d2Vp bGVyICh3aG8gbWF5IGFsc28NCmhhdmUgaG9sZXMgYnV0LCBwbGVhc2UgJERFSVRZLCBub3QgdGhl IHNhbWUgb25lcykgdG8gbWl0aWdhdGUuDQoNClByYWdtYXRpc20gc2hvdWxkIGJlIGEgcmVxdWly ZWQgZGlzY2lwbGluZS4NCi0gLS0gDQpTYWZlciBhbHRlcm5hdGl2ZSB0byBzbW9raW5nIHVuZGVy IHRocmVhdCBmcm9tIG92ZXItcmVndWxhdGlvbg0KZHVlIHRvIHBzZXVkby1zY2llbmNlIGFuZCBw dXJpdGFuaXNtLiBQbGVhc2UgaGVscCBrZWVwIHBlcnNvbmFsDQp2YXBvdXJpc2VycyBhdmFpbGFi bGUgZm9yIGV4IGFuZCBwb3RlbnRpYWwgZXgtc21va2VycyBhdCANCmh0dHA6Ly93d3cuZWZ2aS5l dS8gYnkgc2hvd2luZyB5b3VyIHN1cHBvcnQgZm9yIHRoaXMgY2l0aXplbnMnDQppbml0aWF0aXZl LiANCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mi4wLjIy IChGcmVlQlNEKQ0KDQppRVlFQVJFQ0FBWUZBbE5TU2FJQUNna1FBbVQ5dVk4ZXVpSnk2d0NnaTgz TEJZZDVyWVRXT2tYZFRVK0pkOFJXDQpTNDRBb0tUZkRuYjVYS3NwTDNQOVluVmN1VjhQK0lxTw0K PWV6RWMNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-security@FreeBSD.ORG Sat Apr 19 07:11:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55877235 for ; Sat, 19 Apr 2014 07:11:10 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C1201612 for ; Sat, 19 Apr 2014 07:11:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3J7B9Ln096774 for ; Sat, 19 Apr 2014 07:11:09 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3J7B9SW096771 for freebsd-security@freebsd.org; Sat, 19 Apr 2014 07:11:09 GMT (envelope-from bdrewery) Received: (qmail 65548 invoked from network); 19 Apr 2014 02:11:07 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Apr 2014 02:11:07 -0500 Message-ID: <53522186.9030207@FreeBSD.org> Date: Sat, 19 Apr 2014 02:11:02 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jamie Landeg-Jones , matt@chronos.org.uk, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> In-Reply-To: <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Brm0le8XSWtQUgIkcvVj5GvFmEXSX9kNh" X-Mailman-Approved-At: Sat, 19 Apr 2014 18:19:01 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 07:11:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Brm0le8XSWtQUgIkcvVj5GvFmEXSX9kNh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: > Matt Dawson wrote: >=20 >> My first thought when I saw this was "ego over ethics," which says mor= e >> about Theo than FreeBSD. >=20 > Totally. >=20 > I know Theo has a reputation for being 'difficult', but in my opinion, > this outburst really calls into question his perceived motivations > regarding secure software. >=20 > As to the specific question, I don't think his ego would allow a bug > in openssh to persist, so even if it does, I'd suspect it's not too > serious (or it's non-trivial to exploit), and it's related to FreeBSD > produced 'glue'. >=20 > This is total guesswork on my part, but I'd therefore assume he was > talkining about openssh in base, rarther than openssh-portable in > ports. >=20 As the maintainer of the port I will say that your security decreases with each OPTION/patch you apply. I really would not be surprised if one of the optional patches available in the port had issues. --=20 Regards, Bryan Drewery --Brm0le8XSWtQUgIkcvVj5GvFmEXSX9kNh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUiGGAAoJEDXXcbtuRpfPTNoIANblIe8v5jAl4QNT8FapyKtw 0SN5a0qHyLKPGhE1gTBsiZabM/B3hR1d62ph0U4L+fGv/+pBlaO1KmGBg5Oekjf8 MzTEJPC7veQeEFCZDgu0hVTiPYLAA0MtwmSkxgVu8Dppm3pDE/07mj/sZvW+kMSA vxWLg+xmJq4SjbW3srA0kHHOw9a22wIIQMiGXmNAruLlXa49eWzDRUXfpkX/3S0D 0/ks4AgQ2FC+62MY/FG4waOjVWtX7zamPDSk+JmgRVFPlaDdRirTpmqIR91aFeud 1mlpV4VUAvDxeSTjk5bKV4kD+nCg2IpXaTo14fXDFk7B1fnihOPPZul483LcuJk= =5Okr -----END PGP SIGNATURE----- --Brm0le8XSWtQUgIkcvVj5GvFmEXSX9kNh-- From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 01:46:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6E7CE4B for ; Sun, 20 Apr 2014 01:46:39 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C051179D for ; Sun, 20 Apr 2014 01:46:39 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id q8so2382319lbi.28 for ; Sat, 19 Apr 2014 18:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:in-reply-to:references:comments:mime-version :content-type:content-id:date:message-id; bh=7gDXrVDv4FnMpx3p8p7DJv8/6Ay6Px2xFCxrbAYB604=; b=JjnVoO2z0fUB/fpI/8IU198gRTO1TcvX7Vk7N+zJkS8wb864EZ1fAmYk6J3CaUuJxQ EZTj282WrkRxt5Yk0+0qp8RpQKTbTclWcvDPzqIoOIouJ0m9IoyRBQhIBmW6fC1Oxvlq Y2nJ+fup2vVTiLwyrxBz6spr2yP+/j6+7FU/fkC9vq+2BOEbnwqWaq+7UGf2PNk29q3F bUaSEj3MG2SZ22w/2wdBsWMftbVBy7/9EOjZtbVgoaYsdx845Zk88BBGL1vu5wGywVgA xDs7cVzvfLh+y7DNNAcm7dNLLiPAzmvXj6lMYQDV0kJe6FUAJyCc3p28rEHhngwBg6ZN cdeA== X-Received: by 10.112.150.233 with SMTP id ul9mr17104622lbb.2.1397958396981; Sat, 19 Apr 2014 18:46:36 -0700 (PDT) Received: from edge ([91.123.18.167]) by mx.google.com with ESMTPSA id r5sm32456962lbb.7.2014.04.19.18.46.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 18:46:36 -0700 (PDT) Received: from misha (uid 1001) (envelope-from misha@edge) id ab7281 by edge (DragonFly Mail Agent v0.9); Sun, 20 Apr 2014 05:46:34 +0400 From: Mikhail To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-reply-to: <53522186.9030207@FreeBSD.org> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> Comments: In-reply-to Bryan Drewery message dated "Sat, 19 Apr 2014 02:11:02 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42950.1397958394.1@edge> Date: Sun, 20 Apr 2014 05:46:34 +0400 Message-Id: <535326fa.ab7281.696ea278@edge> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 01:46:40 -0000 >On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: >> Matt Dawson wrote: >> >>> My first thought when I saw this was "ego over ethics," which says more >>> about Theo than FreeBSD. >> >> Totally. >> >> I know Theo has a reputation for being 'difficult', but in my opinion, >> this outburst really calls into question his perceived motivations >> regarding secure software. >> >> As to the specific question, I don't think his ego would allow a bug >> in openssh to persist, so even if it does, I'd suspect it's not too >> serious (or it's non-trivial to exploit), and it's related to FreeBSD >> produced 'glue'. >> >> This is total guesswork on my part, but I'd therefore assume he was >> talkining about openssh in base, rarther than openssh-portable in >> ports. >> > >As the maintainer of the port I will say that your security decreases >with each OPTION/patch you apply. I really would not be surprised if one >of the optional patches available in the port had issues. I believe that Theo just browbeat. Reasons? It was looooong ago, I think very few still remember, but Theo definitely does: http://lists.freebsd.org/pipermail/freebsd-security/2005-March/002719.html From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 04:34:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA5CDF52 for ; Sun, 20 Apr 2014 04:34:57 +0000 (UTC) Received: from bcnetw2.asu.edu (bcnetw2.asu.edu [149.169.2.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "asmtp.asu.edu", Issuer "InCommon Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95F051666 for ; Sun, 20 Apr 2014 04:34:57 +0000 (UTC) X-ASG-Debug-ID: 1397968495-064f8d1de96ebba0001-2RkMqc Received: from exhubw02.asurite.ad.asu.edu (exhubw02.asurite.ad.asu.edu [129.219.4.200]) by bcnetw2.asu.edu with ESMTP id hDDCocKMCVafOuE4 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Sat, 19 Apr 2014 21:34:55 -0700 (MST) X-Barracuda-Envelope-From: Brandon.Vincent@asu.edu X-Barracuda-Apparent-Source-IP: 129.219.4.200 X-ASG-Whitelist: Client Received: from EXMBW03.asurite.ad.asu.edu ([169.254.10.154]) by exhubw02.asurite.ad.asu.edu ([129.219.4.200]) with mapi id 14.03.0174.001; Sat, 19 Apr 2014 21:34:55 -0700 From: "Brandon Vincent (Student)" To: Mikhail , "freebsd-security@freebsd.org" Subject: RE: De Raadt + FBSD + OpenSSH + hole? Thread-Topic: De Raadt + FBSD + OpenSSH + hole? X-ASG-Orig-Subj: RE: De Raadt + FBSD + OpenSSH + hole? Thread-Index: AQHPXDpjgQXq/GHN40GC7qnqTu79jJsZ6nMI Date: Sun, 20 Apr 2014 04:34:54 +0000 Message-ID: <586745645D88D740AF5C0346EF5AB800169AE8D4@exmbw03.asurite.ad.asu.edu> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org>,<535326fa.ab7281.696ea278@edge> In-Reply-To: <535326fa.ab7281.696ea278@edge> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.219.4.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: exhubw02.asurite.ad.asu.edu[129.219.4.200] X-Barracuda-Start-Time: 1397968495 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://149.169.2.72:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at asu.edu X-Barracuda-BRTS-Status: 1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 04:34:58 -0000 It seems like this attitude will provide fuel to the argument that open-sou= rce software is inherently less secure.=0A= =0A= I'm surprised that SSH Communications Security hasn't used these posts yet = as an argument to why their product is more secure.=0A= =0A= Brandon Vincent=0A= ________________________________________=0A= From: owner-freebsd-security@freebsd.org [owner-freebsd-security@freebsd.or= g] on behalf of Mikhail [mp39590@gmail.com]=0A= Sent: Saturday, April 19, 2014 6:46 PM=0A= To: freebsd-security@freebsd.org=0A= Subject: Re: De Raadt + FBSD + OpenSSH + hole?=0A= =0A= >On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote:=0A= >> Matt Dawson wrote:=0A= >>=0A= >>> My first thought when I saw this was "ego over ethics," which says more= =0A= >>> about Theo than FreeBSD.=0A= >>=0A= >> Totally.=0A= >>=0A= >> I know Theo has a reputation for being 'difficult', but in my opinion,= =0A= >> this outburst really calls into question his perceived motivations=0A= >> regarding secure software.=0A= >>=0A= >> As to the specific question, I don't think his ego would allow a bug=0A= >> in openssh to persist, so even if it does, I'd suspect it's not too=0A= >> serious (or it's non-trivial to exploit), and it's related to FreeBSD=0A= >> produced 'glue'.=0A= >>=0A= >> This is total guesswork on my part, but I'd therefore assume he was=0A= >> talkining about openssh in base, rarther than openssh-portable in=0A= >> ports.=0A= >>=0A= >=0A= >As the maintainer of the port I will say that your security decreases=0A= >with each OPTION/patch you apply. I really would not be surprised if one= =0A= >of the optional patches available in the port had issues.=0A= =0A= I believe that Theo just browbeat. Reasons? It was looooong ago, I think=0A= very few still remember, but Theo definitely does:=0A= =0A= http://lists.freebsd.org/pipermail/freebsd-security/2005-March/002719.html= =0A= _______________________________________________=0A= freebsd-security@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-security=0A= To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"= =0A= From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 05:48:51 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 146594FA; Sun, 20 Apr 2014 05:48:51 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A25571AE3; Sun, 20 Apr 2014 05:48:50 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3K5mVuZ055245; Sun, 20 Apr 2014 06:48:31 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3K5mV7N055244; Sun, 20 Apr 2014 06:48:31 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> Date: Sun, 20 Apr 2014 06:48:31 +0100 To: matt@chronos.org.uk, jamie@dyslexicfish.net, freebsd-security@FreeBSD.org, bdrewery@FreeBSD.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> In-Reply-To: <53522186.9030207@FreeBSD.org> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Sun, 20 Apr 2014 06:48:32 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 05:48:51 -0000 Bryan Drewery wrote: > On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: > > > > As to the specific question, I don't think his ego would allow a bug > > in openssh to persist, so even if it does, I'd suspect it's not too > > serious (or it's non-trivial to exploit), and it's related to FreeBSD > > produced 'glue'. > > > > This is total guesswork on my part, but I'd therefore assume he was > > talkining about openssh in base, rarther than openssh-portable in > > ports. > > > > As the maintainer of the port I will say that your security decreases > with each OPTION/patch you apply. I really would not be surprised if one > of the optional patches available in the port had issues. Ahhhh. good point. I forgot about third-party patches. Yeah, if he's not just blowing smoke, that would make the most sense. I don't reckon he'd leave an exploit open if it was purely related to the unpatched source - even if there is some quirk which only makes it only applicable to FreeBSD. Still, by not revealing it, he's only potentially hurting the users. I wonder how many blackhats are going to use this thread as a heads-up? Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 17:35:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 284A2172 for ; Sun, 20 Apr 2014 17:35:05 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0254812EC for ; Sun, 20 Apr 2014 17:35:04 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 2FCD4B822E for ; Sun, 20 Apr 2014 12:26:31 -0500 (CDT) To: freebsd-security@freebsd.org Date: Sun, 20 Apr 2014 12:25:27 -0500 Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> Message-ID: <53540307.1070708@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Sun, 20 Apr 2014 12:25:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 17:35:05 -0000 On 04/20/2014 12:48 AM, Jamie Landeg-Jones wrote: > Bryan Drewery wrote: > >> On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: >>> As to the specific question, I don't think his ego would allow a bug >>> in openssh to persist, so even if it does, I'd suspect it's not too >>> serious (or it's non-trivial to exploit), and it's related to FreeBSD >>> produced 'glue'. >>> >>> This is total guesswork on my part, but I'd therefore assume he was >>> talkining about openssh in base, rarther than openssh-portable in >>> ports. >>> >> As the maintainer of the port I will say that your security decreases >> with each OPTION/patch you apply. I really would not be surprised if one >> of the optional patches available in the port had issues. > Ahhhh. good point. I forgot about third-party patches. > > Yeah, if he's not just blowing smoke, that would make the most sense. > > I don't reckon he'd leave an exploit open if it was purely related to > the unpatched source - even if there is some quirk which only makes > it only applicable to FreeBSD. > > Still, by not revealing it, he's only potentially hurting the users. > > I wonder how many blackhats are going to use this thread as a heads-up? > > Cheers, Jamie > _______________________________________________ > I wonder how many security holes, both those known and as yet unrevealed or unknown, would not be of any exploit value if in all security related libraries and applications the routine to free allocated memory allocation closest to the user app/library set the newly free memory to a known pattern or something from /dev/random before returning. And, similarly, a compiler option causing function returns using more than a few dozen bytes of stack space to erase the newly freed stack region just prior to resuming the caller. Harry From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 18:31:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C32D8F2C for ; Sun, 20 Apr 2014 18:31:16 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DDE21760 for ; Sun, 20 Apr 2014 18:31:16 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3KIVCNt054779; Sun, 20 Apr 2014 19:31:13 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3KIVCSY054778; Sun, 20 Apr 2014 19:31:12 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> Date: Sun, 20 Apr 2014 19:31:12 +0100 To: hcoin@quietfountain.com, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> In-Reply-To: <53540307.1070708@quietfountain.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Sun, 20 Apr 2014 19:31:13 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 18:31:16 -0000 > I wonder how many security holes, both those known and as yet unrevealed > or unknown, would not be of any exploit value if in all security related > libraries and applications the routine to free allocated memory > allocation closest to the user app/library set the newly free memory to > a known pattern or something from /dev/random before returning. And, > similarly, a compiler option causing function returns using more than a > few dozen bytes of stack space to erase the newly freed stack region I'm probably being really dense here, and realise I can't delete this post once sent! But.... Once memory has been freed, I thought any attempt by a user process to access it would cause a SIGSEV. I thought the issue was with programs that inadvertantly expose (either to read or write) other parts of their active memory. Of course, if a process rolls it's own in-process implementation of malloc/free, then this point is moot, but once you free memory back to the system, isn't in no longer accessable anyway? Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 19:00:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5269557D for ; Sun, 20 Apr 2014 19:00:30 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A1AD19AE for ; Sun, 20 Apr 2014 19:00:30 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wn1so3542065obc.18 for ; Sun, 20 Apr 2014 12:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JonhdtaXm6bnLkksht+/51A44wRNA/gdmLb1FGNih9w=; b=Oa9zbxlsmhzdmXsb2OMz4s1j7f/hHwvPSz61ZmUyXivxcijQ5TyUpYP77kxCMpKj2O ko7gIX7G8+NAjLh10rtn6A2s8tBTPK3uGZdR98OObKuLtSbJWuFnpJFUw95VRgCdPqnK U1RBKy3dUDL5vslQbdsENIpMckDH5MM6ujlLfF1NZjBisikD+721ANT7Z6yl3AXL0AF9 iRjuUKVslxpED211s6UrRPHATawWdQq4gGHdHSy2yBaL63VR8PCEmtl0G18TFR7NvYHL EXb0q/gaSPY3Z+ExtmV2fktQlahClM4TtM0rvlLaoC4DbdOQyOyWhtwMsZwABsGI9ReA w4OA== MIME-Version: 1.0 X-Received: by 10.182.87.42 with SMTP id u10mr27769156obz.22.1398020428859; Sun, 20 Apr 2014 12:00:28 -0700 (PDT) Sender: ndorfman@gmail.com Received: by 10.60.158.106 with HTTP; Sun, 20 Apr 2014 12:00:28 -0700 (PDT) In-Reply-To: <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> Date: Sun, 20 Apr 2014 15:00:28 -0400 X-Google-Sender-Auth: Vsn6LrzhY_o-Av9CO9S7T0PYawI Message-ID: Subject: Re: De Raadt + FBSD + OpenSSH + hole? From: Nathan Dorfman To: Jamie Landeg-Jones Content-Type: text/plain; charset=UTF-8 Cc: hcoin@quietfountain.com, freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 19:00:30 -0000 On Sun, Apr 20, 2014 at 2:31 PM, Jamie Landeg-Jones wrote: > Once memory has been freed, I thought any attempt by a user process to > access it would cause a SIGSEV. > > I thought the issue was with programs that inadvertantly expose (either > to read or write) other parts of their active memory. > > Of course, if a process rolls it's own in-process implementation > of malloc/free, then this point is moot, but once you free memory back > to the system, isn't in no longer accessable anyway? free() doesn't usually "free memory back to the system." It just puts it back onto a "free list" managed by libc, entirely within the process's address space. "Use after free" is actually a rather common type of bug -- do a web search on that term to see just how often it comes up. -nd. From owner-freebsd-security@FreeBSD.ORG Sun Apr 20 21:00:43 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CA4AECC for ; Sun, 20 Apr 2014 21:00:43 +0000 (UTC) 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)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5EB4144C for ; Sun, 20 Apr 2014 21:00:42 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id x13so2082741wgg.33 for ; Sun, 20 Apr 2014 14:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=HLvjEGKzzT8MfeQdUI3nwM2SQd0ROqus1cvjIgxoDxI=; b=ncKdOvjANXYZqM3Iaj0X11BIKYv22biHyd1fV1AOvj3pZokucvC3mxDyd5I4bkdSsa 32lB42zHmdNnaboLmezhxn1eippKbtyWP8ve4aSnprI2R5CDAaIzAHw8eWhYa+cpcuS0 gzmEbY1MWUjrTcRZ0HuecXwNu5xsiWbNENJoxYyhl06n5tLPDYe4i7rAFCWd18eipYjE 0RFuGXejWnPlnddDk5oFTm4ejuzcdBbuO/wKtuC20YbQsnzhCnobjl3SEtU+rhGeKwr2 sr/guVgrDRzpoSrnOU2jurKUOpU8L2CtxaA4iffDoOhu1HbluYTpVIlMAEAUjl7Al3dv VOxg== X-Received: by 10.180.211.239 with SMTP id nf15mr11100859wic.9.1398027640937; Sun, 20 Apr 2014 14:00:40 -0700 (PDT) Received: from gumby.homeunix.com (5ec2dc28.skybroadband.com. [94.194.220.40]) by mx.google.com with ESMTPSA id go20sm26279196wjc.18.2014.04.20.14.00.40 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 20 Apr 2014 14:00:40 -0700 (PDT) Date: Sun, 20 Apr 2014 22:00:37 +0100 From: RW To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140420220037.076be9d0@gumby.homeunix.com> In-Reply-To: References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 21:00:43 -0000 On Sun, 20 Apr 2014 15:00:28 -0400 Nathan Dorfman wrote: > On Sun, Apr 20, 2014 at 2:31 PM, Jamie Landeg-Jones > wrote: > > Once memory has been freed, I thought any attempt by a user process > > to access it would cause a SIGSEV. > > > > I thought the issue was with programs that inadvertantly expose > > (either to read or write) other parts of their active memory. > > > > Of course, if a process rolls it's own in-process implementation > > of malloc/free, then this point is moot, but once you free memory > > back to the system, isn't in no longer accessable anyway? > > free() doesn't usually "free memory back to the system." It just puts > it back onto a "free list" managed by libc, entirely within the > process's address space. It can return the physical memory, but there are a couple of caveats. Firstly, it can only return whole pages. Secondly, it's not returned instantaneously to avoid the overhead of page-faults and zeroing pages if that region is remalloced. It's left to the page-daemon to recover the physical memory in its own time, and it remains readable by it's previous process until it's reassigned. From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 00:13:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCC48224 for ; Mon, 21 Apr 2014 00:13:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B758C137F for ; Mon, 21 Apr 2014 00:13:32 +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 s3L01NvZ062804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2014 17:01:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3L01M8X062803; Sun, 20 Apr 2014 17:01:22 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Apr 2014 17:01:22 -0700 From: John-Mark Gurney To: hcoin Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140421000122.GS43976@funkthat.com> Mail-Followup-To: hcoin , freebsd-security@freebsd.org References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53540307.1070708@quietfountain.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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Sun, 20 Apr 2014 17:01:23 -0700 (PDT) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 00:13:33 -0000 hcoin wrote this message on Sun, Apr 20, 2014 at 12:25 -0500: > On 04/20/2014 12:48 AM, Jamie Landeg-Jones wrote: > >Bryan Drewery wrote: > > > >>On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: > >>>As to the specific question, I don't think his ego would allow a bug > >>>in openssh to persist, so even if it does, I'd suspect it's not too > >>>serious (or it's non-trivial to exploit), and it's related to FreeBSD > >>>produced 'glue'. > >>> > >>>This is total guesswork on my part, but I'd therefore assume he was > >>>talkining about openssh in base, rarther than openssh-portable in > >>>ports. > >>> > >>As the maintainer of the port I will say that your security decreases > >>with each OPTION/patch you apply. I really would not be surprised if one > >>of the optional patches available in the port had issues. > >Ahhhh. good point. I forgot about third-party patches. > > > >Yeah, if he's not just blowing smoke, that would make the most sense. > > > >I don't reckon he'd leave an exploit open if it was purely related to > >the unpatched source - even if there is some quirk which only makes > >it only applicable to FreeBSD. > > > >Still, by not revealing it, he's only potentially hurting the users. > > > >I wonder how many blackhats are going to use this thread as a heads-up? > > > >Cheers, Jamie > >_______________________________________________ > > > I wonder how many security holes, both those known and as yet unrevealed > or unknown, would not be of any exploit value if in all security related > libraries and applications the routine to free allocated memory > allocation closest to the user app/library set the newly free memory to > a known pattern or something from /dev/random before returning. And, > similarly, a compiler option causing function returns using more than a > few dozen bytes of stack space to erase the newly freed stack region > just prior to resuming the caller. there is an option to do this w/ malloc(3): J Each byte of new memory allocated by malloc(), realloc(), or reallocf() will be initialized to 0xa5. All memory returned by free(), realloc(), or reallocf() will be initialized to 0x5a. This is intended for debugging and will impact performance nega- tively. This used to be eanbled by default on HEAD, but apparently isn't any more... -- 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 Mon Apr 21 00:35:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C7F447B for ; Mon, 21 Apr 2014 00:35:34 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 39FC21569 for ; Mon, 21 Apr 2014 00:35:34 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 337EEB827F for ; Sun, 20 Apr 2014 19:35:33 -0500 (CDT) To: freebsd-security@freebsd.org Date: Sun, 20 Apr 2014 19:34:29 -0500 Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <20140421000122.GS43976@funkthat.com> Message-ID: <53546795.9050304@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Sun, 20 Apr 2014 19:34:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 00:35:34 -0000 On 04/20/2014 07:01 PM, John-Mark Gurney wrote: > hcoin wrote this message on Sun, Apr 20, 2014 at 12:25 -0500: >> On 04/20/2014 12:48 AM, Jamie Landeg-Jones wrote: >>> Bryan Drewery wrote: >>> >>>> On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: >>>>> As to the specific question, I don't think his ego would allow a bug >>>>> in openssh to persist, so even if it does, I'd suspect it's not too >>>>> serious (or it's non-trivial to exploit), and it's related to FreeBSD >>>>> produced 'glue'. >>>>> >>>>> This is total guesswork on my part, but I'd therefore assume he was >>>>> talkining about openssh in base, rarther than openssh-portable in >>>>> ports. >>>>> >>>> As the maintainer of the port I will say that your security decreases >>>> with each OPTION/patch you apply. I really would not be surprised if one >>>> of the optional patches available in the port had issues. >>> Ahhhh. good point. I forgot about third-party patches. >>> >>> Yeah, if he's not just blowing smoke, that would make the most sense. >>> >>> I don't reckon he'd leave an exploit open if it was purely related to >>> the unpatched source - even if there is some quirk which only makes >>> it only applicable to FreeBSD. >>> >>> Still, by not revealing it, he's only potentially hurting the users. >>> >>> I wonder how many blackhats are going to use this thread as a heads-up? >>> >>> Cheers, Jamie >>> _______________________________________________ >>> >> I wonder how many security holes, both those known and as yet unrevealed >> or unknown, would not be of any exploit value if in all security related >> libraries and applications the routine to free allocated memory >> allocation closest to the user app/library set the newly free memory to >> a known pattern or something from /dev/random before returning. And, >> similarly, a compiler option causing function returns using more than a >> few dozen bytes of stack space to erase the newly freed stack region >> just prior to resuming the caller. > there is an option to do this w/ malloc(3): > J Each byte of new memory allocated by malloc(), realloc(), or > reallocf() will be initialized to 0xa5. All memory returned by > free(), realloc(), or reallocf() will be initialized to 0x5a. > This is intended for debugging and will impact performance nega- > tively. > > This used to be eanbled by default on HEAD, but apparently isn't any > more... > There can be no doubt causing the free call furthest from the operating system to erase memory, (and just as importantly, a compiler option that erases the content of the stack space upon function return for all functions that used more than a couple dozen bytes of stack space in local variables) harms performance. It's also true doing both of these things would not fix the flaw that 'opened the window' onto these data. However it is true that doing so would make the exploit valueless as 'opening a window' onto erased data would reveal nothing and could erase trojan/virus 'hijack via code-injection then trampoline' opportunities. If the variable stack and free() functions erased data spaces, there would be no security value in having application edge malloc effectively be calloc. There may be marginal security value in having OS edge free() erase data before subsequent OS edge malloc of the same page to a process owed by a different userid. This entire discussion, (clear-on-free and clear-stack-on-function-return) are resource heavy ways of managing complexity. It is for the community to decide whether it is 'worth it' on a case by case basis given there is no way to prove a program 'correct' from a security perspective. Harry From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 02:10:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 092654DF for ; Mon, 21 Apr 2014 02:10:27 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 937F31C4C for ; Mon, 21 Apr 2014 02:10:25 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3L2ANaZ019893; Mon, 21 Apr 2014 03:10:23 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3L2AMwO019892; Mon, 21 Apr 2014 03:10:22 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404210210.s3L2AMwO019892@catnip.dyslexicfish.net> Date: Mon, 21 Apr 2014 03:10:22 +0100 To: na@rtfm.net, jamie@dyslexicfish.net Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Mon, 21 Apr 2014 03:10:23 +0100 (BST) Cc: hcoin@quietfountain.com, freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 02:10:27 -0000 Nathan Dorfman wrote: > free() doesn't usually "free memory back to the system." It just puts > it back onto a "free list" managed by libc, entirely within the > process's address space. > > "Use after free" is actually a rather common type of bug -- do a web > search on that term to see just how often it comes up. Ahhh, so (simplifying it here somewhat), malloc/free don't always affect the kernels own representation of the processes memory allocation, as part of libc behaves a bit like a cache - buffering and managing requests in userspace, so as to make things run more efficiently. Thanks for the reply - my question wasn't quite as stupid as I feared! Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 02:19:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A34088D1 for ; Mon, 21 Apr 2014 02:19:07 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3104D1D0A for ; Mon, 21 Apr 2014 02:19:06 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3L2J4X9020039; Mon, 21 Apr 2014 03:19:04 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3L2J4r3020038; Mon, 21 Apr 2014 03:19:04 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404210219.s3L2J4r3020038@catnip.dyslexicfish.net> Date: Mon, 21 Apr 2014 03:19:04 +0100 To: rwmaillists@googlemail.com, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <201404201831.s3KIVCSY054778@catnip.dyslexicfish.net> <20140420220037.076be9d0@gumby.homeunix.com> In-Reply-To: <20140420220037.076be9d0@gumby.homeunix.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Mon, 21 Apr 2014 03:19:05 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 02:19:07 -0000 RW wrote: > It can return the physical memory, but there are a couple of caveats. > Firstly, it can only return whole pages. Secondly, it's not returned > instantaneously to avoid the overhead of page-faults and zeroing pages > if that region is remalloced. It's left to the page-daemon to recover > the physical memory in its own time, and it remains readable by it's > previous process until it's reassigned. Again, thanks for clearing that up for me. I wasn't all that far off-base after all, but yours and Nathans replies make sense! So there is a real world use for calloc after all! (though only as a bug catching security measure - no sane program should ever read its memory it hasn't yet written to!) cheers, jamie From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 03:06:26 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C791FCCA for ; Mon, 21 Apr 2014 03:06:26 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7546312FD for ; Mon, 21 Apr 2014 03:06:25 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3L36JhB020866; Mon, 21 Apr 2014 04:06:19 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3L36JfU020865; Mon, 21 Apr 2014 04:06:19 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404210306.s3L36JfU020865@catnip.dyslexicfish.net> Date: Mon, 21 Apr 2014 04:06:19 +0100 To: hcoin@quietfountain.com, freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <20140421000122.GS43976@funkthat.com> <53546795.9050304@quietfountain.com> In-Reply-To: <53546795.9050304@quietfountain.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Mon, 21 Apr 2014 04:06:19 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 03:06:26 -0000 "hcoin" wrote: > local variables) harms performance. It's also true doing both of these > things would not fix the flaw that 'opened the window' onto these data. > However it is true that doing so would make the exploit valueless as > 'opening a window' onto erased data would reveal nothing and could erase > trojan/virus 'hijack via code-injection then trampoline' opportunities. In the heartbleed case, was the bug returning stale freed memory, though? Couldn't it just as easily have been that the over-read was returning any other memory that the process has had allocated for other variables - data that was still in use? > If the variable stack and free() functions erased data spaces, there > would be no security value in having application edge malloc effectively > be calloc. Yeah. I had wrongly assumed that this was a throwback to more innocent days, and that these days, malloced space was effectively cleared by every sane OS, but due to backwards compatibility, the spec only defines calloc as acually clearing data, so you should never assume malloced memory was cleared, even though effectively it is these days. But Nathan and RW helpfully showed me where my reasoning failed! > There may be marginal security value in having OS edge free() erase data > before subsequent OS edge malloc of the same page to a process owed by a > different userid. Now this I don't get. Marginal? Surely in this case, this is a MUST. Otherwise we'd continually be getting local users getting data they shouldn't.... Every machine would be a 'heartbleed' for local users, even when running bug free code! I'd even extend this policy to different processes - even with the same id, because, of course, many daemons spawn children that deal with different connections simultaneously. (But of course in this case any leak would be down to bad programming if data leaks were discovered to be exploitable.) But yeah, surely if the UID (or more accurately, the EUID) were different but the data wasn't erased by the system prior to malloc, a leak would be unpreventable (unless, of course, the careful programmer never frees data, until he/she has erased it themselves beforehand. And who does that? > This entire discussion, (clear-on-free and > clear-stack-on-function-return) are resource heavy ways of managing > complexity. It is for the community to decide whether it is 'worth it' > on a case by case basis given there is no way to prove a program > 'correct' from a security perspective. I agree. More generally, all exploit busting mechanisms add to complexity and resources, whether it's DNS randomizing outgoing udp ports, or stack protection/pro police/canaries etc. You have to make a judgement call based between the protection of your software against speed, throwing into the equation the competence of your programming team! cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 15:16:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68AB8C3A for ; Mon, 21 Apr 2014 15:16:10 +0000 (UTC) Received: from smtp10.server.rpi.edu (smtp10.server.rpi.edu [128.113.2.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0764511F5 for ; Mon, 21 Apr 2014 15:16:09 +0000 (UTC) Received: from smtp-auth1.server.rpi.edu (smtp-auth1.server.rpi.edu [128.113.2.231]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3LFDcC8001682; Mon, 21 Apr 2014 11:13:38 -0400 Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id 6AF6E5812E; Mon, 21 Apr 2014 11:13:38 -0400 (EDT) Received: from [172.16.61.1] (gilead.netel.rpi.edu [128.113.124.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth1.server.rpi.edu (Postfix) with ESMTPSA id 3C4FE58127; Mon, 21 Apr 2014 11:13:37 -0400 (EDT) From: "Garance A Drosehn" To: "Jamie Landeg-Jones" Subject: Re: De Raadt + FBSD + OpenSSH + hole? Date: Mon, 21 Apr 2014 11:13:24 -0400 Message-ID: <5C4F945A-E156-4AAB-8C59-1D9385BE467A@rpi.edu> In-Reply-To: <201404210306.s3L36JfU020865@catnip.dyslexicfish.net> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <20140421000122.GS43976@funkthat.com> <53546795.9050304@quietfountain.com> <201404210306.s3L36JfU020865@catnip.dyslexicfish.net> MIME-Version: 1.0 X-Mailer: MailMate (1.7.2r3905) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0002 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: -0.01 () [Hold at 15.10] T_RP_MATCHES_RCVD:-0.01 X-CanIt-Incident-Id: 03LQDdCoU X-CanIt-Geo: ip=128.113.124.121; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Cc: hcoin@quietfountain.com, freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:16:10 -0000 On 20 Apr 2014, at 23:06, Jamie Landeg-Jones wrote: > "hcoin" wrote: > >> local variables) harms performance. It's also true doing both of these >> things would not fix the flaw that 'opened the window' onto these data. >> However it is true that doing so would make the exploit valueless as >> 'opening a window' onto erased data would reveal nothing and could erase >> trojan/virus 'hijack via code-injection then trampoline' opportunities. > > In the heartbleed case, was the bug returning stale freed memory, though? > Couldn't it just as easily have been that the over-read was returning any > other memory that the process has had allocated for other variables - data > that was still in use? The heardbleed case is totally an error in openssl, because it does not really use the system malloc/free. It mallocs a huge chunk of memory from the system when it starts up, and then it has it's own routines which manages that memory. As far as the operating system is concerned, it can't touch any of that memory, even though openssl is using it over-and-over for whatever it needs memory for. Openssl did this, of course, for performance reasons. So in the case of openssl, the problem was that the code *never* returned memory, no matter how stale and unreferenced the data was. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 15:23:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C813F7D for ; Mon, 21 Apr 2014 15:23:31 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id 5173312D6 for ; Mon, 21 Apr 2014 15:23:30 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N4E003R902N4O70@st11p09mm-asmtp001.mac.com> for freebsd-security@freebsd.org; Mon, 21 Apr 2014 15:23:16 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Re: De Raadt + FBSD + OpenSSH + hole? From: Kimmo Paasiala In-reply-to: <201404210306.s3L36JfU020865@catnip.dyslexicfish.net> Date: Mon, 21 Apr 2014 18:23:07 +0300 Message-id: <89978872-0943-417C-9A96-9DB24E5D6CB8@icloud.com> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com> <20140421000122.GS43976@funkthat.com> <53546795.9050304@quietfountain.com> <201404210306.s3L36JfU020865@catnip.dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHhEKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCH2lsG0NcGXhzB xlmGx8YGW1vEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGx0QGx4aHxsRCl5ZF2FDXlI FEQpMRhdia2sRCkNaFxISBBsTHwQbGBIEGRkRCkRYFxgRCkRJFxsRCkJFF2Z9fxNNb1xgZRoSE QpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQpCQBduGE5 kHBhiR1hTcBEKcGcXYXlJfRtueXwTe0MRCnBoF2J9Yh8bRxleR3lvEQpwaBdgZxxTUElMQBpDR BEKcGgXb2lnRkNZeFJeS0MRCnBoF2JMbWlhb3JjYgFrEQpwaBdtWF4YRmJsZkZLRxEKcH8Xbm5 oGhMdQ2AfXW0RCnBfF2VzY01fW2BDaVMaEQpwaxdhGgF9W3B8fRltRxEKcEsXYmlyE1hdXGdtU 3MRCnBrF2QfTR4cGmljRVhEEQpwbBdtZ24FH2FOYRxbGxEKcEwXemVMfEdfX1wceHIR X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-21_02:2014-04-21,2014-04-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=10 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404210253 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:23:31 -0000 --Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21.4.2014, at 6.06, Jamie Landeg-Jones = wrote: > "hcoin" wrote: >=20 >> local variables) harms performance. It's also true doing both of = these=20 >> things would not fix the flaw that 'opened the window' onto these = data. =20 >> However it is true that doing so would make the exploit valueless as=20= >> 'opening a window' onto erased data would reveal nothing and could = erase=20 >> trojan/virus 'hijack via code-injection then trampoline' = opportunities. >=20 > In the heartbleed case, was the bug returning stale freed memory, = though? > Couldn't it just as easily have been that the over-read was returning = any > other memory that the process has had allocated for other variables - = data > that was still in use? No, the problem was another type of programming error that is endemic in = C programming. It=92s called failure to validate input parameters before = using the input parameters or derived values from the input parameters = as array indices.=20 https://en.wikipedia.org/wiki/Bounds_checking The bug allowed an attacker to request any number of bytes from memory = that followed the buffer that the client was usually allowed to access = (depending on how the index was interpreted it might have been possible = to request memory before the buffer as well). The part of memory that = followed the buffer very probably contained some very sensitive = information, possibly secret keys that were loaded in memory (memory = that was constantly in use and not free()=92d until the process = terminates) in unprotected form (plain text essentially) for fast access = during encryption and decryption. -Kimmo --Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTVTfeAAoJEFvLZC0FWRVpHfMIAKPW0sIvgfGv2BlTdyw5lADB MPWXB/P3E7HGfY5gKCrn7X2XOgdv6omg9WvZqS5WhRdFXM4MEAMYQBstgEP9mJgu N9RXCbhic08vQDWQdmGcGyh9tknPlitilYiRpMZ2yMCAbU6dan0GRP0fxYUeqaWn iK+j2f4gF8KJl0XPPCd3f3pC08LoNGCLV61yClJJ8R/fv5T6GX79oBQrwLslmzjR TB0i1DDLALuhXqAVxQtRDqcZHAJMha3Y1oxW/UQL79UfcKE9JDjvNrN7lhPotuCq UHWg0dhVa05ocFM0tDNNtpQ1R3ik26vCLA4T/Q9nlVERBAVGLCsm0iIWj3R9yms= =Lk0k -----END PGP SIGNATURE----- --Apple-Mail=_5ACB6A6C-91B4-4C5D-A5BA-DAE79AA198E4-- From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 18:06:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18EA642F for ; Mon, 21 Apr 2014 18:06:35 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D67DB1440 for ; Mon, 21 Apr 2014 18:06:34 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id s3LI6BGd011265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 21 Apr 2014 13:06:27 -0500 Received: from lefty.vicor.com (10.242.182.122) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 21 Apr 2014 13:06:22 -0500 Message-ID: <53555E1B.1060705@fisglobal.com> Date: Mon, 21 Apr 2014 11:06:19 -0700 From: "Robison, Dave" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <535326fa.ab7281.696ea278@edge> In-Reply-To: <535326fa.ab7281.696ea278@edge> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.242.182.122] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-21_03:2014-04-21,2014-04-21,1970-01-01 signatures=0 X-Mailman-Approved-At: Mon, 21 Apr 2014 18:12:33 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: david.robison@fisglobal.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:06:35 -0000 On 04/19/2014 18:46, Mikhail wrote: >> On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: >>> Matt Dawson wrote: >>> >>>> My first thought when I saw this was "ego over ethics," which says more >>>> about Theo than FreeBSD. >>> > > I believe that Theo just browbeat. Reasons? It was looooong ago, I think > very few still remember, but Theo definitely does: > > http://lists.freebsd.org/pipermail/freebsd-security/2005-March/002719.html > _______________________________________________ Theo has maliciously impacted the FreeBSD project at least twice that I can recall. Nobody should expect any less from him. -- Dave Robison Sales Solution Architect II FIS Banking Solutions 510/621-2089 (w) 530/518-5194 (c) 510/621-2020 (f) daver@vicor.com david.robison@fisglobal.com _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 20:48:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8C85629 for ; Mon, 21 Apr 2014 20:48:27 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 8C11D150D for ; Mon, 21 Apr 2014 20:48:27 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 852E13AE6E for ; Mon, 21 Apr 2014 13:39:17 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <53546795.9050304@quietfountain.com> Date: Mon, 21 Apr 2014 13:39:17 -0700 Message-ID: <97711.1398112757@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:48:27 -0000 In message <53546795.9050304@quietfountain.com>, "hcoin" wrote: >... It is for the community to decide whether it is 'worth it' >on a case by case basis given there is no way to prove a program >'correct' from a security perspective. I guess that I was sick that day in software school. Did I just hear you tell me that I can't prove the following program is "secure"? int main (void) { return 0; } From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 21:28:36 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0532E70F for ; Mon, 21 Apr 2014 21:28:36 +0000 (UTC) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:67c:24f8:1::25:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.cksoft.de", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AE7F418F0 for ; Mon, 21 Apr 2014 21:28:35 +0000 (UTC) Received: from m.cksoft.de (unknown [IPv6:2003:41:c010:8001::143:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id 542872EBC3E; Mon, 21 Apr 2014 23:28:32 +0200 (CEST) Received: from amavis.ahti.cksoft.de (unknown [IPv6:fdfe:5560:83f7:8001::143:2]) by m.cksoft.de (Postfix) with ESMTP id EAFFDED02C; Mon, 21 Apr 2014 23:28:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([IPv6:fdfe:5560:83f7:8001::143:1]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [fdfe:5560:83f7:8001::143:2]) (amavisd-new, port 10024) with ESMTP id ICH0H+vnwteJ; Mon, 21 Apr 2014 23:28:26 +0200 (CEST) Received: from pohjola.cksoft.de (unknown [IPv6:fdfe:5560:83f7:8001:9816:8c41:ca18:a0af]) by m.cksoft.de (Postfix) with ESMTP id 9B226ED024; Mon, 21 Apr 2014 23:28:26 +0200 (CEST) Received: by pohjola.cksoft.de (Postfix, from userid 1000) id 86B87D7903; Mon, 21 Apr 2014 23:28:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by pohjola.cksoft.de (Postfix) with ESMTP id 82C3ED7891; Mon, 21 Apr 2014 23:28:26 +0200 (CEST) Date: Mon, 21 Apr 2014 23:28:26 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@pohjola.cksoft.de To: "Ronald F. Guilmette" Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <97711.1398112757@server1.tristatelogic.com> Message-ID: References: <97711.1398112757@server1.tristatelogic.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Christian Kratzer List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:28:36 -0000 Hi, On Mon, 21 Apr 2014, Ronald F. Guilmette wrote: > > In message <53546795.9050304@quietfountain.com>, > "hcoin" wrote: > >> ... It is for the community to decide whether it is 'worth it' >> on a case by case basis given there is no way to prove a program >> 'correct' from a security perspective. > > I guess that I was sick that day in software school. > > Did I just hear you tell me that I can't prove the following program > is "secure"? > > > int > main (void) > { > return 0; > } in an ideal world you could propably. The difficulty ist that even above seemingly trival snippet of code is run after initialization of the c runtime library and some pre processing of argc, argv. It gets more complex with c++ contstructors run before main. If gets even more complex the more software components interact in wierd and wonderfull ways. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 21:36:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2899DBAC for ; Mon, 21 Apr 2014 21:36:20 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 01CE519DA for ; Mon, 21 Apr 2014 21:36:19 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 2E3C8B826A for ; Mon, 21 Apr 2014 16:36:13 -0500 (CDT) To: freebsd-security@freebsd.org Date: Mon, 21 Apr 2014 16:35:26 -0500 Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <53546795.9050304@quietfountain.com> <97711.1398112757@server1.tristatelogic.com> Message-ID: <53558F1E.1010308@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Mon, 21 Apr 2014 16:35:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:36:20 -0000 On 04/21/2014 03:39 PM, Ronald F. Guilmette wrote: > > In message <53546795.9050304@quietfountain.com>, > "hcoin" wrote: > >> ... It is for the community to decide whether it is 'worth it' >> on a case by case basis given there is no way to prove a program >> 'correct' from a security perspective. > I guess that I was sick that day in software school. > > Did I just hear you tell me that I can't prove the following program > is "secure"? > > > int > main (void) > { > return 0; > } > _______________________________________________ > Good one. There were efforts, some years ago, to prove 'software correctness' with a similar understanding of 'correct' as mathematicians have when regarding a theorem as 'true'. The alligators in the complexity swamp ate those efforts before breakfast. First you have to prove the microcode in the processors correct, then you have to prove the compilers 'correctly' translate your favorite language into machine code, then you have to prove the OS is both 'correct' and doesn't 'break' the correctness in the running application. To manage that you have to extend logical expression to manage asynchronous events, no small thing. Our logical tools are pretty bound to linear 'if then' bricks-upon-other-bricks concepts. And then, after all that is proven, the question of whether the program you wrote is 'correct' can be engaged. The new-ish language Haskell takes an 'outside the box' approach to the question, by shifting what a 'program' is to be closer to 'what should the result be' than 'what step should happen next'. There's more hope such a language could specify provably correct programs than C-ish or object-oriented cousins, but that still leaves the whole machine-language domain unaddressed. Imagine the size of a number made up of every settable option bit in the processor and support chips, and add more for each occasion the order in which those bits are set or reset matters. Each combination of those bits calls for the correctness proof to be rechecked. Even in that little program you wrote, is it a security hole if, left on the stack upon return, the perhaps unused arguments remain? Just because you're paranoid doesn't mean they really aren't after you. From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 21:49:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBDC319C for ; Mon, 21 Apr 2014 21:49:52 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 9C1B91AF7 for ; Mon, 21 Apr 2014 21:49:52 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 61B4B3AE6E for ; Mon, 21 Apr 2014 14:49:45 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: Date: Mon, 21 Apr 2014 14:49:45 -0700 Message-ID: <98152.1398116985@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:49:52 -0000 In message , Christian Kratzer wrote: >On Mon, 21 Apr 2014, Ronald F. Guilmette wrote: >> >> In message <53546795.9050304@quietfountain.com>, >> "hcoin" wrote: >> >>> ... It is for the community to decide whether it is 'worth it' >>> on a case by case basis given there is no way to prove a program >>> 'correct' from a security perspective. >> >> I guess that I was sick that day in software school. >> >> Did I just hear you tell me that I can't prove the following program >> is "secure"? >> >> >> int >> main (void) >> { >> return 0; >> } > >in an ideal world you could propably. The difficulty ist that even >above seemingly trival snippet of code is run after initialization of >the c runtime library and some pre processing of argc, argv. > >It gets more complex with c++ contstructors run before main. > >If gets even more complex the more software components interact in >wierd and wonderfull ways. At the risk of stating the obvious... Complexity != Impossibility I think that we need better tools. But then again, I have always thought that, and undoubtedly always will. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 01:38:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E54D662D for ; Tue, 22 Apr 2014 01:38:51 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id C06061082 for ; Tue, 22 Apr 2014 01:38:51 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id CED9A3AE0E for ; Mon, 21 Apr 2014 18:38:45 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <53558F1E.1010308@quietfountain.com> Date: Mon, 21 Apr 2014 18:38:45 -0700 Message-ID: <99496.1398130725@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 01:38:52 -0000 In message <53558F1E.1010308@quietfountain.com>, "hcoin" wrote: > >On 04/21/2014 03:39 PM, Ronald F. Guilmette wrote: >> >> In message <53546795.9050304@quietfountain.com>, >> "hcoin" wrote: >> >>> ... It is for the community to decide whether it is 'worth it' >>> on a case by case basis given there is no way to prove a program >>> 'correct' from a security perspective. >> I guess that I was sick that day in software school. >> >> Did I just hear you tell me that I can't prove the following program >> is "secure"? >> >> >> int >> main (void) >> { >> return 0; >> } >> _______________________________________________ >> >Good one. Thank you. I wish that I could say that I had written that program all by myself, but... >There were efforts, some years ago, to prove 'software >correctness' with a similar understanding of 'correct' as mathematicians >have when regarding a theorem as 'true'. The alligators in the >complexity swamp ate those efforts before breakfast. Well, um, yes. >First you have to >prove the microcode in the processors correct, then you have to prove >the compilers 'correctly' translate your favorite language into machine >code, then you have to prove the OS is both 'correct' and doesn't >'break' the correctness in the running application. Sure, if one wanted to be really anal about it. But the semantics of a given C program are specified by the ANSI/ISO C standard. >The new-ish language Haskell takes an 'outside the box' approach to the ... Funny you should mention that. Just after I wrote the message to which you responded, it occured to me that I had not read anything at all about denotational senatics for about the last 20 years (and even the stuff that I did read, way back then, was probably over my head). So just today, I went and looked at the entry for "denotational semantics" in Wikipedia. That Wikipedia entry did mention one language in particular... Haskell. I guess that I'll be looking into that. (I currently know zip about Haskell, but am always eager to learn new things.) >Even in that little program you wrote, is it a security hole if, left on >the stack upon return, the perhaps unused arguments remain? I suspect that you and I have different definitions of the term "security hole". >Just because you're paranoid doesn't mean they really aren't after you. On this, at least, we agree completely. One last thought... In the aftermath of this whole OpenSSL brouhaha... which none other than Bruce Schneier publically pronounced to be a 12, on a scale from 1 to 10, in terms of awfulness... I do wonder if anyone has taken the time or effort to run the OpenSSL sources through any kind of analyzer to try to obtain some of the standard sorts of software science metrics on it. I suspect that a whole lot of folks might be either (a) red faced or else (b) deeply concerned if a scientifically derived estimate of the number of *remaining* (and as-yet undiscovered) bugs in that package were published. Regards, rfg P.S. I do think that Schneier has seriously overstated the criticality of Heartbleed. So far, I am not aware of -any- banks or other financial institutions which have been confirmed to have been affected, and by and large, life goes on and the world has not ended. From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 02:55:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6A671B9 for ; Tue, 22 Apr 2014 02:55:28 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 72F9F16C1 for ; Tue, 22 Apr 2014 02:55:28 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 4783EB822E for ; Mon, 21 Apr 2014 21:55:27 -0500 (CDT) To: freebsd-security@freebsd.org Date: Mon, 21 Apr 2014 21:54:47 -0500 Subject: Re: De Raadt + FBSD + OpenSSH + hole? References: <53558F1E.1010308@quietfountain.com> <99496.1398130725@server1.tristatelogic.com> Message-ID: <5355D9F7.2010208@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Mon, 21 Apr 2014 21:54:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 02:55:28 -0000 On 04/21/2014 08:38 PM, Ronald F. Guilmette wrote: > I suspect that a whole lot of folks might be either (a) red faced or else > (b) deeply concerned if a scientifically derived estimate of the number of > *remaining* (and as-yet undiscovered) bugs in that package were published. Yes indeed. I think your comment 'as-yet undiscovered' is of an aspirational character. Imagine if your job, every day, is to take all the same talent and training involved in creating all this to find exploits. A person whose mind isn't absorbed with knowing everything about one area enough to move it's art ahead, but enough about all the areas with emphasis on their interfaces and edge conditions. For example, just the right compiler quirk or processor microcode quirk with just the right OS quirk in just the right library routine, or a quirk in the firmware of any device able to generate memory read bus cycles (smart network interface chips and hardware RAID cards come to mind, and, oh my -- graphics processors.... Every time device memory is mapped into user space ... worry.). The folks that do that are good at not sharing, and using them sparingly. It's the same problem faced by any defender: the defenders have to be entirely right all the time, while the exploit finder only has to be right once. Only rigor approaching the level of math theorems applied to software security (a trace easier than 'software correctness' I expect) can offer trustworthy assurances about blocking software-only exploits. The semantics of all our current popular languages, for reasons to do with making early 8 bit processors deliver value, are silent about what happens to data that 'goes out of scope' or 'is freed', most of the time the OS just marks the memory page 'unused' without knowing whether it's of importance to wipe. A few little-used languages had 'garbage collection routines' that could have been good at wiping. But mostly our languages struggled to do the right thing with data people cared about to bother much with what happened to it when 'done'. There was no performance that could be spared to "protect against data dumpster-divers". And wow look at what happened to programming discipline, particularly application programming, when throwing another gigabyte of ram or another processor into a machine cost less than tuning a routine. Most of the time it's not worth the processor time to wipe old data as the pages are bits from an old movie data anyhow. But most of the time isn't all of the time. Perhaps we should consider adding a variable attribute like 'secure' much like 'volatile' was added, to cause the compiler to generate code wiping such variables when they go out of scope, force initialize them to a known bit pattern, and only allocate those variables to pages that are wiped on free and that can't be referenced by pointer or other means except by a function or procedure that also has a 'secure' attribute. I'll go back to lurking now! Thanks for all your efforts. H From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 12:23:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8730570C for ; Tue, 22 Apr 2014 12:23:44 +0000 (UTC) Received: from nm31-vm4.bullet.mail.ir2.yahoo.com (nm31-vm4.bullet.mail.ir2.yahoo.com [212.82.97.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 970101FF4 for ; Tue, 22 Apr 2014 12:23:43 +0000 (UTC) Received: from [212.82.98.53] by nm31.bullet.mail.ir2.yahoo.com with NNFMP; 22 Apr 2014 12:23:35 -0000 Received: from [212.82.98.94] by tm6.bullet.mail.ir2.yahoo.com with NNFMP; 22 Apr 2014 12:23:35 -0000 Received: from [127.0.0.1] by omp1031.mail.ir2.yahoo.com with NNFMP; 22 Apr 2014 12:23:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 123128.67858.bm@omp1031.mail.ir2.yahoo.com Received: (qmail 12721 invoked by uid 60001); 22 Apr 2014 12:16:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1398169015; bh=Uw0yKXi2ug7BC/je8x/56y085IitFMWbylAVnGd8mKU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=I1cTp6RKdgQgL9mPeqJGERl08m00EJ1k0Q1fLJfnDi3HkPNF7lKZQ61nwN7gPjSLythDzKjQTQGC4uTm8XohJL2yPIGTl/OjdXumkrcBA353MOaV3VZHOxOmtyFzgUbnFOo/nkka/+XjStvCQjx11FrOQ6dsR5OvX+WYyNrzEGE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qeJ6ohkfUmEjrtZnsJHZHiHIMBP5Rc1YC1cjKh0Khxbrfpc7iHbgZDjafAbfrVR9PNEgfsaWPnXKA8diETXADhxGFjVrkrykHSb9Rvue0ilL/0onu5uizr6s8QBN60TotLankOkJnNTRk26VsvGYmBMxJqepFjF+XnsUDzjUH1g=; X-YMail-OSG: XCZaFwAVM1mKuOhQMtQqxaClJGukXS.fjShxYUBn9ixZyzg 2c6REAgIZ.pLDCZSs6GnCPtD9.6FZ1LgSzudMUYOfFHNH5bYGt2AncYOTd7U Rh.7DJHSwOddsioyFS1oYENDeVZxW4d5fK9suA4ZAsHcSDDcDDHC09yDTvca LGolhX4.7yyRkKAW9LcxATcrDbBQ_KiqbR6iGFddpQWbvn3tTui_M12mU6U0 _iwvEXjpnnLZuQw1geLre_CQnMV9JO9O45VpYRRLeEjyUzkUpJEi_vz2Te3V odqBcOcE2tHgafDdSzNuqhdVJ0sdsnsS7HW6MY3rYIDPkPiqOI8V.YZmFMMt LLtEhdRP.gp9MyjTYY6phRQ7bHhFaqYuuPoMrIzzcFHhvVJJbOfFd8rXWO87 nojNj3wyFmIGipQ5d9KbgCU24Ieo8Rh4Y9X7XbW1iVTfp9EZeejeCeej2Qfb v9dp2CpLCCPWWDNJj.jvqJKbDHB8RRSNCfNQ0z0iqqalgeUPPliFWWUPz0Gb eae3QtjX2Lofdx9ThBqzxHe7_A7k_DdreOl4P1FipvFJO.qUPl2t2fp2AJbe httnK_2RRZRwEujE4c2Pda4_RleQhaXRsFqq0BPbU2LKT3HljGZfk8VyI98u 9nxq78yxQF_bmRtWA8RHKKi4ZeRAichO1Mw-- Received: from [145.64.134.242] by web28902.mail.ir2.yahoo.com via HTTP; Tue, 22 Apr 2014 13:16:54 BST X-Rocket-MIMEInfo: 002.001, V2hhdCBhIGxvYWQgb2Ygbm9uc2Vuc2UgaGVyZTogbm8sIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGZ1cnRoZXIgZXh0ZW5kIHRoZSBib3VuZGFyaWVzIG9mIG1hdGhlbWF0aWNhbCBsb2dpYyBpbiBvcmRlciB0byBhdm9pZCBzdWNoIGJ1Z3MsIGFuZCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBub3cgY2hhbmdlIG91ciBwcm9ncmFtbWluZyBoYWJpdHMgYW5kIHVzZSB0aGUgbWFnaWMgcG93ZXIgb2YgSGFza2VsbCAtIEkgYWN0dWFsbHkgdGhpbmssIHNvbWVib2R5IHNob3VsZCByZWFkIHRoZSBjb2RlIHRoYXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.185.657 References: Message-ID: <1398169014.53411.YahooMailNeo@web28902.mail.ir2.yahoo.com> Date: Tue, 22 Apr 2014 13:16:54 +0100 (BST) From: Alfred Hegemeier Subject: Re: freebsd-security Digest, Vol 484, Issue 2 To: "freebsd-security@freebsd.org" In-Reply-To: MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 22 Apr 2014 12:34:52 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Alfred Hegemeier List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 12:23:44 -0000 What a load of nonsense here: no, I don't think we should further extend th= e boundaries of mathematical logic in order to avoid such bugs, and I don't= think we should now change our programming habits and use the magic power = of Haskell - I actually think, somebody should read the code that others pr= ogram..especially if it is security related code, shouldn't anybody=A0 ?! = =0A=0AThis is a bug which children get taught to avoid when programming and= how to avoid, namely check the input, don't rely on the user entering a nu= mber between 1 and 10 even if you tell them, but check it, omg.=0A=0AOMG=0A= =0A=0A=0AOn Tuesday, 22 April 2014, 14:00, "freebsd-security-request@freebs= d.org" wrote:=0A =0ASend freebsd-sec= urity mailing list submissions to=0A=A0=A0=A0 freebsd-security@freebsd.org= =0A=0ATo subscribe or unsubscribe via the World Wide Web, visit=0A=A0=A0=A0= http://lists.freebsd.org/mailman/listinfo/freebsd-security=0Aor, via email= , send a message with subject or body 'help' to=0A=A0=A0=A0 freebsd-securit= y-request@freebsd.org=0A=0AYou can reach the person managing the list at=0A= =A0=A0=A0 freebsd-security-owner@freebsd.org=0A=0AWhen replying, please edi= t your Subject line so it is more specific=0Athan "Re: Contents of freebsd-= security digest..."=0A=0A=0AToday's Topics:=0A=0A=A0 1. Re: De Raadt + FBS= D + OpenSSH + hole? (Garance A Drosehn)=0A=A0 2. Re: De Raadt + FBSD + Ope= nSSH + hole? (Kimmo Paasiala)=0A=A0 3. Re: De Raadt + FBSD + OpenSSH + hol= e? (Robison, Dave)=0A=A0 4. Re: De Raadt + FBSD + OpenSSH + hole? (Ronald = F. Guilmette)=0A=A0 5. Re: De Raadt + FBSD + OpenSSH + hole? (Christian Kr= atzer)=0A=A0 6. Re: De Raadt + FBSD + OpenSSH + hole? (hcoin)=0A=A0 7. Re= : De Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette)=0A=A0 8. Re: De = Raadt + FBSD + OpenSSH + hole? (Ronald F. Guilmette)=0A=A0 9. Re: De Raadt= + FBSD + OpenSSH + hole? (hcoin)=0A=0A=0A---------------------------------= -------------------------------------=0A=0AMessage: 1=0ADate: Mon, 21 Apr 2= 014 11:13:24 -0400=0AFrom: "Garance A Drosehn" =0ATo: "Jami= e Landeg-Jones" =0ACc: hcoin@quietfountain.com, fre= ebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?= =0AMessage-ID: <5C4F945A-E156-4AAB-8C59-1D9385BE467A@rpi.edu>=0A=0A=0AOn 20= Apr 2014, at 23:06, Jamie Landeg-Jones wrote:=0A=0A> "hcoin" wrote:=0A>=0A>> local variables) harms performance.=A0 It's a= lso true doing both of these=0A>> things would not fix the flaw that 'opene= d the window' onto these data.=0A>> However it is true that doing so would = make the exploit valueless as=0A>> 'opening a window' onto erased data woul= d reveal nothing and could erase=0A>> trojan/virus 'hijack via code-injecti= on then trampoline' opportunities.=0A>=0A> In the heartbleed case, was the = bug returning stale freed memory, though?=0A> Couldn't it just as easily ha= ve been that the over-read was returning any=0A> other memory that the proc= ess has had allocated for other variables - data=0A> that was still in use?= =0A=0AThe heardbleed case is totally an error in openssl, because it does n= ot=0Areally use the system malloc/free.=A0 It mallocs a huge chunk of memor= y from=0Athe system when it starts up, and then it has it's own routines wh= ich manages=0Athat memory.=A0 As far as the operating system is concerned, = it can't touch any=0Aof that memory, even though openssl is using it over-a= nd-over for whatever it=0Aneeds memory for.=A0 Openssl did this, of course,= for performance reasons.=0A=0ASo in the case of openssl, the problem was t= hat the code *never* returned=0Amemory, no matter how stale and unreference= d the data was.=0A=0A-- =0AGarance Alistair Drosehn=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =3D=A0 =A0 drosih@rpi.edu=0ASenior Systems Programmer=A0 =A0 =A0 = =A0 =A0 =A0 =A0 or=A0 gad@FreeBSD.org=0ARensselaer Polytechnic Institute;= =A0 =A0 =A0 =A0 =A0 =A0 Troy, NY;=A0 USA=0A=0A=0A-------------------------= -----=0A=0AMessage: 2=0ADate: Mon, 21 Apr 2014 18:23:07 +0300=0AFrom: Kimmo= Paasiala =0ATo: Jamie Landeg-Jones =0ACc: freebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + = OpenSSH + hole?=0AMessage-ID: <89978872-0943-417C-9A96-9DB24E5D6CB8@icloud.= com>=0AContent-Type: text/plain; charset=3D"windows-1252"=0A=0A=0AOn 21.4.2= 014, at 6.06, Jamie Landeg-Jones wrote:=0A=0A> "hc= oin" wrote:=0A> =0A>> local variables) harms perf= ormance.=A0 It's also true doing both of these =0A>> things would not fix = the flaw that 'opened the window' onto these data.=A0 =0A>> However it is t= rue that doing so would make the exploit valueless as =0A>> 'opening a wind= ow' onto erased data would reveal nothing and could erase =0A>> trojan/viru= s 'hijack via code-injection then trampoline' opportunities.=0A> =0A> In th= e heartbleed case, was the bug returning stale freed memory, though?=0A> Co= uldn't it just as easily have been that the over-read was returning any=0A>= other memory that the process has had allocated for other variables - data= =0A> that was still in use?=0A=0ANo, the problem was another type of progra= mming error that is endemic in C programming. It?s called failure to valida= te input parameters before using the input parameters or derived values fro= m the input parameters as array indices. =0A=0Ahttps://en.wikipedia.org/wik= i/Bounds_checking=0A=0AThe bug allowed an attacker to request any number of= bytes from memory that followed the buffer that the client was usually all= owed to access (depending on how the index was interpreted it might have be= en possible to request memory before the buffer as well). The part of memor= y that followed the buffer very probably contained some very sensitive info= rmation, possibly secret keys that were loaded in memory (memory that was c= onstantly in use and not free()?d until the process terminates) in unprotec= ted form (plain text essentially) for fast access during encryption and dec= ryption.=0A=0A-Kimmo=0A=0A-------------- next part --------------=0AA non-t= ext attachment was scrubbed...=0AName: signature.asc=0AType: application/pg= p-signature=0ASize: 496 bytes=0ADesc: Message signed with OpenPGP using GPG= Mail=0AURL: =0A=0A-----------------------------= -=0A=0AMessage: 3=0ADate: Mon, 21 Apr 2014 11:06:19 -0700=0AFrom: "Robison,= Dave" =0ATo: = =0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <53555E1B.1= 060705@fisglobal.com>=0AContent-Type: text/plain; charset=3D"ISO-8859-1"=0A= =0AOn 04/19/2014 18:46, Mikhail wrote:=0A>> On 4/14/2014 7:32 AM, Jamie Lan= deg-Jones wrote:=0A>>> Matt Dawson wrote:=0A>>>=0A>>>= > My first thought when I saw this was "ego over ethics," which says more= =0A>>>> about Theo than FreeBSD.=0A>>>=0A> =0A> I believe that Theo just br= owbeat. Reasons? It was looooong ago, I think=0A> very few still remember, = but Theo definitely does:=0A> =0A> http://lists.freebsd.org/pipermail/freeb= sd-security/2005-March/002719.html=0A> ____________________________________= ___________=0A=0A=0ATheo has maliciously impacted the FreeBSD project at le= ast twice that I=0Acan recall.=0A=0ANobody should expect any less from him.= =0A=0A=0A=0A=0A-- =0ADave Robison=0ASales Solution Architect II=0AFIS Banki= ng Solutions=0A510/621-2089 (w)=0A530/518-5194 (c)=0A510/621-2020 (f)=0Adav= er@vicor.com=0Adavid.robison@fisglobal.com=0A=0A_____________=0AThe informa= tion contained in this message is proprietary and/or confidential. If you a= re not the intended recipient, please: (i) delete the message and all copie= s; (ii) do not disclose, distribute or use the message in any manner; and (= iii) notify the sender immediately. In addition, please be aware that any m= essage addressed to our domain is subject to archiving and review by person= s other than the intended recipient. Thank you.=0A=0A=0A-------------------= -----------=0A=0AMessage: 4=0ADate: Mon, 21 Apr 2014 13:39:17 -0700=0AFrom:= "Ronald F. Guilmette" =0ATo: freebsd-security@freeb= sd.org=0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <9771= 1.1398112757@server1.tristatelogic.com>=0A=0A=0AIn message <53546795.905030= 4@quietfountain.com>, =0A"hcoin" wrote:=0A=0A>...= It is for the community to decide whether it is 'worth it' =0A>on a case b= y case basis given there is no way to prove a program =0A>'correct' from a = security perspective.=0A=0AI guess that I was sick that day in software sch= ool.=0A=0ADid I just hear you tell me that I can't prove the following prog= ram=0Ais "secure"?=0A=0A=0Aint=0Amain (void)=0A{=0A=A0 return 0;=0A}=0A=0A= =0A------------------------------=0A=0AMessage: 5=0ADate: Mon, 21 Apr 2014 = 23:28:26 +0200 (CEST)=0AFrom: Christian Kratzer =0ATo: = "Ronald F. Guilmette" =0ACc: freebsd-security@freebs= d.org=0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: =0AContent-Type: TEXT/PLAI= N; charset=3DUS-ASCII; format=3Dflowed=0A=0AHi,=0A=0AOn Mon, 21 Apr 2014, R= onald F. Guilmette wrote:=0A>=0A> In message <53546795.9050304@quietfountai= n.com>,=0A> "hcoin" wrote:=0A>=0A>> ... It is for= the community to decide whether it is 'worth it'=0A>> on a case by case ba= sis given there is no way to prove a program=0A>> 'correct' from a security= perspective.=0A>=0A> I guess that I was sick that day in software school.= =0A>=0A> Did I just hear you tell me that I can't prove the following progr= am=0A> is "secure"?=0A>=0A>=0A> int=0A> main (void)=0A> {=0A>=A0 return 0;= =0A> }=0A=0Ain an ideal world you could propably.=A0 The difficulty ist tha= t even=0Aabove seemingly trival snippet of code is run after initialization= of=0Athe c runtime library and some pre processing of argc, argv.=0A=0AIt = gets more complex with c++ contstructors run before main.=0A=0AIf gets even= more complex the more software components interact in=0Awierd and wonderfu= ll ways.=0A=0AGreetings=0AChristian=0A=0A-- =0AChristian Kratzer=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 CK Software GmbH=0AEmail:=A0 ck@cksoft.de=A0 =A0 = =A0 =A0 =A0 =A0 =A0 Wildberger Weg 24/2=0APhone:=A0 +49 7032 893 997 - 0= =A0 =A0 =A0 D-71126 Gaeufelden=0AFax:=A0 =A0 +49 7032 893 997 - 9=A0 =A0 = =A0 HRB 245288, Amtsgericht Stuttgart=0AMobile:=A0 +49 171 1947 843=A0 =A0= =A0 =A0 =A0 Geschaeftsfuehrer: Christian Kratzer=0AWeb:=A0 =A0 http://www= .cksoft.de/=0A=0A=0A------------------------------=0A=0AMessage: 6=0ADate: = Mon, 21 Apr 2014 16:35:26 -0500=0AFrom: "hcoin" = =0ATo: freebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + OpenSS= H + hole?=0AMessage-ID: <53558F1E.1010308@quietfountain.com>=0AContent-Type= : text/plain; charset=3DISO-8859-1; format=3Dflowed=0A=0A=0AOn 04/21/2014 0= 3:39 PM, Ronald F. Guilmette wrote:=0A>=0A> In message <53546795.9050304@qu= ietfountain.com>,=0A> "hcoin" wrote:=0A>=0A>> ...= It is for the community to decide whether it is 'worth it'=0A>> on a case = by case basis given there is no way to prove a program=0A>> 'correct' from = a security perspective.=0A> I guess that I was sick that day in software sc= hool.=0A>=0A> Did I just hear you tell me that I can't prove the following = program=0A> is "secure"?=0A>=0A>=0A> int=0A> main (void)=0A> {=0A>=A0 =A0 r= eturn 0;=0A> }=0A> _______________________________________________=0A>=0AGo= od one.=A0 There were efforts, some years ago, to prove 'software =0Acorrec= tness' with a similar understanding of 'correct' as mathematicians =0Ahave = when regarding a theorem as 'true'.=A0 The alligators in the =0Acomplexity= swamp ate those efforts before breakfast.=A0 First you have to =0Aprove th= e microcode in the processors correct, then you have to prove =0Athe compil= ers 'correctly' translate your favorite language into machine =0Acode, then= you have to prove the OS is both 'correct' and doesn't =0A'break' the corr= ectness in the running application.=A0 To manage that you =0Ahave to extend= logical expression to manage asynchronous events, no =0Asmall thing.=A0 Ou= r logical tools are pretty bound to linear 'if then' =0Abricks-upon-other-b= ricks concepts.=0A=0AAnd then, after all that is proven, the question of wh= ether the program =0Ayou wrote is 'correct' can be engaged.=0A=0AThe new-is= h language Haskell takes an 'outside the box' approach to the =0Aquestion, = by shifting what a 'program' is to be closer to 'what should =0Athe result = be' than 'what step should happen next'.=A0 There's more hope =0Asuch a lan= guage could specify provably correct programs than C-ish or =0Aobject-orien= ted cousins, but that still leaves the whole =0Amachine-language domain una= ddressed.=0A=0AImagine the size of a number made up of every settable optio= n bit in the =0Aprocessor and support chips, and add more for each occasion= the order in =0Awhich those bits are set or reset matters.=A0 Each combina= tion of those =0Abits calls for the correctness proof to be rechecked.=0A= =0AEven in that little program you wrote, is it a security hole if, left on= =0Athe stack upon return, the perhaps unused arguments remain? Just becaus= e =0Ayou're paranoid doesn't mean they really aren't after you.=0A=0A=0A=0A= =0A=0A=0A------------------------------=0A=0AMessage: 7=0ADate: Mon, 21 Apr= 2014 14:49:45 -0700=0AFrom: "Ronald F. Guilmette" = =0ATo: freebsd-security@freebsd.org=0ASubject: Re: De Raadt + FBSD + OpenSS= H + hole?=0AMessage-ID: <98152.1398116985@server1.tristatelogic.com>=0A=0A= =0AIn message , =0AC= hristian Kratzer wrote:=0A=0A>On Mon, 21 Apr 2014, Ron= ald F. Guilmette wrote:=0A>>=0A>> In message <53546795.9050304@quietfountai= n.com>,=0A>> "hcoin" wrote:=0A>>=0A>>> ... It is = for the community to decide whether it is 'worth it'=0A>>> on a case by cas= e basis given there is no way to prove a program=0A>>> 'correct' from a sec= urity perspective.=0A>>=0A>> I guess that I was sick that day in software s= chool.=0A>>=0A>> Did I just hear you tell me that I can't prove the followi= ng program=0A>> is "secure"?=0A>>=0A>>=0A>> int=0A>> main (void)=0A>> {=0A>= >=A0 return 0;=0A>> }=0A>=0A>in an ideal world you could propably.=A0 The d= ifficulty ist that even=0A>above seemingly trival snippet of code is run af= ter initialization of=0A>the c runtime library and some pre processing of a= rgc, argv.=0A>=0A>It gets more complex with c++ contstructors run before ma= in.=0A>=0A>If gets even more complex the more software components interact = in=0A>wierd and wonderfull ways.=0A=0A=0AAt the risk of stating the obvious= ...=0A=0A=A0 =A0 Complexity !=3D Impossibility=0A=0AI think that we need be= tter tools.=0A=0ABut then again, I have always thought that, and undoubtedl= y always will.=0A=0A=0ARegards,=0Arfg=0A=0A=0A-----------------------------= -=0A=0AMessage: 8=0ADate: Mon, 21 Apr 2014 18:38:45 -0700=0AFrom: "Ronald F= . Guilmette" =0ATo: freebsd-security@freebsd.org=0AS= ubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <99496.13981307= 25@server1.tristatelogic.com>=0A=0A=0AIn message <53558F1E.1010308@quietfou= ntain.com>, =0A"hcoin" wrote:=0A=0A>=0A>On 04/21/= 2014 03:39 PM, Ronald F. Guilmette wrote:=0A>>=0A>> In message <53546795.90= 50304@quietfountain.com>,=0A>> "hcoin" wrote:=0A>= >=0A>>> ... It is for the community to decide whether it is 'worth it'=0A>>= > on a case by case basis given there is no way to prove a program=0A>>> 'c= orrect' from a security perspective.=0A>> I guess that I was sick that day = in software school.=0A>>=0A>> Did I just hear you tell me that I can't prov= e the following program=0A>> is "secure"?=0A>>=0A>>=0A>> int=0A>> main (voi= d)=0A>> {=0A>>=A0 =A0 return 0;=0A>> }=0A>> _______________________________= ________________=0A>>=0A>Good one.=0A=0AThank you.=A0 I wish that I could s= ay that I had written that program all=0Aby myself, but...=0A=0A>There were= efforts, some years ago, to prove 'software =0A>correctness' with a simila= r understanding of 'correct' as mathematicians =0A>have when regarding a th= eorem as 'true'.=A0 The alligators in the =0A>complexity swamp ate those e= fforts before breakfast.=0A=0AWell, um, yes.=0A=0A>First you have to =0A>pr= ove the microcode in the processors correct, then you have to prove =0A>the= compilers 'correctly' translate your favorite language into machine =0A>co= de, then you have to prove the OS is both 'correct' and doesn't =0A>'break'= the correctness in the running application.=0A=0ASure, if one wanted to be= really anal about it.=A0 But the semantics of a=0Agiven C program are spec= ified by the ANSI/ISO C standard.=0A=0A>The new-ish language Haskell takes = an 'outside the box' approach to the ...=0A=0AFunny you should mention that= .=0A=0AJust after I wrote the message to which you responded, it occured to= me=0Athat I had not read anything at all about denotational senatics for a= bout=0Athe last 20 years (and even the stuff that I did read, way back then= , was=0Aprobably over my head).=A0 So just today, I went and looked at the = entry for=0A"denotational semantics" in Wikipedia.=A0 That Wikipedia entry = did mention=0Aone language in particular... Haskell.=0A=0AI guess that I'll= be looking into that.=A0 (I currently know zip about Haskell,=0Abut am alw= ays eager to learn new things.)=0A=0A>Even in that little program you wrote= , is it a security hole if, left on =0A>the stack upon return, the perhaps = unused arguments remain?=0A=0AI suspect that you and I have different defin= itions of the term "security=0Ahole".=0A=0A>Just because you're paranoid do= esn't mean they really aren't after you.=0A=0AOn this, at least, we agree c= ompletely.=0A=0AOne last thought...=0A=0AIn the aftermath of this whole Ope= nSSL brouhaha... which none other than=0ABruce Schneier publically pronounc= ed to be a 12, on a scale from 1 to 10,=0Ain terms of awfulness... I do won= der if anyone has taken the time or effort=0Ato run the OpenSSL sources thr= ough any kind of analyzer to try to obtain=0Asome of the standard sorts of = software science metrics on it.=0A=0AI suspect that a whole lot of folks mi= ght be either (a) red faced or else=0A(b) deeply concerned if a scientifica= lly derived estimate of the number of=0A*remaining* (and as-yet undiscovere= d) bugs in that package were published.=0A=0A=0ARegards,=0Arfg=0A=0A=0AP.S.= =A0 I do think that Schneier has seriously overstated the criticality of = =0AHeartbleed.=A0 So far, I am not aware of -any- banks or other financial= =0Ainstitutions which have been confirmed to have been affected, and by and= =0Alarge, life goes on and the world has not ended.=0A=0A=0A---------------= ---------------=0A=0AMessage: 9=0ADate: Mon, 21 Apr 2014 21:54:47 -0500=0AF= rom: "hcoin" =0ATo: freebsd-security@freebsd.org= =0ASubject: Re: De Raadt + FBSD + OpenSSH + hole?=0AMessage-ID: <5355D9F7.2= 010208@quietfountain.com>=0AContent-Type: text/plain; charset=3DISO-8859-1;= format=3Dflowed=0A=0AOn 04/21/2014 08:38 PM, Ronald F. Guilmette wrote:=0A= =0A> I suspect that a whole lot= of folks might be either (a) red faced or else=0A> (b) deeply concerned if= a scientifically derived estimate of the number of=0A> *remaining*=A0 (and= as-yet undiscovered) bugs in that package were published.=0AYes indeed.=A0= I think your comment 'as-yet undiscovered' is of an =0Aaspirational charac= ter.=0A=0AImagine if your job, every day, is to take all the same talent an= d =0Atraining involved in creating all this to find exploits.=A0 A person w= hose =0Amind isn't absorbed with knowing everything about one area enough t= o =0Amove it's art ahead, but enough about all the areas with emphasis on = =0Atheir interfaces and edge conditions.=A0 For example, just the right =0A= compiler quirk or processor microcode quirk with just the right OS quirk = =0Ain just the right library routine, or a quirk in the firmware of any =0A= device able to generate memory read bus cycles (smart network interface =0A= chips and hardware RAID cards come to mind, and, oh my -- graphics =0Aproce= ssors.... Every time device memory is mapped into user space ... =0Aworry.)= .=A0 The folks that do that are good at not sharing, and using them =0Aspar= ingly.=0A=0AIt's the same problem faced by any defender:=A0 the defenders h= ave to be =0Aentirely right all the time, while the exploit finder only has= to be =0Aright once.=A0 Only rigor approaching the level of math theorems = applied =0Ato software security (a trace easier than 'software correctness'= I =0Aexpect) can offer trustworthy assurances about blocking software-only= =0Aexploits.=0A=0AThe semantics of all our current popular languages, for = reasons to do =0Awith making early 8 bit processors deliver value,=A0 are s= ilent about what =0Ahappens to data that 'goes out of scope' or 'is freed',= most of the time =0Athe OS just marks the memory page 'unused' without kno= wing whether it's =0Aof importance to wipe.=A0 A few little-used languages= had 'garbage =0Acollection routines' that could have been good at wiping.= =A0 But mostly =0Aour languages struggled to do the right thing with data p= eople cared =0Aabout to bother much with what happened to it when 'done'.= =A0 There was no =0Aperformance that could be spared to "protect against da= ta =0Adumpster-divers".=A0 =A0 And wow look at what happened to programming= =0Adiscipline, particularly application programming, when throwing another= =0Agigabyte of ram or another processor into a machine cost less than =0At= uning a routine.=0A=0AMost of the time it's not worth the processor time to= wipe old data as =0Athe pages are bits from an old movie data anyhow.=A0 B= ut most of the time =0Aisn't all of the time.=0A=0APerhaps we should consid= er adding a variable attribute like 'secure' =0Amuch like 'volatile' was ad= ded, to cause the compiler to generate code =0Awiping such variables when t= hey go out of scope, force initialize them =0Ato a known bit pattern, and o= nly allocate those variables to pages that =0Aare wiped on free and that ca= n't be referenced by pointer or other means =0Aexcept by a function or proc= edure that also has a 'secure' attribute.=0A=0AI'll go back to lurking now!= =A0 Thanks for all your efforts.=0A=0AH=0A=0A=0A=0A=0A=0A=0A=0A------------= ------------------=0A=0ASubject: Digest Footer=0A=0A_______________________= ________________________=0Afreebsd-security@freebsd.org mailing list=0Ahttp= ://lists.freebsd.org/mailman/listinfo/freebsd-security=0ATo unsubscribe, se= nd any mail to "freebsd-security-unsubscribe@freebsd.org"=0A=0A------------= ------------------=0A=0AEnd of freebsd-security Digest, Vol 484, Issue 2=0A= ************************************************ From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 19:00:53 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F89715A for ; Tue, 22 Apr 2014 19:00:53 +0000 (UTC) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00C341CF5 for ; Tue, 22 Apr 2014 19:00:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4G00B004NU7800@local.mail-out.apple.com> for freebsd-security@freebsd.org; Tue, 22 Apr 2014 12:00:09 -0700 (PDT) Received: from relay5.apple.com ([17.128.113.88]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4G009EN4RNYEB0@local.mail-out.apple.com>; Tue, 22 Apr 2014 12:00:09 -0700 (PDT) X-AuditID: 11807158-f79c66d00000166b-8c-5356bc3936d7 Received: from [17.149.224.243] (Unknown_Domain [17.149.224.243]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 3F.5F.05739.93CB6535; Tue, 22 Apr 2014 12:00:09 -0700 (PDT) Subject: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Charles Swiger In-reply-to: <99496.1398130725@server1.tristatelogic.com> Date: Tue, 22 Apr 2014 12:00:08 -0700 Message-id: References: <99496.1398130725@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUiOPXBZ13LPWHBBjuWC1v0bHrCZvHq8is2 ByaPGZ/ms3jc39TIHMAUxWWTkpqTWZZapG+XwJWxfMoZ5oLLghUL9hQ2MP7l7WLk4JAQMJH4 3lbRxcgJZIpJXLi3nq2LkYtDSKCfSeJR1yRWkASzgJbEjX8vmUDqeQX0JLb/kgMJCwt4SFzc u4MFJMwmoCYxYSIPSJhTwFJi7qw/YJ0sAqoSZ9YtYoOYoiAxef53ZghbW2LZwtdgNq+AlcTn hZuYQGwhAQuJydMug9WLCOhLLN37lBHiNFmJ0+ees0xg5J+F5KBZCAfNQjJ1ASPzKkaBotSc xEpTvcSCgpxUveT83E2MoFBrKIzYwfh/mdUhRgEORiUeXonlYcFCrIllxZW5hxglOJiVRHil VwOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ox+wcLCaQnlqRmp6YWpBbBZJk4OKUaGO+pXNvU n6/Fs+j8yfU5Dft/TvkWxOWY47JK893lIInDap0Hf21+wG+t9nnaTAHu0t/fzFP+HpdR2uXf csGyb5WR8dRnNgd/ha14+PfJolUPnH5sOPtzlc0144r1H00PKCXeLWqdJtqXE73W7t0Z5zvn rYPM3UtaT+xQeFI3o7b2Urcf58Mk22QlluKMREMt5qLiRAB+Gi1SMQIAAA== Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 19:00:53 -0000 On Apr 21, 2014, at 6:38 PM, Ronald F. Guilmette wrote: > In the aftermath of this whole OpenSSL brouhaha... which none other than > Bruce Schneier publically pronounced to be a 12, on a scale from 1 to 10, > in terms of awfulness... I do wonder if anyone has taken the time or effort > to run the OpenSSL sources through any kind of analyzer to try to obtain > some of the standard sorts of software science metrics on it. Sure. Running clang's static analyzer against openssl-1.0.1g yields: Bug Type Quantity All Bugs 182 Dead store Dead assignment 121 Dead increment 12 Dead initialization 2 Logic error Assigned value is garbage or undefined 3 Branch condition evaluates to a garbage value 1 Dereference of null pointer 27 Division by zero 1 Result of operation is garbage or undefined 9 Uninitialized argument value 2 Unix API 4 The "division by zero" is ssl/t1_enc.c:267 and has 15 steps to reach; one of the null pointer cases, crypto/asn1/f_string.c:191, has a path length of 39. [ ... ] > P.S. I do think that Schneier has seriously overstated the criticality of > Heartbleed. So far, I am not aware of -any- banks or other financial > institutions which have been confirmed to have been affected, and by and > large, life goes on and the world has not ended. Most of the large financial institutions use hardware crypto-accelerators to speed up SSL; devices like F5's BIG-IP, Brocade's ServerIrons, Citrix NetScalers, etc. These vendors and their hardware tend to be conservative and were generally sticking with capabilities mirroring OpenSSL 0.9.8, rather than chasing TLS v1.2, perfect forward secrecy and the like from OpenSSL 1.x. Just as an FYI, I'd heard a rumbling or two about Heartbleed on Friday April 4, but the first open publication I saw of this was on Ars Technica thread here: http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping Note that around comment #78 by raphidae, that user ran the exploit against Ars and was able to grab username+passwords and login as other users. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 19:51:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 454717BB for ; Tue, 22 Apr 2014 19:51:52 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 2465113DA for ; Tue, 22 Apr 2014 19:51:51 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 1BE463AE0E for ; Tue, 22 Apr 2014 12:51:41 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <5355D9F7.2010208@quietfountain.com> Date: Tue, 22 Apr 2014 12:51:41 -0700 Message-ID: <7984.1398196301@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 19:51:52 -0000 In message <5355D9F7.2010208@quietfountain.com>, "hcoin" wrote: >Perhaps we should consider adding a variable attribute like 'secure' >much like 'volatile' was added, to cause the compiler to generate code >wiping such variables when they go out of scope, force initialize them >to a known bit pattern, and only allocate those variables to pages that >are wiped on free and that can't be referenced by pointer or other means >except by a function or procedure that also has a 'secure' attribute. In response to Heartbleed, I also put forward a somewhat different idea, but one which was also focused on new compiler options that might help to insure that code for which security is critical (e.g. OpenSSL) wouldn't be getting access to data that had been free()'d and/or data which had been placed into local variables, within a particular stack frame, after the corresponding function call had returned. Unfortunately, as it was then explained to me, none of these ideas would have helped prevent Heartbleed. In the case of Heartbleed, the problem wasn't that a hunk of ``uninitialized'' memory was accessed, but rather that an attacker could cause OpenSSL to create a buffer of size `N', fill it with valid data, but then later on the attacker could get OpenSSL to send back all the data in that buffer _and_ some _additional_ (perhaps validly initialized) data locations well past the end of that buffer. There's very little that a compiler, a run-time system, or even hardware can do to prevent this sort of thing. Careful programming and an object orientation might have saved the day, but having looked at a bit of the relevant code myself, I can say with some certainty that none of the latter was immediately evident. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 20:43:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C346D0E for ; Tue, 22 Apr 2014 20:43:22 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 76B5019FD for ; Tue, 22 Apr 2014 20:43:22 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 4ABA03AE36 for ; Tue, 22 Apr 2014 13:43:16 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org" Subject: Re: freebsd-security Digest, Vol 484, Issue 2 In-Reply-To: <1398169014.53411.YahooMailNeo@web28902.mail.ir2.yahoo.com> Date: Tue, 22 Apr 2014 13:43:16 -0700 Message-ID: <8389.1398199396@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 20:43:22 -0000 In message <1398169014.53411.YahooMailNeo@web28902.mail.ir2.yahoo.com>, Alfred Hegemeier wrote: >What a load of nonsense here: no, I don't think we should further extend th= >e boundaries of mathematical logic in order to avoid such bugs, and I don't= > think we should now change our programming habits and use the magic power = >of Haskell - I actually think, somebody should read the code that others pr= >ogram..especially if it is security related code, shouldn't anybody=A0 ?! = Having looked a little bit at the code in question, let me just say that I, for one, am not at all persuated that any traditional sort of human- based code review would have caught Heartbleed. The place where the buffer (which was much later on over-read) was allocated miles and miles away from the place where its contents... plus some other stuff... were being written back, verbatim, to the attacker. And as I pointed out (someplace, I forget where now) if *all* such buffers had been allocated to the maximum possible size in the first place... i.e. either 2^16 bytes or else only 2^14 if it was done properly, according to the spec... then there would never have been any problem. But at the place in the code where the response packet was being sent back, there were _two_ possible indicators of how much should be sent back, i.e. (1) the 16-bit _alleged_ original query packet payload size and (2) the actual original query packet payload size. And by that point in the code there was no clear reason at all to have any suspicion that the two wouldn't always be exactly equal, let alone that the former might actually be (fradulently) bigger than the latter. >This is a bug which children get taught to avoid when programming and how t= >o avoid, namely check the input, don't rely on the user entering a number b= >etween 1 and 10 even if you tell them, but check it, I don't think that the whole thing was really quite that simple. I think that the place where input packets were being received was built to be ``general purpose'' and that only these quirky keep-alive packets had an extra/additional 16-bit payload size field in them. The general purpose routine that read incoming packets couldn't have checked that 16-bit field for reasonablness because most of the input packets it would be reading wouldn't even have that field. I could be wrong about all this, but that was my impression, after skimming just some of the relevant code. (It certainly wasn't terribly easy to follow the code, but then I could say that about >90% of all code I've ever seen in my life... except my own, of course. :-) Regards, rfg From owner-freebsd-security@FreeBSD.ORG Tue Apr 22 21:29:03 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9779E4B8 for ; Tue, 22 Apr 2014 21:29:03 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 763AA1E82 for ; Tue, 22 Apr 2014 21:29:03 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 41A5F3AE0E for ; Tue, 22 Apr 2014 14:28:57 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: Date: Tue, 22 Apr 2014 14:28:57 -0700 Message-ID: <8783.1398202137@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 21:29:03 -0000 In message , Charles Swiger wrote: >On Apr 21, 2014, at 6:38 PM, Ronald F. Guilmette wrote >: >> In the aftermath of this whole OpenSSL brouhaha... which none other than >> Bruce Schneier publically pronounced to be a 12, on a scale from 1 to 10, >> in terms of awfulness... I do wonder if anyone has taken the time or effort >> to run the OpenSSL sources through any kind of analyzer to try to obtain >> some of the standard sorts of software science metrics on it. > >Sure. Running clang's static analyzer against openssl-1.0.1g yields: > >Bug Type Quantity >All Bugs 182 > >Dead store > Dead assignment 121 > Dead increment 12 > Dead initialization 2 > >Logic error > Assigned value is garbage or undefined 3 > Branch condition evaluates to a garbage value 1 > Dereference of null pointer 27 > Division by zero 1 > Result of operation is garbage or undefined 9 > Uninitialized argument value 2 > Unix API 4 Thank you for doing this. Perhaps it goes without aying, but I'll say it anyway. The above results are at once both enlightening and disgusting. Apparently, the OpenBSD guys are reorganizing/rewriting OpenSSL. I hope that they take the time to do what you have done *and* also to drive every bleedin' last one of these numbers to zero. I feel sure that the vast majority of the issues uncovered by clang are not in any sense exploitable, however its the one or two or three that are that worry me. Regards, rfg P.S. I was reading last night about VP8. In that case, apparently, the formal specification for that protocol *is* the code. (See RFC 6386, Section 1.) If you have time, Charles, perhaps you could run this same analysis on that code too, and report numbers for that as well. I am *not* looking forward to the day when I'll be rooted because I was watching funny kitten videos on YouTube. From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 00:34:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 389BC6F0 for ; Wed, 23 Apr 2014 00:34:12 +0000 (UTC) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by mx1.freebsd.org (Postfix) with SMTP id 05352105A for ; Wed, 23 Apr 2014 00:34:11 +0000 (UTC) Received: (qmail 18187 invoked by uid 0); 23 Apr 2014 00:34:10 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 23 Apr 2014 00:34:10 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw2 with id tCa21n00b36DqkS01Ca5RQ; Tue, 22 Apr 2014 18:34:09 -0600 X-Authority-Analysis: v=2.1 cv=Q9RBveGa c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=n-kJSqksAAAA:8 a=70qzlKQjAAAA:8 a=dM-xeHiPX5eh3JM4h3wA:9 a=CjuIK1q_8ugA:10 a=98jSFH7WqmUA:10 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:Cc:To:From:Date; bh=KBkjzO4OAWyE/zTVHUrYF6Q0qmbJeBRN+zr6/A+f6PU=; b=vCyvklXC5TLCfqI+5lGPtJd1cZv9UVHPgXmbf3rzOg7S+MBysmVSYwE3nOHnOOgcp7BiiqJPufcuwYVLm36N98eqVX04eMudqp993gUEHp08bB1Yj8uY78h+gJhTnbAo; Received: from [98.245.97.34] (port=62798 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Wcl8V-0000s8-EM; Tue, 22 Apr 2014 18:34:03 -0600 Date: Tue, 22 Apr 2014 18:34:00 -0600 From: Chad Perrin To: "Ronald F. Guilmette" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140423003400.GA8271@glaze.hydra> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <8783.1398202137@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8783.1398202137@server1.tristatelogic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 00:34:12 -0000 On Tue, Apr 22, 2014 at 02:28:57PM -0700, Ronald F. Guilmette wrote: > In message , > Charles Swiger wrote: > > > >Bug Type Quantity > >All Bugs 182 > > > >Dead store > > Dead assignment 121 > > Dead increment 12 > > Dead initialization 2 > > > >Logic error > > Assigned value is garbage or undefined 3 > > Branch condition evaluates to a garbage value 1 > > Dereference of null pointer 27 > > Division by zero 1 > > Result of operation is garbage or undefined 9 > > Uninitialized argument value 2 > > Unix API 4 > > Thank you for doing this. > > Perhaps it goes without aying, but I'll say it anyway. The above results > are at once both enlightening and disgusting. > > Apparently, the OpenBSD guys are reorganizing/rewriting OpenSSL. I hope > that they take the time to do what you have done *and* also to drive every > bleedin' last one of these numbers to zero. I feel sure that the vast > majority of the issues uncovered by clang are not in any sense exploitable, > however its the one or two or three that are that worry me. LibreSSL (re: reorganizing/forking OpenSSL). I'm sure they'll be doing a very thorough job, as LibreSSL will apparently be added to the full body of code managed and extensively code-reviewed by the OpenBSD project. The developers are also taking the encouraging first step of throwing away eight metric tons of cruft. I do not know whether they plan to specifically use Clang's static analyzer as an aid to their efforts, but I would guess they'll be taking similar measures. >From what I have seen (which, admittedly, is pretty superficial by many standards), it looks like OpenSSL is probably just the best of a really bad breed of software. The most widespread, popular, by some standard "major" TLS packages all seem to be rancid crap, with OpenSSL just being the marginally least rancid of the lot. If something like the heartbeat leak exists in OpenSSL, I fully expect that the other big players have worse problems. Consider for instance that (real-world impact aside) the heartbeat bug was the result of a failure of secure coding that took the form of a fairly common way for people to overlook memory management problems in C, while the validation issues recently unearthed in Apple and GnuTLS encryption packages were the sorts of errors that are rather uncommon for people to overlook, in that it almost takes a malicious act of stupidity to forget to *use* an otherwise correct validation, right there in the code where it took place. Even if LibreSSL ends up only halving the vulnerability that comes with OpenSSL (which is, I think, a quite inadequate level of improvement), it should end up being a fantastic leap forward, putting OpenSSL itself in a distant second place over alternatives. I'm mostly just hand-waving, though. If someone with deeper insight into the guts of these TLS packages offer contradicts me in some way with actual independently verifiable supporting analysis, you should probably believe that person. > > P.S. I was reading last night about VP8. In that case, apparently, > the formal specification for that protocol *is* the code. (See RFC > 6386, Section 1.) > > If you have time, Charles, perhaps you could run this same analysis on > that code too, and report numbers for that as well. > > I am *not* looking forward to the day when I'll be rooted because I was > watching funny kitten videos on YouTube. Solution: Dont' watch funny kitten videos on YouTube. I kid. I know it's impossible to stop watching funny kitten videos. A useful mitigation, however, might be to never log in to any Google service, and avoid HTTPS URIs for Google services when you must visit them. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 01:01:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A4B2E28 for ; Wed, 23 Apr 2014 01:01:16 +0000 (UTC) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2C8123B for ; Wed, 23 Apr 2014 01:01:15 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 13A8E34942E; Wed, 23 Apr 2014 01:00:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7B9A6160064; Wed, 23 Apr 2014 01:03:35 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 277DD160056; Wed, 23 Apr 2014 01:03:35 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2891E143D098; Wed, 23 Apr 2014 11:00:54 +1000 (EST) To: "Ronald F. Guilmette" , freebsd-security@freebsd.org From: Mark Andrews References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-reply-to: Your message of "Tue, 22 Apr 2014 18:34:00 -0600." <20140423003400.GA8271@glaze.hydra> Date: Wed, 23 Apr 2014 11:00:54 +1000 Message-Id: <20140423010054.2891E143D098@rock.dv.isc.org> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 01:01:16 -0000 In message <20140423003400.GA8271@glaze.hydra>, Chad Perrin writes: > On Tue, Apr 22, 2014 at 02:28:57PM -0700, Ronald F. Guilmette wrote: > > In message , > > Charles Swiger wrote: > > > > > >Bug Type Quantity > > >All Bugs 182 > > > > > >Dead store > > > Dead assignment 121 > > > Dead increment 12 > > > Dead initialization 2 > > > > > >Logic error > > > Assigned value is garbage or undefined 3 > > > Branch condition evaluates to a garbage value 1 > > > Dereference of null pointer 27 > > > Division by zero 1 > > > Result of operation is garbage or undefined 9 > > > Uninitialized argument value 2 > > > Unix API 4 > > > > Thank you for doing this. > > > > Perhaps it goes without aying, but I'll say it anyway. The above results > > are at once both enlightening and disgusting. > > > > Apparently, the OpenBSD guys are reorganizing/rewriting OpenSSL. I hope > > that they take the time to do what you have done *and* also to drive every > > bleedin' last one of these numbers to zero. I feel sure that the vast > > majority of the issues uncovered by clang are not in any sense exploitable, > > however its the one or two or three that are that worry me. > > LibreSSL (re: reorganizing/forking OpenSSL). I'm sure they'll be doing > a very thorough job, as LibreSSL will apparently be added to the full > body of code managed and extensively code-reviewed by the OpenBSD > project. The developers are also taking the encouraging first step of > throwing away eight metric tons of cruft. I do not know whether they > plan to specifically use Clang's static analyzer as an aid to their > efforts, but I would guess they'll be taking similar measures. > > >From what I have seen (which, admittedly, is pretty superficial by many > standards), it looks like OpenSSL is probably just the best of a really > bad breed of software. The most widespread, popular, by some standard > "major" TLS packages all seem to be rancid crap, with OpenSSL just being > the marginally least rancid of the lot. If something like the heartbeat > leak exists in OpenSSL, I fully expect that the other big players have > worse problems. Consider for instance that (real-world impact aside) > the heartbeat bug was the result of a failure of secure coding that took > the form of a fairly common way for people to overlook memory management > problems in C, Heartbleed had NOTHING to do with memory managment. It was a input parsing bug plain and simple. Standard malloc would not have helped one iota. Even turning on no standard malloc features like overwrite on free was not guarenteed to help. All that does is reduce the amount of memory with data that could be read. It does not prevent active memory being read. As for the number of CLANG analysis warnings. Clang has false positives some of which are impossible to remove regardless of how you recode the section and most of what was reported will be benign. We use clang, Coverity and other tools all the time on products we ship. We use multiple compilers and each one of them pick up different things. Even after doing all that and removing all the warning we can we have to mark things as "Ingore - false positive" or "Ignore - Intentional" as the analyser doesn't follow all of the assignments or doesn't handle initialisation code that doesn't need to be locked or ..... > while the validation issues recently unearthed in Apple > and GnuTLS encryption packages were the sorts of errors that are rather > uncommon for people to overlook, in that it almost takes a malicious act > of stupidity to forget to *use* an otherwise correct validation, right > there in the code where it took place. > > Even if LibreSSL ends up only halving the vulnerability that comes with > OpenSSL (which is, I think, a quite inadequate level of improvement), it > should end up being a fantastic leap forward, putting OpenSSL itself in > a distant second place over alternatives. > > I'm mostly just hand-waving, though. If someone with deeper insight > into the guts of these TLS packages offer contradicts me in some way > with actual independently verifiable supporting analysis, you should > probably believe that person. > > > > > > P.S. I was reading last night about VP8. In that case, apparently, > > the formal specification for that protocol *is* the code. (See RFC > > 6386, Section 1.) > > > > If you have time, Charles, perhaps you could run this same analysis on > > that code too, and report numbers for that as well. > > > > I am *not* looking forward to the day when I'll be rooted because I was > > watching funny kitten videos on YouTube. > > Solution: Dont' watch funny kitten videos on YouTube. > > I kid. I know it's impossible to stop watching funny kitten videos. A > useful mitigation, however, might be to never log in to any Google > service, and avoid HTTPS URIs for Google services when you must visit > them. > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 01:12:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AF656EA for ; Wed, 23 Apr 2014 01:12:18 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 1D33B13A3 for ; Wed, 23 Apr 2014 01:12:17 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id B095C3AE0E for ; Tue, 22 Apr 2014 18:12:11 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <20140423010054.2891E143D098@rock.dv.isc.org> Date: Tue, 22 Apr 2014 18:12:11 -0700 Message-ID: <10999.1398215531@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 01:12:18 -0000 In message <20140423010054.2891E143D098@rock.dv.isc.org>, Mark Andrews wrote: >As for the number of CLANG analysis warnings. Clang has false >positives Please define your terms. I do imagine that the truth or falsehood of your assertion may depend quite substantally on what one does or does not consider a "false positive" in this context. >some of which are impossible to remove regardless of how >you recode the section... I, for one, would dearly love to see one or more concrete examples which purport to support the above assertion (of which I am dubious). Regards, rfg From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 01:23:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B04B7DE3 for ; Wed, 23 Apr 2014 01:23:17 +0000 (UTC) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by mx1.freebsd.org (Postfix) with SMTP id 7C4A1151E for ; Wed, 23 Apr 2014 01:23:17 +0000 (UTC) Received: (qmail 30933 invoked by uid 0); 23 Apr 2014 01:22:15 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 23 Apr 2014 01:22:15 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw4 with id tDN91n00J36DqkS01DNCX7; Tue, 22 Apr 2014 19:22:15 -0600 X-Authority-Analysis: v=2.1 cv=CpMsLBID c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=n-kJSqksAAAA:8 a=70qzlKQjAAAA:8 a=GShNCy7UdeY8KAeUwwQA:9 a=zEfG3Wk7v08oQ7GP:21 a=dAVhYuXg8FwIAxtv:21 a=CjuIK1q_8ugA:10 a=98jSFH7WqmUA:10 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=LQ7C/nR98hSlLxKTizlPPWBpvsN5qP8wiAFqQG8sw58=; b=zDrXXIlWtGAYKbzu8F096YOYoHO2nT0hLxNTvyxh0+ZQVy5GgiMfn/Vdrfl5DdTAoggF1cV46k8atrDhf/WxNf+kj+7bhJqsNLQqmry/me+WlbbaU7nL4E/PxuotQ2dE; Received: from [98.245.97.34] (port=60282 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Wclt3-0007nb-Cm; Tue, 22 Apr 2014 19:22:09 -0600 Date: Tue, 22 Apr 2014 19:22:06 -0600 From: Chad Perrin To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140423012206.GB8271@glaze.hydra> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140423010054.2891E143D098@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 01:23:17 -0000 On Wed, Apr 23, 2014 at 11:00:54AM +1000, Mark Andrews wrote: > In message <20140423003400.GA8271@glaze.hydra>, Chad Perrin writes: > > On Tue, Apr 22, 2014 at 02:28:57PM -0700, Ronald F. Guilmette wrote: > > > In message , > > > Charles Swiger wrote: > > > > > > > >Bug Type Quantity > > > >All Bugs 182 > > > > > > > >Dead store > > > > Dead assignment 121 > > > > Dead increment 12 > > > > Dead initialization 2 > > > > > > > >Logic error > > > > Assigned value is garbage or undefined 3 > > > > Branch condition evaluates to a garbage value 1 > > > > Dereference of null pointer 27 > > > > Division by zero 1 > > > > Result of operation is garbage or undefined 9 > > > > Uninitialized argument value 2 > > > > Unix API 4 > > > > > > Thank you for doing this. > > > > > > Perhaps it goes without aying, but I'll say it anyway. The above results > > > are at once both enlightening and disgusting. > > > > > > Apparently, the OpenBSD guys are reorganizing/rewriting OpenSSL. I hope > > > that they take the time to do what you have done *and* also to drive every > > > bleedin' last one of these numbers to zero. I feel sure that the vast > > > majority of the issues uncovered by clang are not in any sense exploitable, > > > however its the one or two or three that are that worry me. > > > > LibreSSL (re: reorganizing/forking OpenSSL). I'm sure they'll be doing > > a very thorough job, as LibreSSL will apparently be added to the full > > body of code managed and extensively code-reviewed by the OpenBSD > > project. The developers are also taking the encouraging first step of > > throwing away eight metric tons of cruft. I do not know whether they > > plan to specifically use Clang's static analyzer as an aid to their > > efforts, but I would guess they'll be taking similar measures. > > > > From what I have seen (which, admittedly, is pretty superficial by many > > standards), it looks like OpenSSL is probably just the best of a really > > bad breed of software. The most widespread, popular, by some standard > > "major" TLS packages all seem to be rancid crap, with OpenSSL just being > > the marginally least rancid of the lot. If something like the heartbeat > > leak exists in OpenSSL, I fully expect that the other big players have > > worse problems. Consider for instance that (real-world impact aside) > > the heartbeat bug was the result of a failure of secure coding that took > > the form of a fairly common way for people to overlook memory management > > problems in C, > > Heartbleed had NOTHING to do with memory managment. It was a input > parsing bug plain and simple. Standard malloc would not have helped > one iota. Even turning on no standard malloc features like overwrite > on free was not guarenteed to help. All that does is reduce the > amount of memory with data that could be read. It does not prevent > active memory being read. The first sentence of that paragraph depends for its accuracy on your definition of memory management. If you exclude "allowing improper access to memory by failing to check bounds on requests" from "memory management", then sure, it had "NOTHING" to do with memory management. I took a somewhat looser approach to defining "memory management" in my statement. I apologize for being the hapless stranger to set off your negative reaction to use of the term "memory management" for anything other than allocating and de-allocating memory. > > As for the number of CLANG analysis warnings. Clang has false > positives some of which are impossible to remove regardless of how > you recode the section and most of what was reported will be benign. I don't know why you're saying that in response to *me*. I didn't really say anything about the bug count in the Clang static analysis. > > We use clang, Coverity and other tools all the time on products we > ship. We use multiple compilers and each one of them pick up > different things. Even after doing all that and removing all the > warning we can we have to mark things as "Ingore - false positive" > or "Ignore - Intentional" as the analyser doesn't follow all of the > assignments or doesn't handle initialisation code that doesn't need > to be locked or ..... Obviously, human judgment is an important part of the process of finding and fixing bugs. If it wasn't, the last program we'd ever have to debug would be the one that finds and fixes bugs. . . . and? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 08:51:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E05581E7 for ; Wed, 23 Apr 2014 08:51:04 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A246A1443 for ; Wed, 23 Apr 2014 08:51:04 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id dc16so575258qab.7 for ; Wed, 23 Apr 2014 01:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wB/PqxmTVX0BihqMX4by3uNX5L1zch4rFthrA2FQ3R0=; b=PdG6ymokLWOY+zaEdQi/45JCCbxVp7dPJI5Yn+feLrZldm6nXqv24QeQ7P5qCe3y5t gFz/MCWO8vxVOjxBqmnyYxGH5B6OUO0ortxba+xbA17fWAVokyk+yKl/NCQNLr3gVO2a kTe6mncOsurpLse4gFWl6IR7V+r3oV12yQZM0ODr7iCen/njigfSewBfIN8OZjzWJNV4 HZhGFLnVO6DNLRQ271emxAZt1s07DdI1mNIuRnxTtKN80FPDIVmZGXv9BTdDjmvY0+bN 60mJRBI6aUX+dniFkFC1EzSv8jXSj6oDR8GHam6xQ2D0S6t1422VYQjn2Bu8E1jcY2fj nW4g== MIME-Version: 1.0 X-Received: by 10.224.147.77 with SMTP id k13mr54635848qav.64.1398243063777; Wed, 23 Apr 2014 01:51:03 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Wed, 23 Apr 2014 01:51:03 -0700 (PDT) In-Reply-To: <8783.1398202137@server1.tristatelogic.com> References: <8783.1398202137@server1.tristatelogic.com> Date: Wed, 23 Apr 2014 09:51:03 +0100 X-Google-Sender-Auth: zVIynTHwHJHCBhVfVDigojqMsCE Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 08:51:05 -0000 On 22 April 2014 22:28, Ronald F. Guilmette wrote: > > In message , > Charles Swiger wrote: > >>On Apr 21, 2014, at 6:38 PM, Ronald F. Guilmette wrote >>: >>> In the aftermath of this whole OpenSSL brouhaha... which none other than >>> Bruce Schneier publically pronounced to be a 12, on a scale from 1 to 10, >>> in terms of awfulness... I do wonder if anyone has taken the time or effort >>> to run the OpenSSL sources through any kind of analyzer to try to obtain >>> some of the standard sorts of software science metrics on it. >> >>Sure. Running clang's static analyzer against openssl-1.0.1g yields: >> >>Bug Type Quantity >>All Bugs 182 >> >>Dead store >> Dead assignment 121 >> Dead increment 12 >> Dead initialization 2 >> >>Logic error >> Assigned value is garbage or undefined 3 >> Branch condition evaluates to a garbage value 1 >> Dereference of null pointer 27 >> Division by zero 1 >> Result of operation is garbage or undefined 9 >> Uninitialized argument value 2 >> Unix API 4 > > Thank you for doing this. > > Perhaps it goes without aying, but I'll say it anyway. The above results > are at once both enlightening and disgusting. > > Apparently, the OpenBSD guys are reorganizing/rewriting OpenSSL. I hope > that they take the time to do what you have done *and* also to drive every > bleedin' last one of these numbers to zero. I feel sure that the vast > majority of the issues uncovered by clang are not in any sense exploitable, > however its the one or two or three that are that worry me. > > > Regards, > rfg > > > P.S. I was reading last night about VP8. In that case, apparently, > the formal specification for that protocol *is* the code. (See RFC > 6386, Section 1.) > > If you have time, Charles, perhaps you could run this same analysis on > that code too, and report numbers for that as well. > > I am *not* looking forward to the day when I'll be rooted because I was > watching funny kitten videos on YouTube. So where are your patches to fix these issues? From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 08:57:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E8FF34F for ; Wed, 23 Apr 2014 08:57:50 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FF2D1530 for ; Wed, 23 Apr 2014 08:57:49 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id m20so619114qcx.7 for ; Wed, 23 Apr 2014 01:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a2DKAZCK8WU8sdzv2AW9IZ5J+CaRqykY/25n+WZuhiE=; b=nVIlTcpKBGcfN1qatQ9I8mlBNTTLhIVTA8nUuAzTADe8uKFBBsKF+x8WVEGN1L2AOY iAmcVlQ767DUNVsgNLEpvahgy0C7GhfitZD0GQR86C+Ga77FZHni4TbIuOeLiWJtAKDC 3hyTE3YFEup5xuknhlm7ROGDGFx91OWJwmVzeLhJvUNzFzOHe5sBU7rMoJYss1zdsqyq uNErmXBwyblIZenb2Nj9YdEECz295TgRZf5cqjzs9mxX6Yl6O6u/+cEsmLfa+yQE6lII iOx9xgMgOKwduNJ+Ua/mkdhRn4woVqjR7lDEy3Ya3OczX410eZIjP2MkuD9TO+iiHktY Um7A== MIME-Version: 1.0 X-Received: by 10.229.221.194 with SMTP id id2mr55328602qcb.5.1398243469145; Wed, 23 Apr 2014 01:57:49 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Wed, 23 Apr 2014 01:57:49 -0700 (PDT) In-Reply-To: <10999.1398215531@server1.tristatelogic.com> References: <20140423010054.2891E143D098@rock.dv.isc.org> <10999.1398215531@server1.tristatelogic.com> Date: Wed, 23 Apr 2014 09:57:49 +0100 X-Google-Sender-Auth: VxdVwA3SNsJ85o5jV5Pu7ToVU4I Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 08:57:50 -0000 On 23 April 2014 02:12, Ronald F. Guilmette wrote: > > In message <20140423010054.2891E143D098@rock.dv.isc.org>, > Mark Andrews wrote: > >>As for the number of CLANG analysis warnings. Clang has false >>positives > > Please define your terms. > > I do imagine that the truth or falsehood of your assertion may depend > quite substantally on what one does or does not consider a "false > positive" in this context. > >>some of which are impossible to remove regardless of how >>you recode the section... > > I, for one, would dearly love to see one or more concrete examples > which purport to support the above assertion (of which I am dubious). So try wading through the morass of false positives yourself and discover what a joy it is for yourself. From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 10:14:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B193E842 for ; Wed, 23 Apr 2014 10:14:01 +0000 (UTC) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71E911CBA for ; Wed, 23 Apr 2014 10:14:00 +0000 (UTC) Received: from [192.168.1.12] (unknown [217.157.7.221]) by csmtp3.one.com (Postfix) with ESMTPA id C7F5440013835; Wed, 23 Apr 2014 10:06:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Erik Cederstrand In-Reply-To: <10999.1398215531@server1.tristatelogic.com> Date: Wed, 23 Apr 2014 12:06:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> References: <10999.1398215531@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.1874) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 10:14:01 -0000 Den 23/04/2014 kl. 03.12 skrev Ronald F. Guilmette = : >=20 > In message <20140423010054.2891E143D098@rock.dv.isc.org>,=20 > Mark Andrews wrote: >=20 >> As for the number of CLANG analysis warnings. Clang has false >> positives >=20 > Please define your terms. >=20 > I do imagine that the truth or falsehood of your assertion may depend > quite substantally on what one does or does not consider a "false > positive" in this context. Have a look at the ~10.000 reports at = http://scan.freebsd.your.org/freebsd-head/ (unavailable ATM). Silly = things are reported like missing return at the end of main() or not = free()ing memory two lines before program exit. There are nonsensical = reports because the analyzer doesn't detect exit() in a usage() function = because usage() is defined in a separate compilation unit, or this: int foo(int y, int z) { int x; if (y =3D=3D z) { x =3D 0; } else { if (y !=3D z) { x =3D 1; } } return x; } warning that x may be uninitialized. Fixing these require considerable = effort e.g. improving IPA and adding alpha-remaning support to the = analyzer's constraint manager, or would result in unnecessary code churn = in FreeBSD just to work around the reports. My best guess is that at least 90% of the reports are either false = positives or really silly. Which doesn't mean that the reports are = useless, but a lot of time is wasted finding real bugs. Erik= From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 17:54:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF220354 for ; Wed, 23 Apr 2014 17:54:01 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA87B143A for ; Wed, 23 Apr 2014 17:54:01 +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 s3NHrmBS013349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2014 10:53: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 s3NHrlxB013348; Wed, 23 Apr 2014 10:53:47 -0700 (PDT) (envelope-from jmg) Date: Wed, 23 Apr 2014 10:53:47 -0700 From: John-Mark Gurney To: Erik Cederstrand Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140423175347.GI43976@funkthat.com> Mail-Followup-To: Erik Cederstrand , "Ronald F. Guilmette" , "freebsd-security@freebsd.org" References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 23 Apr 2014 10:53:49 -0700 (PDT) Cc: "freebsd-security@freebsd.org" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 17:54:01 -0000 Erik Cederstrand wrote this message on Wed, Apr 23, 2014 at 12:06 +0200: > Den 23/04/2014 kl. 03.12 skrev Ronald F. Guilmette : > > > > In message <20140423010054.2891E143D098@rock.dv.isc.org>, > > Mark Andrews wrote: > > > >> As for the number of CLANG analysis warnings. Clang has false > >> positives > > > > Please define your terms. > > > > I do imagine that the truth or falsehood of your assertion may depend > > quite substantally on what one does or does not consider a "false > > positive" in this context. > > Have a look at the ~10.000 reports at http://scan.freebsd.your.org/freebsd-head/ (unavailable ATM). Silly things are reported like missing return at the end of main() Considering that this is legal C99, it is very silly, from 5.1.2.2.3 of the C99 spec: reaching the } that terminates the main function returns a value of 0. -- 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 Wed Apr 23 19:14:46 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4A31925 for ; Wed, 23 Apr 2014 19:14:46 +0000 (UTC) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 846311B93 for ; Wed, 23 Apr 2014 19:14:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4H00200ZYQZE00@local.mail-out.apple.com> for freebsd-security@freebsd.org; Wed, 23 Apr 2014 12:14:40 -0700 (PDT) Received: from relay6.apple.com ([17.128.113.90]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4I009U303KACD0@local.mail-out.apple.com>; Wed, 23 Apr 2014 12:14:40 -0700 (PDT) X-AuditID: 1180715a-f79cb6d00000168c-32-5358112004e6 Received: from [17.149.224.243] (Unknown_Domain [17.149.224.243]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id BD.A8.05772.02118535; Wed, 23 Apr 2014 12:14:40 -0700 (PDT) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Charles Swiger In-reply-to: <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> Date: Wed, 23 Apr 2014 12:14:40 -0700 Message-id: References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> To: Erik Cederstrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUiOPXBZ10FwYhgg61TRCyevrW36Nn0hM2B yaN5+WJ2jxmf5rMEMEVx2aSk5mSWpRbp2yVwZRw+85ul4JVExYdJl1kaGLuEuxg5OSQETCSO 3JrDAmGLSVy4t54NxBYS6GeS2HBFAMRmFtCSuPHvJVMXIwcHr4CexPZfciCmsICPxIMjxiAm m4CaxISJPCDFnAJOEv1LfoENYRFQldi9eg8TxBAviUePJzJC2NoSyxa+ZgaxeQWsJJYd7GSH WJonsf/TEbAaEQEDiRMf3zNDHCYrcfrcc5YJjPyzkNwzC+GeWUimLmBkXsUoUJSak1hpppdY UJCTqpecn7uJERRoDYVROxgbllsdYhTgYFTi4ZW4HB4sxJpYVlyZe4hRgoNZSYTXliEiWIg3 JbGyKrUoP76oNCe1+BCjNAeLkjgvAxdQtUB6YklqdmpqQWoRTJaJg1OqgbH8qOnZ7f/W/S0/ YX2N8d+0W5dq29l3OQWf7ktvVJT8FHBzn1dzDkOojMcltivHjmw+YhwrKbUwVOLzQjMb7hVS YmXsBucObn+28YZK38LN/oceMISd9y5blftwrerPsI0OC+o041a23Eg7c6HqYT+jcbP05du8 uZx86ze1WNf8q9DaMbeqsVeJpTgj0VCLuag4EQBdlg2OMAIAAA== Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 19:14:46 -0000 Hi-- On Apr 23, 2014, at 3:06 AM, Erik Cederstrand wrote: > Den 23/04/2014 kl. 03.12 skrev Ronald F. Guilmette : [ ... ] >> I do imagine that the truth or falsehood of your assertion may depend >> quite substantally on what one does or does not consider a "false >> positive" in this context. > > Have a look at the ~10.000 reports at http://scan.freebsd.your.org/freebsd-head/ (unavailable ATM). Silly things are reported like missing return at the end of main() or not free()ing memory two lines before program exit. There are nonsensical reports because the analyzer doesn't detect exit() in a usage() function because usage() is defined in a separate compilation unit, or this: Sure, static analysis isn't perfect and runs into false positives, some of which are truly harmless and some of which actually do indicate an area where refactoring the code in light of the warning would be an improvement. It's worth noting that even if you believe that (e.g.) the clang static analyzer isn't properly doing liveness analysis and misjudging whether there's a dead assignment (writing to a variable which is never read), the clang compiler will be using the same analysis when doing dead-code elimination and common-subexpression elimination and such while optimizing. > int foo(int y, int z) { > int x; > if (y == z) { > x = 0; > } else { > if (y != z) { > x = 1; > } > } > return x; > } > > warning that x may be uninitialized. Fixing these require considerable effort e.g. improving IPA and adding alpha-remaning support to the analyzer's constraint manager, or would result in unnecessary code churn in FreeBSD just to work around the reports. Ah, that's a classic example. If you declared y and z as const, then I'd agree that the compiler should be free to make assumptions that one of the two if statements must be true. On the other hand, if you assume that the arguments are volatile and that maybe another thread might update y or z on the stack between the time when the first if test is evaluated and the second if, one realizes that the static analyzer might actually have a point. (Or you're on an SMP system and don't get sequential consistency / total-store ordering without memory barriers....) Sure, your code might never intentionally try to mess with the stack, but there's a long history of bugs like typing ~1030 characters at a password prompt and blowing past a char passwd[1024] buffer that someone assumed would be more than enough. The most straightforward changes to this snippet would be either: int foo(int y, int z) { int x; if (y == z) { x = 0; } else { x = 1; } return x; } ...or: int foo(int y, int z) { int x = 0; if (y != z) { x = 1; } return x; } Not only are both of these shorter and they pass clang's static analyzer without a warning, I'd argue that the second version is noticeably cleaner. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 20:28:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9BC52B0 for ; Wed, 23 Apr 2014 20:28:55 +0000 (UTC) Received: from csmtp10.one.com (csmtp10.one.com [195.47.247.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99CEA13AE for ; Wed, 23 Apr 2014 20:28:55 +0000 (UTC) Received: from bigmac.router9fbd7c.com (unknown [176.222.238.90]) by csmtp10.one.com (Postfix) with ESMTPA id B682B400002B7; Wed, 23 Apr 2014 20:21:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Erik Cederstrand In-Reply-To: Date: Wed, 23 Apr 2014 22:21:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> To: Charles Swiger X-Mailer: Apple Mail (2.1874) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 20:28:55 -0000 Den 23/04/2014 kl. 21.14 skrev Charles Swiger : > The most straightforward changes to this snippet would be either: >=20 > int foo(int y, int z) { > int x; > if (y =3D=3D z) { > x =3D 0; > } else { > x =3D 1; > } > return x; > } >=20 > ...or: >=20 > int foo(int y, int z) { > int x =3D 0; > if (y !=3D z) { > x =3D 1; > } > return x; > } >=20 > Not only are both of these shorter and they pass clang's static = analyzer without a warning, I'd argue that the second version is = noticeably cleaner. I don't disagree with you, but rewriting 1000 if-else cases in = single-threaded userland programs just so the analyzer understands them = is 1) tedious and 2) bound to accidentally introduce at least 50 new = bugs, since most real-life examples are considerably more complicated = than the minimal example I posted. Erik= From owner-freebsd-security@FreeBSD.ORG Wed Apr 23 23:36:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B76951A8 for ; Wed, 23 Apr 2014 23:36:08 +0000 (UTC) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 916A716AF for ; Wed, 23 Apr 2014 23:36:07 +0000 (UTC) MIME-version: 1.0 Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4I00300BZCWD00@local.mail-out.apple.com> for freebsd-security@freebsd.org; Wed, 23 Apr 2014 16:36:06 -0700 (PDT) Received: from relay8.apple.com ([17.128.113.102]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4I000EUC7XM021@local.mail-out.apple.com>; Wed, 23 Apr 2014 16:36:06 -0700 (PDT) X-AuditID: 11807166-f79c26d000001623-eb-53584e664d37 Received: from [17.149.224.243] (Unknown_Domain [17.149.224.243]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id B9.5B.05667.66E48535; Wed, 23 Apr 2014 16:36:06 -0700 (PDT) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Charles Swiger In-reply-to: <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> Date: Wed, 23 Apr 2014 16:36:05 -0700 Message-id: References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> To: Erik Cederstrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUiOPXBZ900v4hggzdPFC2evrW36Nn0hM2B yaN5+WJ2jxmf5rMEMEVx2aSk5mSWpRbp2yVwZdzbuoS54LFGRcvylUwNjM+Vuhg5OSQETCQ+ TZ/GBmGLSVy4tx7MFhLoZ5LY/qsGxGYWSJB43/6JtYuRg4NXQA8oLAdiCgv4SDw4Ygxisgmo SUyYyANSzCngJLG3/QYjiM0ioCpx6vhpFoghjhJTpnwDs3kFrCQWT/nK3sXIBbToMqPE1PZb zCAJEQEDiRMf3zNDXCMrcfrcc5YJjHyzkBwxC+EIiLC2xLKFr5lBwswCOhKTFzKiCkPYH88f YVrAyLaKUaAoNSex0kIvsaAgJ1UvOT93EyMoMBsK03YwNi23OsQowMGoxMMrcTk8WIg1say4 MvcQowQHs5IIb55HRLAQb0piZVVqUX58UWlOavEhRmkOFiVxXgYuoGqB9MSS1OzU1ILUIpgs EwenVANjY6C2r9uN5PNe/ltENv449Z83+dXW3YH7D8X4HFyblq9ZaLm9hNd77571eo92XY99 mlzv2fc00m9zWvW3CeEflOyOKD+YcULklmf2N+7n6e4n8yx2JvwIL2I1eKKx+dpj+TUGW83s bc33brzbqabWPN/cc07sGl6W7BdS1xeeCo2frim5/Uq5EktxRqKhFnNRcSIAjN81pEgCAAA= Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:36:08 -0000 On Apr 23, 2014, at 1:21 PM, Erik Cederstrand wrote: [ ... ] >> Not only are both of these shorter and they pass clang's static analyzer without a warning, I'd argue that the second version is noticeably cleaner. > > I don't disagree with you, but rewriting 1000 if-else cases in single-threaded userland programs just so the analyzer understands them is 1) tedious and 2) bound to accidentally introduce at least 50 new bugs, since most real-life examples are considerably more complicated than the minimal example I posted. Any change comes with some risk. If you want to say that fixing minor issues like not free()ing memory or explicitly close()ing a FD rather than just exit()ing and letting the system clean up afterwards is not worth bothering in something like cal or some other utility that isn't running root or setuid, doesn't listen on the network, doesn't process untrusted data, etc...well, OK-- by themselves, such things probably are harmless. However, being sloppy about fixing warnings from the compiler or code analyzers seems to be habit-forming. And as you start moving towards software which does run with elevated permissions, or acts as a network server, or processes random multimedia files from untrusted web pages (I'm thinking a codec like VP8), much less is used to provide transport layer security for credit card and banking transactions, well, you also move from harmless to Heartbleed. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 00:07:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93B58594 for ; Thu, 24 Apr 2014 00:07:56 +0000 (UTC) Received: from mail.in-addr.com (noop.in-addr.com [208.58.23.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F0EC191D for ; Thu, 24 Apr 2014 00:07:55 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Wd7Ca-0002b5-7F; Wed, 23 Apr 2014 20:07:44 -0400 Date: Wed, 23 Apr 2014 20:07:44 -0400 From: Gary Palmer To: Charles Swiger Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140424000744.GE15884@in-addr.com> References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> 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" , Erik Cederstrand X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 00:07:56 -0000 On Wed, Apr 23, 2014 at 04:36:05PM -0700, Charles Swiger wrote: > On Apr 23, 2014, at 1:21 PM, Erik Cederstrand wrote: > [ ... ] > >> Not only are both of these shorter and they pass clang's static analyzer without a warning, I'd argue that the second version is noticeably cleaner. > > > > I don't disagree with you, but rewriting 1000 if-else cases in single-threaded userland programs just so the analyzer understands them is 1) tedious and 2) bound to accidentally introduce at least 50 new bugs, since most real-life examples are considerably more complicated than the minimal example I posted. > > > Any change comes with some risk. > > If you want to say that fixing minor issues like not free()ing memory or explicitly close()ing a FD rather than just exit()ing and letting the system clean up afterwards is not worth bothering in something like cal or some other utility that isn't running root or setuid, doesn't listen on the network, doesn't process untrusted data, etc...well, OK-- by themselves, such things probably are harmless. > > However, being sloppy about fixing warnings from the compiler or code analyzers seems to be habit-forming. > > And as you start moving towards software which does run with elevated permissions, or acts as a network server, or processes random multimedia files from untrusted web pages (I'm thinking a codec like VP8), much less is used to provide transport layer security for credit card and banking transactions, well, you also move from harmless to Heartbleed. Compiler warnings and static code analysis are a small part of a secure programming mentality/methodology, and in and of themselves are fairly useless. I doubt either would have caught Heartbleed. We've been warned about SQL injection and other related flaws for years, and yet people STILL don't do proper validation of untrusted input. Until we get the basics correct, the rest doesn't really matter. e.g. it doesn't really matter if your code passes gcc -Wall -Werror when you can still take input from the wire and pass it straight to a SQL statement, or use it to calculate how much data to send back to the client, when the data requested can exceed the maximum valid response size by several orders of magnitude. Even worse when the protocol design allows for such a request in the first place. Too many programs think it's fine to replace the system malloc/free functions with their own versions because of performance or other reasons, potentially removing yet more layers of protection, or at minimum introducing more points of failure that need to be examined and tested. I also think we're getting off topic. Any concrete steps people are willing to take to make FreeBSD more secure? Gary From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 06:43:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 925C04ED; Thu, 24 Apr 2014 06:43:58 +0000 (UTC) Received: from csmtp14.one.com (csmtp14.one.com [195.47.247.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F64F1D41; Thu, 24 Apr 2014 06:43:57 +0000 (UTC) Received: from [172.20.10.3] (94.191.184.93.mobile.3.dk [94.191.184.93]) by csmtp14.one.com (Postfix) with ESMTPA id 15628400000EE; Thu, 24 Apr 2014 06:34:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Erik Cederstrand In-Reply-To: <20140424000744.GE15884@in-addr.com> Date: Thu, 24 Apr 2014 08:33:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9330A007-63D2-4930-AB33-4EEE64AEF670@cederstrand.dk> References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> <20140424000744.GE15884@in-addr.com> To: Gary Palmer X-Mailer: Apple Mail (2.1874) Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 06:43:58 -0000 Den 24/04/2014 kl. 02.07 skrev Gary Palmer : >=20 > I also think we're getting off topic. Any concrete steps people are > willing to take to make FreeBSD more secure? Well, the static analysis reports aren't totally useless, but we need = some way of marking them as false positive or wontfix, so the effort = isn't duplicated. Out of the 10.000 reports, a conservative guess is = that at least 100 of them are real security issues. And they are public, = so Mallory can just pick one now and write an exploit. A year ago, I did = a raid on reports about not checking the return value of setuid() and = friends, which did uncover real issues. Erik= From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 08:32:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74CBAA2F for ; Thu, 24 Apr 2014 08:32:57 +0000 (UTC) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0082.outbound.protection.outlook.com [213.199.154.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BFC5189A for ; Thu, 24 Apr 2014 08:32:55 +0000 (UTC) Received: from [192.168.11.2] (88.192.40.21) by DB3PR06MB620.eurprd06.prod.outlook.com (10.255.71.42) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 07:59:58 +0000 Message-ID: <5358C474.5060903@simgroep.nl> Date: Thu, 24 Apr 2014 10:59:48 +0300 From: Paul van Erk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Subject: gnutls vulnerabilities disappeared Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [88.192.40.21] X-ClientProxiedBy: DBXPR05CA006.eurprd05.prod.outlook.com (10.255.191.174) To DB3PR06MB620.eurprd06.prod.outlook.com (10.255.71.42) X-Forefront-PRVS: 01917B1794 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(6049001)(6009001)(428001)(189002)(199002)(23756003)(65816999)(87266999)(54356999)(87976001)(50986999)(36756003)(86362001)(33656001)(92726001)(81342001)(83506001)(81542001)(50466002)(92566001)(74662001)(74482001)(31966008)(15202345003)(85852003)(99396002)(19580395003)(80316001)(83322001)(80976001)(64126003)(59896001)(77982001)(80022001)(66066001)(15975445006)(74502001)(65956001)(4396001)(65806001)(83072002)(46102001)(47776003)(76482001)(79102001)(42186004)(20776003)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR06MB620; H:[192.168.11.2]; FPR:A1C2C99C.8A376422.ED6EB37A.C4E58649.20118; MLV:nov; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: simgroep.nl does not designate permitted sender hosts) X-OriginatorOrg: simgroep.nl X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:32:57 -0000 Hi, Recently, I noticed a vulnerability in the gnutls package: gnutls-2.12.23_3 multiple certificate verification issues Shown here: http://portaudit.freebsd.org/f645aa90-a3e8-11e3-a422-3c970e169bc2.html Now, however, this vulnerability message is not found after running "pkg audit gnutls-2.12.23_3" I do find 3 other vulnerabilities when running "pkg audit gnutls-2.12", but not the original one, that is still active at the given URL, though. This problem is experienced on FreeBSD 8, 9 and 10. Is there a known issue here? Regards, Paul van Erk From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 09:25:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C919F6E2 for ; Thu, 24 Apr 2014 09:25:08 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3ED211DBA for ; Thu, 24 Apr 2014 09:25:08 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s3O9P2AG063613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Thu, 24 Apr 2014 11:25:04 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <5358D86E.4060306@obluda.cz> Date: Thu, 24 Apr 2014 11:25:02 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> <20140424000744.GE15884@in-addr.com> <9330A007-63D2-4930-AB33-4EEE64AEF670@cederstrand.dk> In-Reply-To: <9330A007-63D2-4930-AB33-4EEE64AEF670@cederstrand.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:25:08 -0000 On 04/24/14 08:33, Erik Cederstrand: > we need some way of marking them as false positive or wontfix, so the effort isn't duplicated. Out of the 10.000 reports, a conservative guess is that at least 100 of them are real security issues > A year ago, I did a raid on reports about not checking the return value of setuid() and friends, which did uncover real issues. Well, about nine years ago I spent some time to analysis of warnings raised by compiler during 'buildworld' (see bin/71632 for example). Most of them has been false positives of course, but it has been possible to modify the code to avoid them in the future. Just few true issues has been discovered, of course. I created PR and proposed patch for most of them - both bugs and warnings that can be avoided. So many of those PR has left untouched for years. I considered that proactive approach is not welcomed so much. I'm not complaining in any way, it's about my feeling that I wasted my time with activity not considered useful. I fully understand that reviewing of tenths of patches take time and no fun nor honor is related to such kind of work. That is it. Yes, we need "wontfix" mark, or so. But before it, the cleanup of code needs to be recognized as something valuable and important. Heartbleed raised the dust, so we are speaking those issues now. But dust will settle again within few weeks. Reviewing of "just code cleanup" reports will become "not fun/not honor/time costly" task again. A kind of task with no priority. Please note that my skills in English are very limited. I'm not trying to attack the comitters nor anyone else in any way. People tends to have human characteristics (I'm not exception) and not funny tasks that can be delayed will be delayed. I'm just trying to explain why I feel that "we have no code analysis done yet" or "we need wontfix flag" is not most important question. I'm not trying to push anyone. Just asking. If we (volunteers with no commit right) will spend time (and money, may be) to do the analysis, will someone with commit rights take the job, despite it will be time costly task with little of honor, despite the Heartbleed dust will become settled ? Dan From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 09:32:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B684B945 for ; Thu, 24 Apr 2014 09:32:06 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 97E3A1FD0 for ; Thu, 24 Apr 2014 09:32:05 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 546AD3AE82 for ; Thu, 24 Apr 2014 02:31:56 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: Date: Thu, 24 Apr 2014 02:31:56 -0700 Message-ID: <22727.1398331916@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:32:06 -0000 In message Ben Laurie wrote: >So where are your patches to fix these issues? Moi? Sorry. I'm confused. Was there something (anything) in or amongst the comments I made have could have been construed or interpreted to indicate that I personally was able to devote time to bugfixing on these specific packages? And more to the point, didn't I explicitly note that the OpenBSD dudes are... according to published reports... already laboring away on a slimed down and reorganized version of OpenSSL? Why would I or anyone else want to spend (waste?) time hacking on this until those guys release a new, improved and altogether svelte new version? Regards, rfg From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 10:58:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 975D5258 for ; Thu, 24 Apr 2014 10:58:32 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55F7B1899 for ; Thu, 24 Apr 2014 10:58:32 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id cm18so2050827qab.18 for ; Thu, 24 Apr 2014 03:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RCKxP/eIvtxgUHAeGumCpuEYqIKo04GdJEQoyFTPI0Y=; b=biTutdC9mzbL18mq6CSt1ICQQi48OrlSzjsK832o7n3hHcmgMz9K9JKTNU7VVBsQ7b Cdnus/AeRiUB3qjeTA6+ZqocgA1J6QfqPtZrr/iWWeJH90Fd9rJWtniAPSQqXjdnJzx9 Zewjv/ICzhu/8G2DJJu6IDzl0QqiN0gwdBPEE3EOp9YOKj57z7Y38MtElKsP5H2UkK7F lSPt14cIwGuUTYcFKwYAOSNGKORzQ1ISzniQO+HhdVPKWdk8zYIuOIVw7s42X9OKA3sx cIStZVSvAYL4H3ibiQeW5I3QV5mp8RdR0cUKWWql98EZ54zVp/TPbznkEnw7q/hDULvi p6+A== MIME-Version: 1.0 X-Received: by 10.224.2.193 with SMTP id 1mr1390709qak.100.1398337111443; Thu, 24 Apr 2014 03:58:31 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Thu, 24 Apr 2014 03:58:31 -0700 (PDT) In-Reply-To: References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> Date: Thu, 24 Apr 2014 11:58:31 +0100 X-Google-Sender-Auth: mK7ZgJwbqSbLJnZcn_W8qwUO9mI Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: Charles Swiger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-security@freebsd.org security" , Erik Cederstrand X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 10:58:32 -0000 On 23 April 2014 20:14, Charles Swiger wrote: > Hi-- > > On Apr 23, 2014, at 3:06 AM, Erik Cederstrand = wrote: >> Den 23/04/2014 kl. 03.12 skrev Ronald F. Guilmette : > [ ... ] >>> I do imagine that the truth or falsehood of your assertion may depend >>> quite substantally on what one does or does not consider a "false >>> positive" in this context. >> >> Have a look at the ~10.000 reports at http://scan.freebsd.your.org/freeb= sd-head/ (unavailable ATM). Silly things are reported like missing return a= t the end of main() or not free()ing memory two lines before program exit. = There are nonsensical reports because the analyzer doesn't detect exit() in= a usage() function because usage() is defined in a separate compilation un= it, or this: > > Sure, static analysis isn't perfect and runs into false positives, some o= f which are truly harmless and some of which actually do indicate an area w= here refactoring the code in light of the warning would be an improvement. > > It's worth noting that even if you believe that (e.g.) the clang static a= nalyzer isn't properly doing liveness analysis and misjudging whether there= 's a dead assignment (writing to a variable which is never read), the clang= compiler will be using the same analysis when doing dead-code elimination = and common-subexpression elimination and such while optimizing. I think this is not true. I could be wrong, but I've actually worked on clang static analysis and I think it is an entirely separate system. Certainly there's no guarantee that a static analysis result will be reflected in the output of the compiler. >> int foo(int y, int z) { >> int x; >> if (y =3D=3D z) { >> x =3D 0; >> } else { >> if (y !=3D z) { >> x =3D 1; >> } >> } >> return x; >> } >> >> warning that x may be uninitialized. Fixing these require considerable e= ffort e.g. improving IPA and adding alpha-remaning support to the analyzer'= s constraint manager, or would result in unnecessary code churn in FreeBSD = just to work around the reports. > > Ah, that's a classic example. If you declared y and z as const, then I'd= agree that the compiler should be free to make assumptions that one of the= two if statements must be true. > > On the other hand, if you assume that the arguments are volatile and that= maybe another thread might update y or z on the stack between the time whe= n the first if test is evaluated and the second if, one realizes that the s= tatic analyzer might actually have a point. (Or you're on an SMP system an= d don't get sequential consistency / total-store ordering without memory ba= rriers....) > > Sure, your code might never intentionally try to mess with the stack, but= there's a long history of bugs like typing ~1030 characters at a password = prompt and blowing past a char passwd[1024] buffer that someone assumed wou= ld be more than enough. > > The most straightforward changes to this snippet would be either: > > int foo(int y, int z) { > int x; > if (y =3D=3D z) { > x =3D 0; > } else { > x =3D 1; > } > return x; > } > > ...or: > > int foo(int y, int z) { > int x =3D 0; > if (y !=3D z) { > x =3D 1; > } > return x; > } > > Not only are both of these shorter and they pass clang's static analyzer = without a warning, I'd argue that the second version is noticeably cleaner. > > Regards, > -- > -Chuck > > _______________________________________________ > 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" From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 11:07:14 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A9E74AE for ; Thu, 24 Apr 2014 11:07:14 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 438E81999 for ; Thu, 24 Apr 2014 11:07:13 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id AE3303AE36 for ; Thu, 24 Apr 2014 04:07:09 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> Date: Thu, 24 Apr 2014 04:07:09 -0700 Message-ID: <23494.1398337629@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:07:14 -0000 In message <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk>, Erik Cederstrand wrote: >Silly things are reported like missing return at the end of main() In the post that you are replying to, I took issue with two prior assertions made by Mark Andrews, specifically (1) that some clang static analysis warnings are "false positives" and (2) that elimination some of them was "impossible". Would you agree with me if I were to say that if in fact there is no return statement at the end of the main() function, then a warning which simply states that fact is not in any sense "false"? And if you would agree with me on that, would you also and likewise agree that such a warning in exactly such a context cannot and should not be considered, by any reasonable person to be a "false" postive? And secondly, continuing with this same example (i.e. of a missing return at the end of main) would you agree with me that elimination of a warning about that very specific and particular condition would not only be entirely "possible", but actually entirely straightforward? >or not free()ing memory two lines before program exit. Again, if a clang static analysis is generating a warning message saying that a chunk of malloc'd memory is not being free'd before program exit, and if in fact that memory is not being free'd before program exit, then how does such a message in any sense constitute a "false positive"? And also, in what sense, if any, might it be either "impossible"... or even particularly difficult for that matter... to eliminate exactly such a warning message in exactly such a context? Wouldn't simply adding a suitable call to free() make the warning go away? Assuming so, then what, exactly, is the problem? >There are nonsensical >reports because the analyzer doesn't detect exit() in a usage() function >because usage() is defined in a separate compilation unit, If there does not exist, at present, any mechanism (supported by the clang compiler) to accomodate this precise situation, then this is certainly something that would bear fixing (in that compiler). I know that GNU C has a special pragma (__noreturn__) which can be attached to external function declarations _precisely_ to deal with this exact sort of situa- tion, i.e. otherwise unhelpful and misleading results from static analysis that does not take into account that a given external function causes program exit: http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Attributes.html "This makes slightly better code. More importantly, it helps avoid spurious warnings of uninitialized variables." ^^^^^^^^^^^^^^^^^^^^^^^ >int foo(int y, int z) { > int x; > if (y == z) { > x = 0; > } else { > if (y != z) { > x = 1; > } > } > return x; >} > >warning that x may be uninitialized. Yes. That code will likely get exactly that warning from many C compilers. >Fixing these require considerable effort Sir, does not the following trivial and obvious single line modification to the above code eliminate the warning? And does it not do so *without* the need for ``considerable effort''? int x = -1; I thank you for providing me with the example above, and thus also this opportunity to so perfectly illustrate my fundamental point. My fundamental point is just this: I think that it is a real crying shame that implementors of compilers... in particular GCC and clang... have worked and striven and sweated so long and so hard to give developers such great and often quite helpful compile-time warnings... warnings which, if heeded, may often prevent serious bugs from making it out the door... only to find that many a developer simply refuses to pay any heed at all to the warnings because (a) not all of them indicate absolutely DIRE problems and because (b) eliminating the ones that don't is _perceived_ by many... wrongly in my opinion... to be ``too hard''. As the examples above illustrate, the claim that eliminating the non-helpful warnings is ``too hard'' cannot, I believe, be supported by the facts, and the (unfortunately widespread) perception that eliminating such warnings is ``too hard'' is actually... and not to put too fine a point on it... a product more of ignorance or laziness than it is a product of genuine difficulty in quieting the unhelpful diagnostics in question. (To me it is a little like going for a drive with your cranky eighty year old grandfather who, even when out on the freeway, refuses to engage the cruise control because (he claims) it is ``too hard'' to enable it. Actually, as most of us know, it really just ain't that bloody hard.) In short, neither the use of modern cruise control systems nor the elimination of the kinds of static compiler generated warnings we have been discussing is in fact very hard at all, and in both cases there are substantial benefits to be derived from making proper and full use of these modern tools. (Those benefits explain why the implementors of these things went to such a lot of time and bother to actually build these things.) >e.g. improving IPA and adding alpha-remaning support to the >analyzer's constraint manager, or would result in unnecessary code churn >in FreeBSD just to work around the reports. I'm sorry, you are apparently using some domain-specific terminology with which I am not familiar. What exactly is "IPA" and "alpha-remaning"? Do these have something do do with SSL? As regards to your claim relating to "unnecessary code churn", I'm not sure what I can offer, other than the observation that at some or many times during this month of April, 2014 I believe that there have existed many many many system administrators, throughout the world, who, I believe, rather seriously _do_ wish that the code of OpenSSL had been ``churned'' a bit more than it had been prior to this month. In other words I'm not 100% sure that the loaded term ``code churn'' carries quite the perjorative connotation that you had intended. Not in the present context anyway. If ``code churn'' causes bugs to be ``churned'' *out* of production code, then it is a Good Thing, not a Bad Thing. >My best guess is that at least 90% of the reports are either false >positives or really silly. As I've noted above, a warning that says that a function is missing a return statement when it is in fact missing a return statement is not in any sense a ``false positive''. It may be a TRUE positive that many programmers may, in their haste to ship something, prefer to ignore, but that is a judgement call which could be made in a different way by a different programmer. And more to the point, the programmer who does in fact wish to ignore that specific warning can trivially banish it from view, forever, simply by adding the requsite return statement... even if, due to actual run-time behavior, that added return statement will be essentially superfluous (at run-time). >Which doesn't mean that the reports are >useless, but a lot of time is wasted finding real bugs. I could be wrong, but I am sort-of thinking that perhaps that last part of what you said above didn't come out quite the way you had intended. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 11:10:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F9845C7 for ; Thu, 24 Apr 2014 11:10:45 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 638331A32 for ; Thu, 24 Apr 2014 11:10:45 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 02BA43ADFA for ; Thu, 24 Apr 2014 04:10:45 -0700 (PDT) From: "Ronald F. Guilmette" cc: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> Date: Thu, 24 Apr 2014 04:10:45 -0700 Message-ID: <23520.1398337845@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:10:45 -0000 In message <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk>, Erik Cederstrand wrote: >Have a look at the ~10.000 reports at http://scan.freebsd.your.org/freebsd-head/ Whatever that is supposed to be, or to show, it appears to be down at the moment. :-( Regards, rfg From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 11:59:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC6D1528 for ; Thu, 24 Apr 2014 11:59:52 +0000 (UTC) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADA8C1E59 for ; Thu, 24 Apr 2014 11:59:52 +0000 (UTC) Received: from [192.168.187.70] (unknown [87.54.33.251]) by csmtp3.one.com (Postfix) with ESMTPA id 62590400134FD for ; Thu, 24 Apr 2014 11:59:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Erik Cederstrand In-Reply-To: <23494.1398337629@server1.tristatelogic.com> Date: Thu, 24 Apr 2014 13:59:10 +0200 Cc: "freebsd-security@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> References: <23494.1398337629@server1.tristatelogic.com> X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:59:53 -0000 Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette = : >=20 > In the post that you are replying to, I took issue with two prior = assertions > made by Mark Andrews, specifically (1) that some clang static analysis > warnings are "false positives" and (2) that elimination some of them = was > "impossible". I really wish the reports were online again so we weren't discussing = hypothetical situations here. Ulrich? > Sir, does not the following trivial and obvious single line = modification > to the above code eliminate the warning? And does it not do so = *without* > the need for ``considerable effort''? >=20 > int x =3D -1; >=20 > I thank you for providing me with the example above, and thus also = this > opportunity to so perfectly illustrate my fundamental point. The example I gave is of course trivial to rewrite. It was the shortest = possible example I could think of to illustrate the situation. It was = condensed from a really convoluted if-else case which was not incorrect = but quite difficult to untangle. And yes, it's laudable to rewrite it = for the sake of readability, but it doesn't fix any security issues. > As the examples above illustrate, the claim that eliminating the = non-helpful > warnings is ``too hard'' cannot, I believe, be supported by the facts, = and > the (unfortunately widespread) perception that eliminating such = warnings is > ``too hard'' is actually... and not to put too fine a point on it... a > product more of ignorance or laziness than it is a product of genuine > difficulty in quieting the unhelpful diagnostics in question. As others have pointed out, 'too hard' can also mean 'too hard' to get = someone with commit access to actually commit the patch and accept the = risk of introducing new bugs. Case in point: I contributed this = one-liner patch for ZFS found by Clang Analyzer, adding the __noreturn__ = pragma you also mention: https://www.illumos.org/issues/3363. For 1,5 = years, I have been unable to get anyone from FreeBSD or Illumos to = commit it or even review it. My personal conclusion is that patches to = warnings have to fix more severe issues to get attention. Or in other = words, if the warning is a result of the compiler or analyzer being too = stupid, the response will more likely be "fix the analyzer", and = compiler warnings are more likely to be ignored. > I'm sorry, you are apparently using some domain-specific terminology = with > which I am not familiar. What exactly is "IPA" and "alpha-remaning"? = Do > these have something do do with SSL? Alpha renaming, or =CE=B1-conversion, is explained here: = http://en.wikipedia.org/wiki/Lambda_calculus IPA, or Inter-Procedural Analysis, is explained here: = http://llvm.org/docs/Lexicon.html Erik= From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 12:10:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FFEB9D6 for ; Thu, 24 Apr 2014 12:10:16 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD8810B7 for ; Thu, 24 Apr 2014 12:10:15 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 4FFD83AE6E for ; Thu, 24 Apr 2014 05:10:12 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> Date: Thu, 24 Apr 2014 05:10:12 -0700 Message-ID: <23889.1398341412@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:10:16 -0000 In message <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk>, Erik Cederstrand wrote: >I don't disagree with you, but rewriting 1000 if-else cases in single-threaded >userland programs just so the analyzer understands them is 1) tedious and 2) >bound to accidentally introduce at least 50 new bugs I feel compelled to point out that one could make the exact same two assertions about writing code _generally_, i.e. writing software AT ALL is (1) tedious and (2) bound to accidentally introduce at least 50 new bugs. I feel further compelled to point out that at least the first of those two assertions also applies, in my experience, to writing QUALITY code. That doesn't mean it shouldn't be done. And anyway, who said anything about userland? I personally would contend that if the folks writing kernel code are failing to eliminate compile time warnings, then that is also a travesty, and perhaps even moreso than in the case of userland code. Certainly, if a developer misses a bug because he failed to pay any attention to the flashing yellow lights, then that is likely to have far more serious ramifications if the code in question is within the kernel. >...since most real-life examples >are considerably more complicated than the minimal example I posted. If in fact, as you assert, ``most'' real-life examples of contexts and situations where it is tedious and/or difficult to eliminate non-useful compile-time warnings are ``complicated'' then I would guess that it would be easy for you to find just _one_ such ``real life'' difficult example and post it here. Please do. In my personal estimation no such alleged ``complicated'' real life examples actually exist. But I am more than willing to be proven wrong. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 17:49:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17D9C24C for ; Thu, 24 Apr 2014 17:49:23 +0000 (UTC) Received: from gproxy5-pub.mail.unifiedlayer.com (unknown [IPv6:2605:dc00:100:2::a5]) by mx1.freebsd.org (Postfix) with SMTP id CF84D1901 for ; Thu, 24 Apr 2014 17:49:22 +0000 (UTC) Received: (qmail 31027 invoked by uid 0); 24 Apr 2014 17:49:22 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 24 Apr 2014 17:49:22 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw2 with id ttpG1n01936DqkS01tpKsF; Thu, 24 Apr 2014 11:49:20 -0600 X-Authority-Analysis: v=2.1 cv=Q9RBveGa c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=hKNOJcEOAAAA:8 a=70qzlKQjAAAA:8 a=-BsvhE_w4F0sME6eUggA:9 a=CjuIK1q_8ugA:10 a=--HJk1m7dRcA:10 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=V0Hu/lpC9wlNtmW1szuFx/M7PjDBB4EOeEtrpiL3PC8=; b=Qm70CXGl6eRE/BfSLm1TiQ8rtZcBZg826LGgbQ39lvyXbjIAXaAxKOcOS4YfvzBkUuvIB1F6ly0MilgELfkwwmaTFnHyPVCjyzN6rXWihdDC+GhZ2/ndGmd6WEDLDaWM; Received: from [98.245.97.34] (port=60402 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WdNlt-00014Z-Mk for freebsd-security@freebsd.org; Thu, 24 Apr 2014 11:49:17 -0600 Date: Thu, 24 Apr 2014 11:49:14 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140424174914.GC3850@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <23494.1398337629@server1.tristatelogic.com> <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:49:23 -0000 On Thu, Apr 24, 2014 at 01:59:10PM +0200, Erik Cederstrand wrote: > Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette : > > > > Sir, does not the following trivial and obvious single line modification > > to the above code eliminate the warning? And does it not do so *without* > > the need for ``considerable effort''? > > > > int x = -1; > > > > I thank you for providing me with the example above, and thus also this > > opportunity to so perfectly illustrate my fundamental point. > > The example I gave is of course trivial to rewrite. It was the > shortest possible example I could think of to illustrate the > situation. It was condensed from a really convoluted if-else case > which was not incorrect but quite difficult to untangle. And yes, it's > laudable to rewrite it for the sake of readability, but it doesn't fix > any security issues. I'm generally of the opinion that, all else being equal, making your code readable is a way to find bugs you did not know existed. Even more amazingly, making your code readable fixes bugs that have not yet been written. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 18:11:47 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FA08824; Thu, 24 Apr 2014 18:11:47 +0000 (UTC) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B0BC1B9B; Thu, 24 Apr 2014 18:11:46 +0000 (UTC) MIME-version: 1.0 Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4J00J00RIO2400@local.mail-out.apple.com>; Thu, 24 Apr 2014 11:11:46 -0700 (PDT) Received: from relay2.apple.com ([17.128.113.67]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4J009E7RV6HDK1@local.mail-out.apple.com>; Thu, 24 Apr 2014 11:11:46 -0700 (PDT) X-AuditID: 11807143-f79f66d0000015d3-ba-535953e262d3 Received: from [17.149.225.103] (Unknown_Domain [17.149.225.103]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 46.79.05587.2E359535; Thu, 24 Apr 2014 11:11:46 -0700 (PDT) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Charles Swiger In-reply-to: Date: Thu, 24 Apr 2014 11:11:45 -0700 Message-id: References: <10999.1398215531@server1.tristatelogic.com> <50CA7E78-BB5E-4872-A272-B7374627EC12@cederstrand.dk> To: Ben Laurie , Erik Cederstrand X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUiOPVhuu6j4MhggzuTFCy+TZrBavH0rb1F z6YnbA7MHs3LF7N7zPg0nyWAKYrLJiU1J7MstUjfLoErY9WCDvaCyxUVE2c8Zm9g/J/SxcjJ ISFgInH26AZ2CFtM4sK99WxdjFwcQgL9TBJv2lezgCSYBRIkjizZCGRzcPAK6Els/yUHYgoL +Eg8OGIMYrIJqElMmMgDUswpECgxf1EzWDGLgKrEnv95EDO8JB49nsgIYvMKWElcOXaUBWLR I0aJP4samUESIkC9v/42M0NcIytx+txzlgmMfLOQ3DAL4QaIsLbEsoWvmUHCzAI6EpMXMqIK Q9gfzx9hWsDItopRoCg1J7HSSC+xoCAnVS85P3cTIyhEGwqddzAeW2Z1iFGAg1GJh3eCbGSw EGtiWXFl7iFGCQ5mJRHedbZAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryqYRHBQgLpiSWp2amp BalFMFkmDk6pBkbWS4oXPeoN/UMyGCTXtTveKc8o7P7Qlv1G5vZLV98pkV7RmyqOvblX6+u8 0GWy7VZNqefZvAky3bzMzwP/uj1ntVzZrJvfuGVyl+iWC8sevy/9qOeYu9C+e7Gy7a/kCecX 8LOecV5x6UnbuhbbJcurqjTXLdfc9mzhwZyMhbbB4aL2B4P+ayqxFGckGmoxFxUnAgBsvnmv TQIAAA== Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:11:47 -0000 Hi-- On Apr 24, 2014, at 3:58 AM, Ben Laurie wrote: [ ... ] >> It's worth noting that even if you believe that (e.g.) the clang static analyzer isn't properly doing liveness analysis and misjudging whether there's a dead assignment (writing to a variable which is never read), the clang compiler will be using the same analysis when doing dead-code elimination and common-subexpression elimination and such while optimizing. > > I think this is not true. I could be wrong, but I've actually worked > on clang static analysis and I think it is an entirely separate > system. Certainly there's no guarantee that a static analysis result > will be reflected in the output of the compiler. You appear to be disagreeing with something which was almost-- but not quite-- what I said. :-) scan-build invokes a wrapper called ccc-analyzer (for C code; c++-analyzer for C++), which they interpose around the compiler such as clang or even gcc. The docs are informative: --use-cc=[compiler path] scan-build analyzes a project by interposing a "fake compiler", which executes a real compiler for compilation and the static analyzer for analysis. Because of the current implementation of interposition, scan-build does not know what compiler your project normally uses. Instead, it simply overrides the CC environment variable, and guesses your default compiler. In the future, this interposition mechanism to be improved, but if you need scan-build to use a specific compiler for *compilation* then you can use this option to specify a path to that compiler. --use-analyzer [Xcode|path to clang] --use-analyzer=[Xcode|path to clang] scan-build uses the 'clang' executable relative to itself for static analysis. One can override this behavior with this option by using the 'clang' packaged with Xcode (on OS X) or from the PATH. ...and to pick a specific example from the end of the openssl-1.0.1g build+scan: ~/WorkAreas/llvm/tools/clang/tools/scan-build/ccc-analyzer -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o engine.o engine.c engine.c:114:3: warning: Value stored to 'l' is never read l += 2; /* ", " */ ^ ~ 1 warning generated. That's from clang. You can get the same output by invoking clang directly as: clang -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -Wall --analyze -c -o engine.o engine.c engine.c:114:3: warning: Value stored to 'l' is never read l += 2; /* ", " */ ^ ~ 1 warning generated. If you check the file, openssl-1.0.1g/apps/engine.c around line 114, you'll see it was quite right: static int append_buf(char **buf, const char *s, int *size, int step) { int l = strlen(s); if (*buf == NULL) { *size = step; *buf = OPENSSL_malloc(*size); if (*buf == NULL) return 0; **buf = '\0'; } if (**buf != '\0') l += 2; /* ", " */ if (strlen(*buf) + strlen(s) >= (unsigned int)*size) { *size += step; *buf = OPENSSL_realloc(*buf, *size); } if (*buf == NULL) return 0; if (**buf != '\0') BUF_strlcat(*buf, ", ", *size); BUF_strlcat(*buf, s, *size); return 1; } Ewww. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 20:49:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EC67C6E for ; Thu, 24 Apr 2014 20:49:31 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id E3FA81C4A for ; Thu, 24 Apr 2014 20:49:30 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id A94543ADFA for ; Thu, 24 Apr 2014 13:49:24 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: Date: Thu, 24 Apr 2014 13:49:24 -0700 Message-ID: <26111.1398372564@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 20:49:31 -0000 In message , Erik Cederstrand wrote: >As others have pointed out, 'too hard' can also mean 'too hard' to get >someone with commit access to actually commit the patch and accept the >risk of introducing new bugs. Case in point: I contributed this >one-liner patch for ZFS found by Clang Analyzer, adding the __noreturn__ >pragma you also mention: https://www.illumos.org/issues/3363. For 1,5 >years, I have been unable to get anyone from FreeBSD or Illumos to >commit it or even review it. Ah! OK. That is a different sort of problem entirely, and one for which I personally have no suggestion, nor any ready answer. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 06:55:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6839CD36; Fri, 25 Apr 2014 06:55:40 +0000 (UTC) Received: from acme.spoerlein.net (unknown [IPv6:2a02:2528:fa:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.spoerlein.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8B1D1673; Fri, 25 Apr 2014 06:55:39 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) by acme.spoerlein.net (8.14.8/8.14.7) with ESMTP id s3P6tSPK092035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Apr 2014 08:55:29 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Fri, 25 Apr 2014 08:55:28 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Erik Cederstrand , Li-Wen Hsu Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425065528.GE3620@acme.spoerlein.net> References: <23494.1398337629@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 25 Apr 2014 12:07:56 +0000 Cc: "freebsd-security@freebsd.org" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 06:55:40 -0000 +lwhsu Things are in motion to bring back the scan-build results on FreeBSD infrastructure, so that it doesn't disappear without notice, again. On Thu, 2014-04-24 at 13:57:13 +0200, Erik Cederstrand wrote: > Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette : > > > > In the post that you are replying to, I took issue with two prior assertions > > made by Mark Andrews, specifically (1) that some clang static analysis > > warnings are "false positives" and (2) that elimination some of them was > > "impossible". > > I really wish the reports were online again so we weren't discussing hypothetical situations here. Ulrich? > > > Sir, does not the following trivial and obvious single line modification > > to the above code eliminate the warning? And does it not do so *without* > > the need for ``considerable effort''? > > > > int x = -1; > > > > I thank you for providing me with the example above, and thus also this > > opportunity to so perfectly illustrate my fundamental point. > > The example I gave is of course trivial to rewrite. It was the shortest possible example I could think of to illustrate the situation. It was condensed from a really convoluted if-else case which was not incorrect but quite difficult to untangle. And yes, it's laudable to rewrite it for the sake of readability, but it doesn't fix any security issues. > > > As the examples above illustrate, the claim that eliminating the non-helpful > > warnings is ``too hard'' cannot, I believe, be supported by the facts, and > > the (unfortunately widespread) perception that eliminating such warnings is > > ``too hard'' is actually... and not to put too fine a point on it... a > > product more of ignorance or laziness than it is a product of genuine > > difficulty in quieting the unhelpful diagnostics in question. > > As others have pointed out, 'too hard' can also mean 'too hard' to get someone with commit access to actually commit the patch and accept the risk of introducing new bugs. Case in point: I contributed this one-liner patch for ZFS found by Clang Analyzer, adding the __noreturn__ pragma you also mention: https://www.illumos.org/issues/3363. For 1,5 years, I have been unable to get anyone from FreeBSD or Illumos to commit it or even review it. My personal conclusion is that patches to warnings have to fix more severe issues to get attention. Or in other words, if the warning is a result of the compiler or analyzer being too stupid, the response will more likely be "fix the analyzer", and compiler warnings are more likely to be ignored. > > > I'm sorry, you are apparently using some domain-specific terminology with > > which I am not familiar. What exactly is "IPA" and "alpha-remaning"? Do > > these have something do do with SSL? > > Alpha renaming, or Ī±-conversion, is explained here: http://en.wikipedia.org/wiki/Lambda_calculus > > IPA, or Inter-Procedural Analysis, is explained here: http://llvm.org/docs/Lexicon.html > > > Erik From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 12:24:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44C737DA for ; Fri, 25 Apr 2014 12:24:33 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 03BFB1BD1 for ; Fri, 25 Apr 2014 12:24:32 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5335D6B43; Fri, 25 Apr 2014 12:24:26 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 5A01930FDF; Fri, 25 Apr 2014 14:24:28 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Ronald F. Guilmette" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> Date: Fri, 25 Apr 2014 14:24:28 +0200 In-Reply-To: <20140423012206.GB8271@glaze.hydra> (Chad Perrin's message of "Tue, 22 Apr 2014 19:22:06 -0600") Message-ID: <86bnvpoav7.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:24:33 -0000 Chad Perrin writes: > Obviously, human judgment is an important part of the process of finding > and fixing bugs. If it wasn't, the last program we'd ever have to debug > would be the one that finds and fixes bugs. https://en.wikipedia.org/wiki/Halting_problem Oh, wait, is this one of those conversations where knowledge and facts are not welcome? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 12:27:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EBF394F for ; Fri, 25 Apr 2014 12:27:12 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBCF1C0D for ; Fri, 25 Apr 2014 12:27:12 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 66A4D6B5F; Fri, 25 Apr 2014 12:27:11 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 6AA3C30FE7; Fri, 25 Apr 2014 14:27:13 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Chad Perrin Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> Date: Fri, 25 Apr 2014 14:27:13 +0200 In-Reply-To: <86bnvpoav7.fsf@nine.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8r?= =?utf-8?Q?grav=22's?= message of "Fri, 25 Apr 2014 14:24:28 +0200") Message-ID: <867g6doaqm.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:27:12 -0000 Dag-Erling Sm=C3=B8rgrav writes: > Oh, wait, is this one of those conversations where knowledge and facts > are not welcome? Weird interaction of quoting and reply-to. Chad, this was aimed at Ronald and "hcoin", not you. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 13:52:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB6D7B40 for ; Fri, 25 Apr 2014 13:52:34 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 821671688 for ; Fri, 25 Apr 2014 13:52:34 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 248EEB80AA for ; Fri, 25 Apr 2014 08:52:28 -0500 (CDT) To: freebsd-security@freebsd.org Date: Fri, 25 Apr 2014 08:52:10 -0500 Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <23494.1398337629@server1.tristatelogic.com> <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> <20140424174914.GC3850@glaze.hydra> Message-ID: <535A688A.2040606@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Fri, 25 Apr 2014 08:52:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:52:34 -0000 On 04/24/2014 12:49 PM, Chad Perrin wrote: > On Thu, Apr 24, 2014 at 01:59:10PM +0200, Erik Cederstrand wrote: >> Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette : >>> Sir, does not the following trivial and obvious single line modification >>> to the above code eliminate the warning? And does it not do so *without* >>> the need for ``considerable effort''? >>> >>> int x = -1; >>> >>> I thank you for providing me with the example above, and thus also this >>> opportunity to so perfectly illustrate my fundamental point. >> The example I gave is of course trivial to rewrite. It was the >> shortest possible example I could think of to illustrate the >> situation. It was condensed from a really convoluted if-else case >> which was not incorrect but quite difficult to untangle. And yes, it's >> laudable to rewrite it for the sake of readability, but it doesn't fix >> any security issues. > I'm generally of the opinion that, all else being equal, making your > code readable is a way to find bugs you did not know existed. Even more > amazingly, making your code readable fixes bugs that have not yet been > written. > +1. As an exercise, writing a small but non-trivial program in machine 'assembly' language that has to deal with at least one interrupt drives Mr. Perrin's lesson home better than any number of lectures. Let's not kid ourselves though, the only 'assurance' anyone can give about the security of any non-trivial bit of programming is what they detect upon manual review, and by use of programs that detect problems (which today are not more than automating a subset of mostly syntax-related things we look for upon manual review). These are 'consensus security opinions' or 'somewhat justified true beliefs'. Until checking programs also encompass more semantics, until we can write a collection of what in logic would be called axioms (which when all true for a program /a fortior//i/ imply security) well..... it would be better to avoid having to eat future dishes of hot steaming crow by terming software security 'security arts', akin to 'medical arts'. Harry Coin From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 14:15:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 225596E5 for ; Fri, 25 Apr 2014 14:15:31 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D32181937 for ; Fri, 25 Apr 2014 14:15:30 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id i8so4102623qcq.3 for ; Fri, 25 Apr 2014 07:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8+EoBD9205ulXZK49RL1RxYODtnBVImLMKeXnwXNvZE=; b=DJ7H7Ewd3Rhmo2aYV4RAX6UnzxIJGVb+PGpGbe0ZRL5q5truI/2Ktbs3iSFHxsB41S UspcMrtLOOW4ZrbIcyWxG1Uvu+ech1yi5Rp3qroRMY6YtuQfYWTf243fVGP3tq0HhrzE 5hShE1Tr6h84TM6+M2svDEHAB3tdldfT8VJrRGt+Q54nGyJGTHv6IrfLZXtl1q4P7/9w /RcW0XBLosww7XSh1gGnEWB29UsrBl09mmz5ZPiwF+t5nBklp3z1ykZ2ALk0YA1+nRar vN7o7f9hCudo194SXBXpqqfGZyJVk2G85pvi2tmCK1hC0PAxRTqgw9G1pikwpKMyF/qa pXhw== MIME-Version: 1.0 X-Received: by 10.140.92.230 with SMTP id b93mr3588048qge.12.1398435329703; Fri, 25 Apr 2014 07:15:29 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Fri, 25 Apr 2014 07:15:29 -0700 (PDT) In-Reply-To: <86bnvpoav7.fsf@nine.des.no> References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> Date: Fri, 25 Apr 2014 15:15:29 +0100 X-Google-Sender-Auth: 03cw-YHg_ayZJbtQRhW9zHxr_0U Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-security@freebsd.org security" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:15:31 -0000 On 25 April 2014 13:24, Dag-Erling Sm=C3=B8rgrav wrote: > Chad Perrin writes: >> Obviously, human judgment is an important part of the process of finding >> and fixing bugs. If it wasn't, the last program we'd ever have to debug >> would be the one that finds and fixes bugs. > > https://en.wikipedia.org/wiki/Halting_problem > > Oh, wait, is this one of those conversations where knowledge and facts > are not welcome? Curious what the halting problem can tell us about finding/fixing bugs? From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 16:52:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C643CFE6 for ; Fri, 25 Apr 2014 16:52:15 +0000 (UTC) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by mx1.freebsd.org (Postfix) with SMTP id 8B32D1AE6 for ; Fri, 25 Apr 2014 16:52:15 +0000 (UTC) Received: (qmail 16492 invoked by uid 0); 25 Apr 2014 16:52:15 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 25 Apr 2014 16:52:14 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw4 with id uGs91n00c36DqkS01GsC0g; Fri, 25 Apr 2014 10:52:14 -0600 X-Authority-Analysis: v=2.1 cv=CpMsLBID c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=8nJEP1OIZ-IA:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=70qzlKQjAAAA:8 a=quWpSuQb2GV3a9MkUGoA:9 a=wPNLvfGTeEIA:10 a=0Twd46asWQUA:10 a=Djr-2Vxv6fIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=apotheon.net; s=default; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=f77bIiCCvrRNAi3LSJUgncI6/VZF4iC7uk4fLhn4jMA=; b=lf3qOjtm+eV//GYlH5w6kH1+s7/qH96uJAjQBOWZWFatBiSy0O6NYhQgWOAscAiGuyYwZ1FXEej0u1C7ETZvV+7OLzAwdyn5+9XEgidLhXgCeRtsZTCdCqHBruv9SUuw; Received: from [98.245.97.34] (port=60611 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WdjM9-0002Xc-Cy for freebsd-security@freebsd.org; Fri, 25 Apr 2014 10:52:09 -0600 Date: Fri, 25 Apr 2014 10:52:04 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425165204.GA8127@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> <867g6doaqm.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <867g6doaqm.fsf@nine.des.no> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:52:15 -0000 On Fri, Apr 25, 2014 at 02:27:13PM +0200, Dag-Erling Smųrgrav wrote: > Dag-Erling Smųrgrav writes: > > Oh, wait, is this one of those conversations where knowledge and facts > > are not welcome? > > Weird interaction of quoting and reply-to. Chad, this was aimed at > Ronald and "hcoin", not you. Thanks for clarifying that. For a moment there, I was actually confused. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 17:14:24 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC8A19D9; Fri, 25 Apr 2014 17:14:24 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4ED1D2F; Fri, 25 Apr 2014 17:14:24 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5936F6505; Fri, 25 Apr 2014 17:14:23 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 7BAC23112A; Fri, 25 Apr 2014 19:14:25 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ben Laurie Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> Date: Fri, 25 Apr 2014 19:14:25 +0200 In-Reply-To: (Ben Laurie's message of "Fri, 25 Apr 2014 15:15:29 +0100") Message-ID: <86zjj9mivi.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 security" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:14:24 -0000 Ben Laurie writes: > Dag-Erling Sm=C3=B8rgrav writes: > > https://en.wikipedia.org/wiki/Halting_problem > Curious what the halting problem can tell us about finding/fixing bugs? Some participants in this thread claim that there is no such thing as a false positive from a static analyzer. A corollary of the halting problem is that it is impossible to write a program capable to proving or disproving the correctness of all programs. Hence, static analysis must perforce produce both false positive and false negative results. The purpose of static analysis in a compiler is to identify possible optimizations; therefore it must be conservative, because a false negative may result in incorrect code; therefore it will produce many false positives. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 17:33:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0715DCB for ; Fri, 25 Apr 2014 17:33:44 +0000 (UTC) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by mx1.freebsd.org (Postfix) with SMTP id 8A0301084 for ; Fri, 25 Apr 2014 17:33:44 +0000 (UTC) Received: (qmail 14984 invoked by uid 0); 25 Apr 2014 17:33:43 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 25 Apr 2014 17:33:43 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by CMOut01 with id uHZc1n00C36DqkS01HZfdU; Fri, 25 Apr 2014 11:33:43 -0600 X-Authority-Analysis: v=2.1 cv=EOmVjTpC c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=8nJEP1OIZ-IA:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=6I5d2MoRAAAA:8 a=8pif782wAAAA:8 a=70qzlKQjAAAA:8 a=1G-YfAeunkake7ZTHKgA:9 a=nGmemLi6sPGI8RlX:21 a=0Uqwa3fj9EtE_n6K:21 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=apotheon.net; s=default; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=kIn6dPSI4g1o46ZDQtu/a25jY4Y+7qMIzVoB1392PdY=; b=MFYtz59PQhT1Yr76sUhV/qpGIKLolOXF/Fk4MOkSYtPqoL+F9a9TgSCmOUMLrKGYdNmXyPtOEh4Hjbw8hiLvKA2uTA0J/d3iM6pot2a7TvFd2LHz9zTtRCTBAGibWH+q; Received: from [98.245.97.34] (port=62459 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Wdk0G-0008Px-2i for freebsd-security@freebsd.org; Fri, 25 Apr 2014 11:33:36 -0600 Date: Fri, 25 Apr 2014 11:33:31 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425173331.GA8393@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> <86zjj9mivi.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86zjj9mivi.fsf@nine.des.no> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:33:44 -0000 On Fri, Apr 25, 2014 at 07:14:25PM +0200, Dag-Erling Smųrgrav wrote: > Ben Laurie writes: > > Dag-Erling Smųrgrav writes: > > > https://en.wikipedia.org/wiki/Halting_problem > > Curious what the halting problem can tell us about finding/fixing bugs? > > Some participants in this thread claim that there is no such thing as a > false positive from a static analyzer. I'm not sure that's true. I think the claims are much more conservative than that. Specifically, I think it has been claimed that many of the kinds of reports you regard as false positives were disputed, thus suggesting that the rate of false positives is substantially *lower* than you claim -- not that it is *zero*. > > A corollary of the halting problem is that it is impossible to write a > program capable to proving or disproving the correctness of all > programs. Hence, static analysis must perforce produce both false > positive and false negative results. The purpose of static analysis > in a compiler is to identify possible optimizations; therefore it must > be conservative, because a false negative may result in incorrect > code; therefore it will produce many false positives. I am not sure this statement, as you have composed it, has much truth in it either. Yes, it seems to be the case that a program cannot be proven correct for some definition of "correct". This does not necessarily mean that an analyzer cannot yield zero false positives. If it produces false negatives, but no false positives, it has still not proven the program correct. Now . . . it may be that it is "impossible" for an analyzer to fail to report false positives, at least sometimes, but your reasoning in the above quoted paragraph does not adequately make that case. In addition to that, nothing about it being incapable of avoiding all false positives implies that it must report "many" false positives. I am inclined to agree that Clang's static analyzer, given the examples provided in this discussion, *technically* produces fewer false positives than you suggest, though it may produce many false "problems" according to what you consider a problem for your projects. I suppose you might reasonably disagree with me if your definition of what constitutes a "positive" differs from mine, but that does not make my opinion wrong -- only different from yours. On the other hand, I am not sure what your definition of a technical true positive would be, as I think I have only seen you refer to cases where you do not consider a given positive (false or true) to be a "real problem". We have now descended into the realm of arguing about how we argue about what we wish to argue, which I suspect will never naturally swing back into the realm of productive discussion. I apologize for my part in that. I will just add this, though: I consider warnings that essentially consist of indications that I have used ambiguous or otherwise poor coding style to be quite useful in ensuring I write maintainable code. Even if the most dire problems are not addressed by the output of the static analyzer, its output can help me clean up my code to make it more readable and maintainable, and this might in turn help me find where more dire problems lurk in the dusty corners of my code. I consider that a win, and as such I appreciate the benefits of Clang's static analyzer as a tool that, coupled with human judgment (flawed though it may be), can help me write cleaner, more maintainable, less buggy, and safer code. Your mileage may vary. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 17:45:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0E211C9 for ; Fri, 25 Apr 2014 17:45:39 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6E7E11A4 for ; Fri, 25 Apr 2014 17:45:39 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id f51so4288319qge.40 for ; Fri, 25 Apr 2014 10:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Lnw/bcOq6JMQkmUDUefJP8b27jHSEIcGS4wcwiRsF3g=; b=CNTuPezjmz8XPdAfF0tqfzayPx9Qpol4NtuCx+kl7e9rTi/6yfQQul/Z9zmsIjdK6X dniaelsh/bQFiyV8NB866dTybqIyLguelgqfddAdV94r/737zpHKSRhzsR1mGEAg6z+U 4M5ySKuJu3fRAIxYsd8WUwubtzDKGKEdBhek8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Lnw/bcOq6JMQkmUDUefJP8b27jHSEIcGS4wcwiRsF3g=; b=Ke4fhid94TZwapnczxztbqTykQbiBnVyTF2uyXPg86WgdmiXbyKScKuQF+cjtvs4yt IXaq8iqAtRnVpW2RF2aRnHMRmz98S48pq8hiHAev60SOLoLF/dBEHKgXRBKbs3o2fLv0 OOBH1eNNPOWfCMSaEaXe9B3FRsG1EFjJra9F00Kfn56SbLsgmgwwRPLxGnoZ3PMpeTsJ v2Qx0+9Pw7hWPoy5qQtHZWgWrZqCi1+T6Z+ebR+X8F+TuH/49FC/mxDyrGmI6NQ4uet7 5XhQQoRUYACRkpc8PEbdANxMdciYFxSsEn+iUxjqc/7O5MvDcuRZFG+aAZ7EIJT0Llm0 jWug== X-Gm-Message-State: ALoCoQn9/3JSqtEGmcTW6ePBILwfrL8ZTaQTB1IeN1fGsU5MiVzVki4ftijwiwxaJzxCAIdr94kE X-Received: by 10.224.67.131 with SMTP id r3mr13644458qai.75.1398447938109; Fri, 25 Apr 2014 10:45:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.54.102 with HTTP; Fri, 25 Apr 2014 10:45:08 -0700 (PDT) In-Reply-To: <86zjj9mivi.fsf@nine.des.no> References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> <86zjj9mivi.fsf@nine.des.no> From: Eitan Adler Date: Fri, 25 Apr 2014 10:45:08 -0700 Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ben Laurie , "freebsd-security@freebsd.org security" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:45:40 -0000 On 25 April 2014 10:14, Dag-Erling Sm=C3=B8rgrav wrote: > Ben Laurie writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > https://en.wikipedia.org/wiki/Halting_problem >> Curious what the halting problem can tell us about finding/fixing bugs? > > Some participants in this thread claim that there is no such thing as a > false positive from a static analyzer. A corollary of the halting > problem is that it is impossible to write a program capable to proving > or disproving the correctness of all programs. Modern computers can be considered linear bounded automatons , not turing machines, so the halting problem can be solved on them > Hence, static analysis > must perforce produce both false positive and false negative results. This doesn't follow from the halting problem: for instance static analysis of the form "return nothing" produces no false positives. Modern static analysis are not both sound and complete. In general implementers have leaned towards soundness over completeness. > The purpose of static analysis in a compiler is to identify possible > optimizations; therefore it must be conservative, because a false > negative may result in incorrect code; therefore it will produce many > false positives. the clang analyzer operates under a different set of constraints and end user vision than a typical compiler. --=20 Eitan Adler From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 17:51:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2312051C for ; Fri, 25 Apr 2014 17:51:11 +0000 (UTC) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by mx1.freebsd.org (Postfix) with SMTP id DA35C128A for ; Fri, 25 Apr 2014 17:51:10 +0000 (UTC) Received: (qmail 21874 invoked by uid 0); 25 Apr 2014 17:51:04 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 25 Apr 2014 17:51:04 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by CMOut01 with id uHr11n00d36DqkS01Hr4EU; Fri, 25 Apr 2014 11:51:04 -0600 X-Authority-Analysis: v=2.1 cv=EOmVjTpC c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=8nJEP1OIZ-IA:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=6I5d2MoRAAAA:8 a=8pif782wAAAA:8 a=70qzlKQjAAAA:8 a=soYWCMwtBPLKuhagTP0A:9 a=jxO62lszJgyWr7kT:21 a=_ND47J_5DQQ_gorl:21 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=apotheon.net; s=default; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=zJzNxRXvlxIq4nIn8VumcrjOIF5bmtR8CTtHVKh/H1M=; b=ewBil9iZWtzdrFxqzMOvArheSVcxVcIhUriIjUJD2ACT+7YLAq0hlGjM2cluy0z6BNWsqsmDBH5liYblOy1Thw97+cTCNGIIt/FTOEKhw7ZY7FqvoI78nPcJY/UaYRjo; Received: from [98.245.97.34] (port=62857 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WdkH7-0004DA-EF for freebsd-security@freebsd.org; Fri, 25 Apr 2014 11:51:01 -0600 Date: Fri, 25 Apr 2014 11:50:56 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425175056.GA8508@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> <86zjj9mivi.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86zjj9mivi.fsf@nine.des.no> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:51:11 -0000 On Fri, Apr 25, 2014 at 07:14:25PM +0200, Dag-Erling Smųrgrav wrote: > Ben Laurie writes: > > Dag-Erling Smųrgrav writes: > > > https://en.wikipedia.org/wiki/Halting_problem > > Curious what the halting problem can tell us about finding/fixing bugs? > > Some participants in this thread claim that there is no such thing as a > false positive from a static analyzer. A corollary of the halting > problem is that it is impossible to write a program capable to proving > or disproving the correctness of all programs. Hence, static analysis > must perforce produce both false positive and false negative results. > The purpose of static analysis in a compiler is to identify possible > optimizations; therefore it must be conservative, because a false > negative may result in incorrect code; therefore it will produce many > false positives. While I'm letting myself get embroiled in this, I have a question: Do you claim that the Clang static analyzer is essentially worthless for finding and fixing security-related bugs because it is more trouble to make use of its output than its output is worth, or does it only *seem* like that is your claim? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 17:59:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E22B6717; Fri, 25 Apr 2014 17:59:21 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id ABB791303; Fri, 25 Apr 2014 17:59:21 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from discipline.rdnzl.info (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N4L00LF5LYN2G70@st11p09mm-asmtp001.mac.com>; Fri, 25 Apr 2014 17:59:15 +0000 (GMT) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Kimmo Paasiala In-reply-to: Date: Fri, 25 Apr 2014 20:59:09 +0300 Content-transfer-encoding: quoted-printable Message-id: <1705A4DB-6413-442E-8850-E629EC1702F2@icloud.com> References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> To: Ben Laurie X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaEhEKTEMXGx0EGx0YBBIZBBsSEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsbGmJCH2lmHlxCGXhzB xl6Gx0fE29+EQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxIQGx4aHxsRCl5ZF2FBb0l kEQpMRhdsa2sRCkNaFxISBBsTHwQbGBIEGRkRCkJeFxsRCkRYFx4RCkRJFx4RCkJFF2Z9fxNNb 1xgZRoSEQpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQp CQBdtZGRPRhIYZlwYTxEKcGcXbFAcemgbG2hDZmQRCnBoF2Jse29/GVBlR2cdEQpwaBdjbl8fU GdhY3wTQxEKcGgXbVlmHUBwWmcaTh4RCnBoF29OQ0ZOZkFyZ3NiEQpwaBdtBQVjWF1QGWl4SxE KcH8Xbm5oGhMdQ2AfXW0RCnBfF3pgHElhGxlcYF1lEQpwbBdtZ24FH2FOYRxbGxEKcEwXYVlhY UZwSVJbfWwR X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-25_05:2014-04-25,2014-04-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=35 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404250277 Cc: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= , "Ronald F. Guilmette" , "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 17:59:22 -0000 On 25.4.2014, at 17.15, Ben Laurie wrote: > On 25 April 2014 13:24, Dag-Erling Sm=F8rgrav wrote: >> Chad Perrin writes: >>> Obviously, human judgment is an important part of the process of = finding >>> and fixing bugs. If it wasn't, the last program we'd ever have to = debug >>> would be the one that finds and fixes bugs. >>=20 >> https://en.wikipedia.org/wiki/Halting_problem >>=20 >> Oh, wait, is this one of those conversations where knowledge and = facts >> are not welcome? >=20 > Curious what the halting problem can tell us about finding/fixing = bugs? >=20 It and its direct implications mean that it=92s provably impossible to = write a program X that would take another program A as its input and be = able to decide with 100% certainty whether this other program A has a = certain property or not. In the actual halting problem the property is =93The program runs to = completion and produces a result with every possible input=94. A classic = real world example is when property is set to =93The program A is/has a = virus=94. The halting problem applies to this discussion very naturally = if you use the property =93The program A has a buffer overflow = vulnerability=94 or =93The program A uses memory that has already been = free()=92d=94. None of these properties (or any other similar property) = can be detected programmatically with 100% certainty, that is what the = halting problem tells you about finding bugs. In essence all this is saying that is foolish to claim that an automated = code analyzer could find all bugs in a given piece of code, outside some = very trivial programs it is just not going to happen. =20 -Kimmo From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 18:02:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09B6786D for ; Fri, 25 Apr 2014 18:02:28 +0000 (UTC) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by mx1.freebsd.org (Postfix) with SMTP id C82F213AF for ; Fri, 25 Apr 2014 18:02:27 +0000 (UTC) Received: (qmail 29552 invoked by uid 0); 25 Apr 2014 18:02:27 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 25 Apr 2014 18:02:27 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw3 with id uJ2P1n00A36DqkS01J2S9k; Fri, 25 Apr 2014 12:02:27 -0600 X-Authority-Analysis: v=2.1 cv=XPOjF2RE c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=CJn5o44HT8MA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=70qzlKQjAAAA:8 a=mT0hdOR4Eu6LQJxTT4EA:9 a=CjuIK1q_8ugA:10 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=1JgLWYJ8+FFvqeWw9VqOGTlCtHckFQK00hRBZsxXAiw=; b=usguJFlXKERIHg147Vf9kebahQHrqR9U4oNK53UfQnoFxkV5igXg1zqDBHi/zpxCkOqhcglvSFd3+Cw/oYeZPJIx0IyOPhc9e1vrX/JlIY+eThugMC66d5M61iQN+aZB; Received: from [98.245.97.34] (port=62989 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WdkS6-0002TF-D4 for freebsd-security@freebsd.org; Fri, 25 Apr 2014 12:02:22 -0600 Date: Fri, 25 Apr 2014 12:02:17 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] Message-ID: <20140425180217.GC8508@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <20140414144155.C55844@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:02:28 -0000 On Mon, Apr 14, 2014 at 12:36:28AM -0500, David Noel wrote: > > Indeed it is not. David's solution - which seems to amount to removing > > portsnap and herding the cats at home to DTRT about using svn securely - > > relies on other cats being as smart and aware of the ramifications as he > > is - a highly questionable proposition especially for the numerous more > > naive users that portsnap renders the process of securely upgrading the > > ports tree just about as simple and consistent as it can be. > > On the one hand I do get what you're saying. On the other I don't know > that you're fairly characterizing the typical portsnap user. Building > ports from source is not something I would think a novice FreeBSD user > would do (make can be--and often is--an absolute nightmare!). Rather, > I would imagine a novice would be using something like pkgng. When I was a novice FreeBSD user, lo these many many moons ago when the world was young and neckbearded Unix gods roamed the earth, I installed from source using the ports system. > > > > David, perhaps your obvious talent for auditing the portsnap code and > > its server-side configuration might be better applied to remedying any > > perceived vulnerabilities in conjunction with present and past security > > officers and teams? > > Thanks. I'm happy to, and it's on my to-do list, the only problem is > that I'm swamped with other projects and it's been sitting on that > list for the past 2 years. It seems to be a similar problem for Colin > and the Security Team. I'm hoping that by bringing this bug to the > list that someone with more free time will be able to patch it. Would you be willing to put the time into training up someone to do that work? I'm a bit of a fixer-upper, but I am willing and eager to contribute. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 18:16:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C03F8DAD for ; Fri, 25 Apr 2014 18:16:49 +0000 (UTC) Received: from gate2.quietfountain.com (gate2.quietfountain.com [97.64.213.195]) by mx1.freebsd.org (Postfix) with ESMTP id 95E65153C for ; Fri, 25 Apr 2014 18:16:49 +0000 (UTC) Received: from ops1.quietfountain.com (ops1.quietfountain.com [192.168.29.13]) by gate2.quietfountain.com (Postfix) with ESMTP id 44FB2B8237 for ; Fri, 25 Apr 2014 13:16:48 -0500 (CDT) To: freebsd-security@freebsd.org Date: Fri, 25 Apr 2014 13:16:41 -0500 Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> <86zjj9mivi.fsf@nine.des.no> Message-ID: <535AA689.8000302@quietfountain.com> From: "hcoin" Received: from [192.168.29.127] (gate1.quietfountain.com [192.168.29.2]) by ops1.quietfountain.com; Fri, 25 Apr 2014 13:16:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 18:16:49 -0000 On 04/25/2014 12:14 PM, Dag-Erling SmĆørgrav wrote: > Ben Laurie writes: >> Dag-Erling SmĆørgrav writes: >>> https://en.wikipedia.org/wiki/Halting_problem >> Curious what the halting problem can tell us about finding/fixing bugs? > Some participants in this thread claim that there is no such thing as a > false positive from a static analyzer. A corollary of the halting > problem is that it is impossible to write a program capable to proving > or disproving the correctness of all programs. All current analyzers are a packaged up collection of correctness intuitions operating on the borders of language syntax and information semantics. If they deliver 'false positives' it is because we don't know how to capture in software the semantics necessary to justify 'not reporting' false positives. If they deliver 'false negatives' it's because either a syntax/grammar only routine can't reach the semantics necessary to detect the problem, we don't know how to capture the semantics in checking routines, or one got by the grammar checkers. And apropos yours above of 'halting problem': 'Halting' has a defined and objectively testable meaning, while 'correct' and 'secure' do not. Hence the corollary you mention is in the manner of professional intuition (and likely correct in our lifetimes), but not the usual meaning of corollary. And in any event the unhappy outcome you mention in 'the halting problem' exists if and only when presupposing infinite program memory, infinite processing time and by implication infinite machine life. It should be possible to write a set of rules that, when taken together define 'secure', inasmuch as 'secure' can be equivalent to whether only allowed information of known finite size running on a known finite computer crosses an interface or edge of a specific program. But first a great deal more has do be done in defining basics, for example if a hashing routine confirms no-match against a stored hashed password, that's leaking information in a mathematical sense because you now know one password isn't it given the password space is finite (if big), but is that routine 'insecure' or 'secure'? 'Correct' on the other hand, that term is much like valor (in the eye of the beholder). One might argue it is a per-program specification and as such more a restatement of the program itself in an as-yet-to-be-written specification language, which itself needs it's own correctness specification in an as-yet-as-yet-to-be-written specification-specification language, and so forth until we get to the eye of the beholder anyhow, or lunch with Kurt Godel. I don't mean to be argumentative, I just want to urge caution in using metaphors from math without consistent application of either hard or soft focus on the rigor. Harry Coin From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 20:24:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9BAB577 for ; Fri, 25 Apr 2014 20:24:55 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id A561512B8 for ; Fri, 25 Apr 2014 20:24:55 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0BD7F3AE82 for ; Fri, 25 Apr 2014 13:24:44 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security\@freebsd.org security" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <86zjj9mivi.fsf@nine.des.no> Date: Fri, 25 Apr 2014 13:24:44 -0700 Message-ID: <32060.1398457484@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:24:55 -0000 In message <86zjj9mivi.fsf@nine.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: >Ben Laurie writes: >> Dag-Erling Sm=C3=B8rgrav writes: >> > https://en.wikipedia.org/wiki/Halting_problem >> Curious what the halting problem can tell us about finding/fixing bugs? > >Some participants in this thread claim that there is no such thing as a >false positive from a static analyzer. I suppose that you might possibly be referring to me. Assuming so, I would respond as follows... Sir, I believe that you may have misconstrued my comments. I'll should probably go back now and look at exactly what I may have said, and try to find how that could have been interpreted in this way, however I do know that I did attempt to make the point that (for example) a warning saying that there is no return statement at the end of a function when in fact there is no return statement at the end of said function is not in any sense a "false positive". I still stand by that assertion, which I believe is self-evident. Separately, a code example of the following general form was discussed: if (condition) variable = value1; if (!condition) variable = value2; use (variable); It was noted that code of this form can generate a "false positive" warning, from some or many code analyzers, to the effect that "variable" may be used while in an "uninitialized" state. I agree entirely that, given code of the above form, the variable will never in fact be used while in an uninitialized state, and that thus, any such warning is rather unambiguously "false". I don't believe that I suggested otherwise. I did however note that the warning in such cases may be trivially quieted by the addition of an (unconditional) initialization of "variable" somewhere prior to the code in question. I did that in response to an assertion that eliminating such a warning might be in some sense "too hard", even though the party or parties to which such an assertion might apply was not specified. >A corollary of the halting problem... Although this interesting digression may have something to do with either comments that were made, by someone, or to your interpretation of comments that may have been made, by either me or someone else, I am not persuaded that it has anything at all to do with the two specific (and self-evident?) points that I made earlier, and that I have just reiterated again above. Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 20:38:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFA527F9 for ; Fri, 25 Apr 2014 20:38:27 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7125213AC for ; Fri, 25 Apr 2014 20:38:27 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id e89so4658322qgf.34 for ; Fri, 25 Apr 2014 13:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oRUYUs0+hjRfE37FKEEkZI73ZpPNGtZ0HikAspxIwmc=; b=r202QcqWzdRDiK2wYRa6CpBvzV4/s3kXxhAVX6qPT1KTJMlq+QigIBrJJRr4+AW9aC 0WZf9kCmNUjnD+VMBrrobwTmKv4WwMM9UCrfZ0+xeZh4qTBnqF+oFReifKcsOLrUt6aq BUgJw7VZh6vC93i/7hbSbQ3BwGaCBNg+eGLtPvR8WiR/iytHY+EM/2uMn0H4BalV0JNK D5ZH0yGc0/aghuzivdKIpTV+jpV+pVsEtAStxIqWCIyBJXrDU/HAaSIJD2kL2EnKxtvs vROPUIN0wl8GjhZAlvM4qpSHp27E3td7y6rbA+kRooFI0t1YfnkKRV22XjkrkI93ZivC jDvg== MIME-Version: 1.0 X-Received: by 10.140.92.230 with SMTP id b93mr6483605qge.12.1398458306541; Fri, 25 Apr 2014 13:38:26 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Fri, 25 Apr 2014 13:38:26 -0700 (PDT) In-Reply-To: <32060.1398457484@server1.tristatelogic.com> References: <86zjj9mivi.fsf@nine.des.no> <32060.1398457484@server1.tristatelogic.com> Date: Fri, 25 Apr 2014 21:38:26 +0100 X-Google-Sender-Auth: tMlMGo177l-d1hTxZUlkpYgKR94 Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:38:27 -0000 On 25 April 2014 21:24, Ronald F. Guilmette wrote: > Separately, a code example of the following general form was discussed: > > if (condition) variable = value1; > if (!condition) variable = value2; > use (variable); > > It was noted that code of this form can generate a "false positive" > warning, from some or many code analyzers, to the effect that "variable" > may be used while in an "uninitialized" state. I agree entirely that, > given code of the above form, the variable will never in fact be used > while in an uninitialized state, and that thus, any such warning is > rather unambiguously "false". I don't believe that I suggested > otherwise. I did however note that the warning in such cases may be > trivially quieted by the addition of an (unconditional) initialization > of "variable" somewhere prior to the code in question. But that would then hide the error condition of it being not set to a new value after initialisation. One better answer would be to have a way to annotate that after the two conditionals you assert that |variable| is initialised. Then a future, smarter static analyzer can attempt to prove you wrong. > I did that in > response to an assertion that eliminating such a warning might be in > some sense "too hard", even though the party or parties to which such > an assertion might apply was not specified. From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 20:46:46 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAC79CAB; Fri, 25 Apr 2014 20:46:46 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7E59614ED; Fri, 25 Apr 2014 20:46:46 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 433841598; Fri, 25 Apr 2014 20:46:40 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.8/8.14.8) with ESMTP id s3PKkbRL036501; Fri, 25 Apr 2014 20:46:37 GMT (envelope-from phk@phk.freebsd.dk) To: Ben Laurie Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-reply-to: From: "Poul-Henning Kamp" References: <86zjj9mivi.fsf@nine.des.no> <32060.1398457484@server1.tristatelogic.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 25 Apr 2014 20:46:37 +0000 Message-ID: <36500.1398458797@critter.freebsd.dk> Cc: "freebsd-security@freebsd.org security" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:46:46 -0000 In message , Ben Laurie writes: >On 25 April 2014 21:24, Ronald F. Guilmette wrote: >> Separately, a code example of the following general form was discussed: >> >> if (condition) variable = value1; >> if (!condition) variable = value2; >> use (variable); >> >One better answer would be to have a way to annotate that after the >two conditionals you assert that |variable| is initialised. Then a >future, smarter static analyzer can attempt to prove you wrong. The way you do that *IS* to assert that the variable is indeed set to something you can use. If your "security" source code does not have at least 10% assert lines, you're not really serious about security. And of course, if you compile the asserts out for "production" you are downright moronic about security :-) -- 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 Fri Apr 25 20:47:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66BDED9F for ; Fri, 25 Apr 2014 20:47:34 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 450F6150E for ; Fri, 25 Apr 2014 20:47:33 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 8D2B53ADFA for ; Fri, 25 Apr 2014 13:47:33 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <20140424000744.GE15884@in-addr.com> Date: Fri, 25 Apr 2014 13:47:33 -0700 Message-ID: <32215.1398458853@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:47:34 -0000 In message <20140424000744.GE15884@in-addr.com>, Gary Palmer wrote: >Compiler warnings and static code analysis are a small part of a secure >programming mentality/methodology, and in and of themselves are fairly >useless. I doubt either would have caught Heartbleed. I just wanted to say that although I'm quote obviously a proponent of making full use of any and every tool that can generate, at compile time, errors or warnings which may prove useful for improving the quality of code, and while I thus would take issue with Gary Palmer's characteri- zation of such tools as "useless", I do have to concede that he's right that it is either highly unlikely or perhaps even outright impossible that any such tools could have properly diagnosed the specific flaw that led to Heartbleed. Having looked into Heartbleed a little myself... but not too deeply... I would say that the only thing that might possibly have prevented Heartbleed from arising would have been if the entire code base of OpenSSL would have been engineered from the beginning to be rather entirely more object oriented than it is. However even that might well not have prevented this specific bug. (And please note that selecting C as the implementation language most certainly _does not_ preclude object orientation in the code.) Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 20:52:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AD90EC1 for ; Fri, 25 Apr 2014 20:52:27 +0000 (UTC) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE79A15CF for ; Fri, 25 Apr 2014 20:52:26 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id m5so2908107qaj.39 for ; Fri, 25 Apr 2014 13:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sH6Bg5oME7DEEtsCmkNFgevaCPQQyqhIQ4Z0+qQOWXE=; b=xY3PxNgkiU3K7MWFiDS1xw6Ex9DR1ts8eTn47BxQ8iNyx3w8PxLu/PUQqdkmJwrMSI bis4az4rnbuRO/VPk4V2YRK+PoaDTSY8QT8fHgqNWDpYYmXJ7gDaTEycdeDwr5MU3qOr uHib9yr6E/cNDV/SjTIKXzg7iUPGCb46frOFAqNwDOcmDrWsTl1obGmXHX+q8Z26LefC uKfBff67S9eNEwrq+CgneXu1jX7bwz01Wasx9RLGr8+FZR3ykqdrwhlSpatfw0IsLbFB IDOIZyqIEDazqNzaGBcBm1ql5ehUPE2Myay+Za2kjG2SBAZYO33ySkVA/EgGa95Hjb46 ertw== MIME-Version: 1.0 X-Received: by 10.224.160.142 with SMTP id n14mr15142176qax.17.1398459145876; Fri, 25 Apr 2014 13:52:25 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Fri, 25 Apr 2014 13:52:25 -0700 (PDT) In-Reply-To: <36500.1398458797@critter.freebsd.dk> References: <86zjj9mivi.fsf@nine.des.no> <32060.1398457484@server1.tristatelogic.com> <36500.1398458797@critter.freebsd.dk> Date: Fri, 25 Apr 2014 21:52:25 +0100 X-Google-Sender-Auth: C6LzNYgob4aaXfs8D8oe3d_0TDY Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org security" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:52:27 -0000 On 25 April 2014 21:46, Poul-Henning Kamp wrote: > In message > , Ben Laurie writes: >>On 25 April 2014 21:24, Ronald F. Guilmette wrote: >>> Separately, a code example of the following general form was discussed: >>> >>> if (condition) variable = value1; >>> if (!condition) variable = value2; >>> use (variable); >>> > >>One better answer would be to have a way to annotate that after the >>two conditionals you assert that |variable| is initialised. Then a >>future, smarter static analyzer can attempt to prove you wrong. > > The way you do that *IS* to assert that the variable is indeed > set to something you can use. That only works if there's at least one illegal value, though. And you know what it is :-) > If your "security" source code does not have at least 10% assert > lines, you're not really serious about security. People get really pissed off when I put asserts into OpenSSL. Perhaps they'll have a different opinion now. > And of course, if you compile the asserts out for "production" > you are downright moronic about security :-) > > -- > 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 Fri Apr 25 21:04:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E191340 for ; Fri, 25 Apr 2014 21:04:31 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C1B991720 for ; Fri, 25 Apr 2014 21:04:30 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E61A86AC7 for ; Fri, 25 Apr 2014 21:04:29 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 27DCD31238; Fri, 25 Apr 2014 23:04:32 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? References: <8783.1398202137@server1.tristatelogic.com> <20140423003400.GA8271@glaze.hydra> <20140423010054.2891E143D098@rock.dv.isc.org> <20140423012206.GB8271@glaze.hydra> <86bnvpoav7.fsf@nine.des.no> <86zjj9mivi.fsf@nine.des.no> <20140425175056.GA8508@glaze.hydra> Date: Fri, 25 Apr 2014 23:04:32 +0200 In-Reply-To: <20140425175056.GA8508@glaze.hydra> (Chad Perrin's message of "Fri, 25 Apr 2014 11:50:56 -0600") Message-ID: <86iopxm87z.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:04:31 -0000 Chad Perrin writes: > Do you claim that the Clang static analyzer is essentially worthless for > finding and fixing security-related bugs because it is more trouble to > make use of its output than its output is worth, or does it only *seem* > like that is your claim? All I was saying is that 70% of this thread is pointless and that some of the most active participants are talking out of their asses. I won't address the wall of text in your previous reply except to note that you misrepresented my position and argued against a claim I never made. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 21:21:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A918DAA3 for ; Fri, 25 Apr 2014 21:21:48 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 894C91878 for ; Fri, 25 Apr 2014 21:21:48 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id BA72A3AE0E for ; Fri, 25 Apr 2014 14:21:47 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org security" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: Date: Fri, 25 Apr 2014 14:21:47 -0700 Message-ID: <32377.1398460907@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:21:48 -0000 In message Ben Laurie wrote: >But that would then hide the error condition of it being not set to a >new value after initialisation. The (modified/quieted) code example under discussion is as follows: variable = value0; /* initialization */ if (condition) variable = value1; if (!condition) variable = value2; use (variable); Please note that variable *is* *always* set to some value (either value1 or value2) after initialization. The "error condition" that you seem concerned about having explicitly flagged does not in fact exist in the example code snippet under discussion. >One better answer would be to have a way to annotate that after the >two conditionals you assert that |variable| is initialised. Then a >future, smarter static analyzer can attempt to prove you wrong. Sir, is there any sense in which the final line of the above example _does not_ already and standing all by itself constitute an implicit assertion that "variable" has been initialized by that point in the code? Regards, rfg From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 21:38:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BFB65AA for ; Fri, 25 Apr 2014 21:38:55 +0000 (UTC) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by mx1.freebsd.org (Postfix) with SMTP id 182F11A28 for ; Fri, 25 Apr 2014 21:38:54 +0000 (UTC) Received: (qmail 12841 invoked by uid 0); 25 Apr 2014 21:38:54 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 25 Apr 2014 21:38:54 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw3 with id uMer1n00G36DqkS01MeuQ3; Fri, 25 Apr 2014 15:38:54 -0600 X-Authority-Analysis: v=2.1 cv=XPOjF2RE c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=pGLkceISAAAA:8 a=hKNOJcEOAAAA:8 a=70qzlKQjAAAA:8 a=ZKyoXTu9lnk2cEw3GCcA:9 a=CjuIK1q_8ugA:10 a=--HJk1m7dRcA:10 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=EjWW2IitWDjcQvnTTho7tMrnVIeJFngqDQ+UcnF4RME=; b=jFWTOwRWej7cOrTe26VcLXsW8OIdnVgdUQYCD/dlYgm8MTIOQ5r1snAlyzoXlhy9e/yRgBUAqjdoLHMJufV4TbFoLTZdpy6rMv08G42K9P5d63wBhfG9h2YvRS3SVUZT; Received: from [98.245.97.34] (port=62594 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Wdnpb-0001LH-9i for freebsd-security@freebsd.org; Fri, 25 Apr 2014 15:38:51 -0600 Date: Fri, 25 Apr 2014 15:38:46 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425213846.GC9479@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <86zjj9mivi.fsf@nine.des.no> <32060.1398457484@server1.tristatelogic.com> <36500.1398458797@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:38:55 -0000 On Fri, Apr 25, 2014 at 09:52:25PM +0100, Ben Laurie wrote: > On 25 April 2014 21:46, Poul-Henning Kamp wrote: > > In message > > , Ben Laurie writes: > >>On 25 April 2014 21:24, Ronald F. Guilmette wrote: > >>> Separately, a code example of the following general form was discussed: > >>> > >>> if (condition) variable = value1; > >>> if (!condition) variable = value2; > >>> use (variable); > >>> > > > >>One better answer would be to have a way to annotate that after the > >>two conditionals you assert that |variable| is initialised. Then a > >>future, smarter static analyzer can attempt to prove you wrong. > > > > The way you do that *IS* to assert that the variable is indeed > > set to something you can use. > > That only works if there's at least one illegal value, though. And you > know what it is :-) With the proposed initialization value of -1, you could at least assert that it is no longer -1, which at least indicates you have done *something* to it in your code -- which, I believe, solves the problem the code analyzer actually "intended" to point out, which is that it might be possible for a variable to be used without any value assigned to it (thus potentially reading garbage from a variable). > > > > If your "security" source code does not have at least 10% assert > > lines, you're not really serious about security. > > People get really pissed off when I put asserts into OpenSSL. > > Perhaps they'll have a different opinion now. . . . or maybe we'll all end up using LibreSSL in the not-to-distant future and it will not matter any longer (for some definition of "we" that does not include banks running "secure" software on VMS past its epoch). -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 21:40:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5E6C696 for ; Fri, 25 Apr 2014 21:40:20 +0000 (UTC) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by mx1.freebsd.org (Postfix) with SMTP id 7D7CA1A49 for ; Fri, 25 Apr 2014 21:40:20 +0000 (UTC) Received: (qmail 17333 invoked by uid 0); 25 Apr 2014 21:40:19 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 25 Apr 2014 21:40:19 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw3 with id uMgG1n00l36DqkS01MgKnp; Fri, 25 Apr 2014 15:40:19 -0600 X-Authority-Analysis: v=2.1 cv=XPOjF2RE c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=oA0Jii2iB0UA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=70qzlKQjAAAA:8 a=5qVS7zfge0p1EuM6TFkA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 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=OLXrIDXA40LLWVCpUMB/UIbftIPU11InxdVqncWpK7E=; b=qg+Kc5bEjRDM62vAilrWsFtxrJtK0Tqfuj6h+IVjzoNM23UizZ7S3yHLJJweiz5nKB+XTOf5us9ZfEevrvsJUz0oeslgLLcUmZCFCCFmj9xUfujvIjEnU3nDOWcHHs39; Received: from [98.245.97.34] (port=62631 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Wdnqy-0002q1-Hk for freebsd-security@freebsd.org; Fri, 25 Apr 2014 15:40:16 -0600 Date: Fri, 25 Apr 2014 15:40:11 -0600 From: Chad Perrin To: freebsd-security@freebsd.org Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425214011.GD9479@glaze.hydra> Mail-Followup-To: freebsd-security@freebsd.org References: <32377.1398460907@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32377.1398460907@server1.tristatelogic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:40:20 -0000 On Fri, Apr 25, 2014 at 02:21:47PM -0700, Ronald F. Guilmette wrote: > > In message > Ben Laurie wrote: > > >But that would then hide the error condition of it being not set to a > >new value after initialisation. > > The (modified/quieted) code example under discussion is as follows: > > variable = value0; /* initialization */ > if (condition) variable = value1; > if (!condition) variable = value2; > use (variable); > > Please note that variable *is* *always* set to some value (either value1 > or value2) after initialization. The "error condition" that you seem > concerned about having explicitly flagged does not in fact exist in the > example code snippet under discussion. > > >One better answer would be to have a way to annotate that after the > >two conditionals you assert that |variable| is initialised. Then a > >future, smarter static analyzer can attempt to prove you wrong. > > Sir, is there any sense in which the final line of the above example > _does not_ already and standing all by itself constitute an implicit > assertion that "variable" has been initialized by that point in the > code? I do believe you are right . . . at least until the code needs to be edited for some reason. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 06:40:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C6209F2 for ; Sat, 26 Apr 2014 06:40:20 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DCB51991 for ; Sat, 26 Apr 2014 06:40:20 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e16so5039104qcx.34 for ; Fri, 25 Apr 2014 23:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bc2yj6i8BsqJDiIqtJeUjNekQOoX6IgJnOxfGt0CWIc=; b=NOu6VrzwWb7vG/Rcc7W7UyjwwWx4z75gjNA+8Lar2Lh/3URfHR4MXrBYzY689lB8pK 7iqt3h7RzZgxCqRpWqtG9EgQLZU/5QxV0ZYT1cvx+gISZ+w4DN/RF2RA8y4Tv1iG2X1z WLsNI1jQ4zIZuBY11XSPtNr7v5IwhNL/sPAKBT4eJp+395Ie4imCCEBiQ41kVOo0nD5p RCFlwWBQ++cX4UDXJV1aco/SPCL1d3pmLxqwXQp46XjtAdznQjcSstJWlQ6mzFOaHeq1 Tx0cAiKgcXk3dOUEQCZ4HZE9395+kc58274L1Ffir02Zd6sCNo9HpQ2Q3wZ5PTzCESMv uxPg== MIME-Version: 1.0 X-Received: by 10.224.66.133 with SMTP id n5mr17515241qai.11.1398494418777; Fri, 25 Apr 2014 23:40:18 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Fri, 25 Apr 2014 23:40:18 -0700 (PDT) In-Reply-To: <32377.1398460907@server1.tristatelogic.com> References: <32377.1398460907@server1.tristatelogic.com> Date: Sat, 26 Apr 2014 07:40:18 +0100 X-Google-Sender-Auth: pkh3tPeGDjGfU6e1irfYvSU0tyQ Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 06:40:20 -0000 On 25 April 2014 22:21, Ronald F. Guilmette wrote: > > In message > Ben Laurie wrote: > >>But that would then hide the error condition of it being not set to a >>new value after initialisation. > > The (modified/quieted) code example under discussion is as follows: > > variable = value0; /* initialization */ > if (condition) variable = value1; > if (!condition) variable = value2; > use (variable); > > Please note that variable *is* *always* set to some value (either value1 > or value2) after initialization. The "error condition" that you seem > concerned about having explicitly flagged does not in fact exist in the > example code snippet under discussion. Of course it doesn't, that's the whole point. >>One better answer would be to have a way to annotate that after the >>two conditionals you assert that |variable| is initialised. Then a >>future, smarter static analyzer can attempt to prove you wrong. > > Sir, is there any sense in which the final line of the above example > _does not_ already and standing all by itself constitute an implicit > assertion that "variable" has been initialized by that point in the > code? My point is that if you want to silence the warning, the right way to do it is by saying "you are wrong, here is my claimed truth" rather than by changing the code to avoid the shortcoming in analysis. The reason being that future analysis can decide to ignore or disprove your assertion, but cannot ignore the suppression you suggest. From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 06:41:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FDF5ADC for ; Sat, 26 Apr 2014 06:41:39 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE8AB1A29 for ; Sat, 26 Apr 2014 06:41:38 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id cm18so4498084qab.32 for ; Fri, 25 Apr 2014 23:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Q/7aM8k7+cIG7KueUhamINTecNfdmxKX/WMoz5RbigE=; b=V0WR9Olfbzp/YyJBrQlj9qtMA0+Rx6oDyiIRn05o7gUQRMxZlA5nXyugegG5+xLMRJ FolUjDdqDkyITpCZ06nN+e7Gh5h0rtq0xDo9UYCfhsPreAOlJilzXFVhcQXE/qFSaagk CiL+iIaUjd0pB5zIgTDaaRaO2V9sb7eGEBE7nXYeTcCs/egmtzr4lyLrHR/vRahbnrkB NIPRAL+kUGpOJcTKrYZHSNkLGp+s+7HoYpN1EfMHWZaomFYuBtHUp7JGdrQN031uLTet q3X1eypDBbY9Jgt7LIAnVpI2XWjVVPzBOZ0nI6gFeJqchA3jj5m3e1KWmIOmjPMGIEvR xaYQ== MIME-Version: 1.0 X-Received: by 10.224.147.77 with SMTP id k13mr17722201qav.64.1398494497987; Fri, 25 Apr 2014 23:41:37 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Fri, 25 Apr 2014 23:41:37 -0700 (PDT) In-Reply-To: <20140425213846.GC9479@glaze.hydra> References: <86zjj9mivi.fsf@nine.des.no> <32060.1398457484@server1.tristatelogic.com> <36500.1398458797@critter.freebsd.dk> <20140425213846.GC9479@glaze.hydra> Date: Sat, 26 Apr 2014 07:41:37 +0100 X-Google-Sender-Auth: l_mXVRuANRy5A7MOakOzl9rULu4 Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: "freebsd-security@freebsd.org security" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 06:41:39 -0000 On 25 April 2014 22:38, Chad Perrin wrote: > On Fri, Apr 25, 2014 at 09:52:25PM +0100, Ben Laurie wrote: >> On 25 April 2014 21:46, Poul-Henning Kamp wrote: >> > In message >> > , Ben Laurie writes: >> >>On 25 April 2014 21:24, Ronald F. Guilmette wrote: >> >>> Separately, a code example of the following general form was discussed: >> >>> >> >>> if (condition) variable = value1; >> >>> if (!condition) variable = value2; >> >>> use (variable); >> >>> >> > >> >>One better answer would be to have a way to annotate that after the >> >>two conditionals you assert that |variable| is initialised. Then a >> >>future, smarter static analyzer can attempt to prove you wrong. >> > >> > The way you do that *IS* to assert that the variable is indeed >> > set to something you can use. >> >> That only works if there's at least one illegal value, though. And you >> know what it is :-) > > With the proposed initialization value of -1, you could at least assert > that it is no longer -1, which at least indicates you have done > *something* to it in your code -- which, I believe, solves the problem > the code analyzer actually "intended" to point out, which is that it > might be possible for a variable to be used without any value assigned > to it (thus potentially reading garbage from a variable). Only if -1 cannot be either value1 or value2, that's my point. > > >> > >> > If your "security" source code does not have at least 10% assert >> > lines, you're not really serious about security. >> >> People get really pissed off when I put asserts into OpenSSL. >> >> Perhaps they'll have a different opinion now. > > . . . or maybe we'll all end up using LibreSSL in the not-to-distant > future and it will not matter any longer (for some definition of "we" > that does not include banks running "secure" software on VMS past its > epoch). Or Windows or Linux or ... > > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] > _______________________________________________ > 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 Apr 26 09:56:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B4CE3EC for ; Sat, 26 Apr 2014 09:56:34 +0000 (UTC) Received: from bay0-omc3-s22.bay0.hotmail.com (bay0-omc3-s22.bay0.hotmail.com [65.54.190.160]) by mx1.freebsd.org (Postfix) with ESMTP id 7649318FA for ; Sat, 26 Apr 2014 09:56:34 +0000 (UTC) Received: from BAY180-W44 ([65.54.190.188]) by bay0-omc3-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Apr 2014 02:55:28 -0700 X-TMN: [bQ+yJhGFN79F9+aEccAPG1LvHPZo25QP] X-Originating-Email: [jp4314@outlook.com] Message-ID: From: Joe Parsons To: "freebsd-security@freebsd.org" Subject: am I NOT hacked? Date: Sat, 26 Apr 2014 05:55:28 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2014 09:55:28.0095 (UTC) FILETIME=[A70EA6F0:01CF6135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 09:56:34 -0000 I was slow to patch my multiple vms after that heartbleed disclosure. I ju= st managed to upgrade these systems to 9.2=2C and installed the patched ope= nssl=2C then started changing passwords for root and other shell users. Ho= wever I realized that=2C only the root password was changed. For other use= rs=2C even though the "passwd userid" issued no warning=2C and "echo $?" is= 0=2C the password is NOT changed. For more debugging=2C I tried to "adduser"=2C the command was successful=2C= and I can see the new entry "test" in /etc/passwd. However "finger test" c= omplains no such user! Also=2C "rm test" complains there is no such user t= o delete as well. Furthermore=2C the mail server got problem sending email=2C the log file sa= id there is no such user "postfix"=2C and sure enough: # finger postfix finger: postfix: no such user while this "postfix" user certainly existed for years=2C and I can see see = its entry in /etc/passwd. This appeared to all the multiple vms on multiple hosts=2C all running Free= BSD 9.2 now. I was paranoid=2C I really should have patched all these systems immediatel= y reading that heartbleed news=2C as all these servers had the vulnerable o= penssl port installed! Until googling and I found this:=20 https://forums.freebsd.org/viewtopic.php?&t=3D29644 it said "The user accounts are actually stored in a database. It's possible= it got out of sync with your [file]/etc/passwd[/file] file."=2C and it sug= gested running "vipw" to fix it. I ran vipw=2C then saved=2C and quit. No joy. Then ran vipw again=2C made= a change=2C then undid the change=2C save again. Now "finger postfix" fou= nd the user=2C and I can change user password now=2C and all the above prob= lem disappeared. Am I right that=2C that I am NOT hacked? Is the above problem produced by = the freebsd-update process? Is this supposed to happen? I just followed t= he handbook to update from 9.1-RELEASE to 9.2-RELEASE=2C never compiled ker= nel or tweak. Thank you! Joe = From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 10:23:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A71A4CB7 for ; Sat, 26 Apr 2014 10:23:58 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63FAF1B35 for ; Sat, 26 Apr 2014 10:23:58 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so4849646iec.33 for ; Sat, 26 Apr 2014 03:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=BDgrZeUqclwTAT9X9r6V7aNRls69q8h5gp8foPzOQ7g=; b=as8GtK6i3sgvLxn40R+P5lR0C5XMA5cFalmM9SOsJToZNPogrTlEBSv8RjDvL7CRik hY6kzE/OsBQrlTyXrW/TYuV3TN/I4PkoyJP4pF6toZvgPyYUT0zRdpK8hPXGbaeXr8au uzhkTtY4PPHvsZIOmPQ/uN4+SWD45wFVwbSR4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=BDgrZeUqclwTAT9X9r6V7aNRls69q8h5gp8foPzOQ7g=; b=HkXReIvs+51YolLzoSfi7EupTBT/ojOFxQNe9ei2STTnM6Z1c0By8VgbOAevf09lW6 HOx/GMj6KGTbr0BSYc4TtlKT8yEzM1r5xJxI4AIqNepGVOOjR+ajE5KkB8K7gl/eCXcD G8b0RJZsJvf6NYMGK23Ikq1H8Ji+NjvYiib9In6+OXGi9P7djJQ6K/etM6G2kA/edXUV fg5hRtOZAOmyLQ2emDNnhSw8P0Dh99NaXje4TJBvynF9INXIqTE0jvkdKHp1tArpwG6Z BkbYo/rOQWG9G9YLcYm6TQwzv31FOqv2RE2OE2XwHtPh0UzJJFg4yF7eiEUGoKhrROUP 4p2Q== X-Gm-Message-State: ALoCoQkBMwtmLvb7nq2//5sxgFLzcnd8JUo8eKWBFOwij6IAWcIRxs7rUG2ev6Wqfd2PBJnssn3K X-Received: by 10.42.194.199 with SMTP id dz7mr286533icb.76.1398507393944; Sat, 26 Apr 2014 03:16:33 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id vf14sm4859178igb.8.2014.04.26.03.16.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Apr 2014 03:16:33 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6402F128-C5A9-41ED-A55B-2A104FB01680; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <40252ED1-CB5C-4A4D-B0B8-C3E9AFCDD3C2@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: am I NOT hacked? Date: Sat, 26 Apr 2014 06:16:29 -0400 To: Joe Parsons X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 10:23:58 -0000 --Apple-Mail-6402F128-C5A9-41ED-A55B-2A104FB01680 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Excuse me but there is nothing about the information you have provided that c= ould or would suggest that you have or have not been hacked. There is not a w= ay from the very little information that you have provided to diagnose that a= nd doesn't seem that you have covered all the avenues possible to even detec= t an unwanted change in your systems. For the least part yes FreeBSD does store the passwd info in a database. You= could have skipped running vipw(8) and just run pw_mkdb /etc/master.passwd t= o resolve that problem. Its common knowledge. To solve the hacked or not hacked problem you should take the steps to creat= e a new clean system and migrate your data but j doubt this list is a justif= ied medium to discuss all the possible avenues that you would have to cover o= n a possibly compromised system. Clean fresh system and start from there. Good luck=20 --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Apr 26, 2014, at 5:55, Joe Parsons wrote: >=20 > I was slow to patch my multiple vms after that heartbleed disclosure. I j= ust managed to upgrade these systems to 9.2, and installed the patched opens= sl, then started changing passwords for root and other shell users. However= I realized that, only the root password was changed. For other users, even= though the "passwd userid" issued no warning, and "echo $?" is 0, the passw= ord is NOT changed. >=20 > For more debugging, I tried to "adduser", the command was successful, and I= can see the new entry "test" in /etc/passwd. However "finger test" complain= s no such user! Also, "rm test" complains there is no such user to delete a= s well. >=20 > Furthermore, the mail server got problem sending email, the log file said t= here is no such user "postfix", and sure enough: >=20 > # finger postfix > finger: postfix: no such user >=20 > while this "postfix" user certainly existed for years, and I can see see i= ts entry in /etc/passwd. >=20 > This appeared to all the multiple vms on multiple hosts, all running FreeB= SD 9.2 now. >=20 > I was paranoid, I really should have patched all these systems immediately= reading that heartbleed news, as all these servers had the vulnerable opens= sl port installed! >=20 > Until googling and I found this:=20 >=20 > https://forums.freebsd.org/viewtopic.php?&t=3D29644 >=20 > it said "The user accounts are actually stored in a database. It's possibl= e it got out of sync with your [file]/etc/passwd[/file] file.", and it sugge= sted running "vipw" to fix it. >=20 > I ran vipw, then saved, and quit. No joy. Then ran vipw again, made a ch= ange, then undid the change, save again. Now "finger postfix" found the use= r, and I can change user password now, and all the above problem disappeared= . >=20 > Am I right that, that I am NOT hacked? Is the above problem produced by t= he freebsd-update process? Is this supposed to happen? I just followed the= handbook to update from 9.1-RELEASE to 9.2-RELEASE, never compiled kernel o= r tweak. >=20 > Thank you! Joe > =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= " --Apple-Mail-6402F128-C5A9-41ED-A55B-2A104FB01680 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDQyNjEwMTYzMVowIwYJKoZIhvcN AQkEMRYEFKKIsBd9Nhn76z6cJtJflDE361XWMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAfa1dsjKfTZX/uxpOnwst QsrpVTLaZIMhnN+xiG2NzS0Zkv2THxelSZE4xNSbcWTmMosHyH5VlC+bL/+JkHAq7cBXhEVjyqgP gJOtMNLJAGn7UktL3I54z4LlykfcT1TGa03RE0u6pfke3i7kpC8aAFPAt+CFZzL3iZh80f9fqax5 cdLNzGEURftaHKhe22F0Sv3yMmjijV5MoaEKHWBRvETKwX9+uNoBYvYnxa+YWPB+7wQ9Rw34TzYu o0TA+u4gU1MV2h+9NKh6W33weZakPbtSRxbjkKZMHRLBVd8H+cMgN1qfo+cOma1VoWX8FvI+itUX Oz9YeJEnTxLj8FbwlgAAAAAAAA== --Apple-Mail-6402F128-C5A9-41ED-A55B-2A104FB01680-- From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 11:15:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB6599FC for ; Sat, 26 Apr 2014 11:15:17 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7DEF910B1 for ; Sat, 26 Apr 2014 11:15:17 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 7AD046390; Sat, 26 Apr 2014 11:15:16 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 03AE5316E5; Sat, 26 Apr 2014 13:15:18 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Joe Parsons Subject: Re: am I NOT hacked? References: Date: Sat, 26 Apr 2014 13:15:18 +0200 In-Reply-To: (Joe Parsons's message of "Sat, 26 Apr 2014 05:55:28 -0400") Message-ID: <86tx9gl4u1.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 11:15:17 -0000 Joe Parsons writes: > I was slow to patch my multiple vms after that heartbleed disclosure. > I just managed to upgrade these systems to 9.2, and installed the > patched openssl, then started changing passwords for root and other > shell users. [...] If you were running 9.2 or older and had not installed OpenSSL from ports, you were never vulnerable. In any case, heartbleed does *not* facilitate remote code execution or code injection, only information retrieval, so unless your passwords were stored in cleartext (or a weakly hashed form) in the memory of an Internet-facing SSL-enabled service (such as https, smtp with STARTTLS or imaps, but not ssh), you cannot have been "hacked" as a consequence of heartbleed. Your passwd etc issues are consistent with out-of-sync {,s}pwd.mkdb which can result from a botched mergemaster. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 10:25:13 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29B4CDD0 for ; Sat, 26 Apr 2014 10:25:13 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DA1751B84 for ; Sat, 26 Apr 2014 10:25:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::92d:ba2d:3c64:ddd2] (unknown [IPv6:2001:7b8:3a7:0:92d:ba2d:3c64:ddd2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CA1DB5C44; Sat, 26 Apr 2014 12:25:08 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_4312382A-7049-4883-A9E6-5BEAC11EBEFC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: am I NOT hacked? From: Dimitry Andric In-Reply-To: Date: Sat, 26 Apr 2014 12:24:51 +0200 Message-Id: <039246EB-21D1-48C1-9D59-F3C9F8D8C74D@FreeBSD.org> References: To: Joe Parsons X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Sat, 26 Apr 2014 12:18:47 +0000 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 10:25:13 -0000 --Apple-Mail=_4312382A-7049-4883-A9E6-5BEAC11EBEFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Apr 2014, at 11:55, Joe Parsons wrote: > I was slow to patch my multiple vms after that heartbleed disclosure. = I just managed to upgrade these systems to 9.2, and installed the = patched openssl, FreeBSD 9.x was never vulnerable to Heartbleed, as you can read in the security advisory (FreeBSD-SA-14:06.openssl). This is because it still has OpenSSL 0.9.8, and the feature that contains the Heartbleed problem was only implemented after OpenSSL 1.0. That said, the advisory also contained another OpenSSL security problem, CVE-2014-0076, but that was apparently found less earth-shattering than Heartbleed. So it is still a good idea to patch up your server(s) and check for irregularities. -Dimitry --Apple-Mail=_4312382A-7049-4883-A9E6-5BEAC11EBEFC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlNbiYAACgkQsF6jCi4glqM5dACeIwuJ3dwz70PMnyjIO+tNhQyh AGQAn1wbsmgtJlPrgkrriTzhsCcb3sUE =EAmz -----END PGP SIGNATURE----- --Apple-Mail=_4312382A-7049-4883-A9E6-5BEAC11EBEFC-- From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 17:02:53 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3D923F5 for ; Sat, 26 Apr 2014 17:02:53 +0000 (UTC) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46E7E1DD1 for ; Sat, 26 Apr 2014 17:02:52 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id z11so2659070lbi.26 for ; Sat, 26 Apr 2014 10:02:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=d0sQpmyexwIdroEAE76VmRP1W6v5y7u+rJz+qoU+RB0=; b=WLmnA0/x31bfSDoBjRf0CQXryWfSxKNFL2iK8mmxkSPJFiHaY8F2yrzzJyo8foB4Y1 LQTs/3BY6SvKINZo9MqbOK51NOtP7Vc9+GhlvcWnpb7oqWxCijivYnGU9dQRY2DNBG0P Q11J6hBaMIJM5QsfdXaEmhYMe2Mr/zM6Yhwf1x9yHybviiNCeobZbd2SuKsSIQYJCgO+ ozoGtcvXXnfJy4NDRhsCmoSrgv6lMr4RrG3/n8gEQZVuWfROesvYxJ46KEIGa8fyaQK/ twlY6w0AVDSnE+0sfkNk0S9w5XFxzu/Ao/GWELMHVke1f65RHt9VXaTAB6g9m/AqnhBy CRVg== X-Gm-Message-State: ALoCoQlzKGhcIxwZhuOhcyrKGj9u/qWuHB6pfSbcsZkq4eRv5CCOmjgyxD39CEh+sK6bwhJLqkxd X-Received: by 10.152.30.41 with SMTP id p9mr10803934lah.26.1398531765445; Sat, 26 Apr 2014 10:02:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.39.71 with HTTP; Sat, 26 Apr 2014 10:02:05 -0700 (PDT) X-Originating-IP: [208.54.40.253] In-Reply-To: References: From: Leif Pedersen Date: Sat, 26 Apr 2014 12:02:05 -0500 Message-ID: Subject: Re: am I NOT hacked? To: Joe Parsons Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 17:02:54 -0000 Joe, Just thinking about this practically, I don't think you were compromised. It seems more like you goofed the upgrade in the same way on each VM. Also, if I were attacking, I wouldn't leave such overt traces that one would immediately notice. And if the attacker were goofing up that badly, he'd likely not do it the same way on every VM. Not that assuming anything about an attacker's intelligence guarantees anything, but it does seem like an odd thing to do. Not to mention other's comments about pre-10 not being vulnerable, and local compromise requiring that your password or SSH key was read by a process serving SSL sockets. If you decide it's likely your system was compromised while it was vulnerable, shutting off the system is a priority to stop ongoing damages. Then you have to mount its disks in a clean system so that whatever bad stuff (bots, backdoors, etc) the attacker added don't just start again at reboot, and to be sure the attacker doesn't merely add backdoors back while you take them away. It's hard to be sure you fixed every single file that was touched ...executables, dynamic libs, configs, and much more contain subtle ways to leave a back door, and one could even patch the kernel to hide a malicious process in memory. Starting from a fresh install and copying your data over is really the quickest and safest approach. Since "restore your data" usually means home directories, be sure to check everyone's .ssh/authorized_keys for unwanted entries before copying. Try "man pwd_mkdb" for info on the password database; especially look under the "FILES" heading. It's a good subsystem to know more about anyway, and not complicated. It is perhaps easier to remember that using vipw to add a blank line will sync everything than to remember the cryptic "pwd_mkdb -p /etc/master.passwd" command though. Actually having a machine compromised is no fun; I've been there. I do hope that's not the case for you. - Leif On Sat, Apr 26, 2014 at 4:55 AM, Joe Parsons wrote: > I was slow to patch my multiple vms after that heartbleed disclosure. I > just managed to upgrade these systems to 9.2, and installed the patched > openssl, then started changing passwords for root and other shell users. > However I realized that, only the root password was changed. For other > users, even though the "passwd userid" issued no warning, and "echo $?" is > 0, the password is NOT changed. > > For more debugging, I tried to "adduser", the command was successful, and > I can see the new entry "test" in /etc/passwd. However "finger test" > complains no such user! Also, "rm test" complains there is no such user to > delete as well. > > Furthermore, the mail server got problem sending email, the log file said > there is no such user "postfix", and sure enough: > > # finger postfix > finger: postfix: no such user > > while this "postfix" user certainly existed for years, and I can see see > its entry in /etc/passwd. > > This appeared to all the multiple vms on multiple hosts, all running > FreeBSD 9.2 now. > > I was paranoid, I really should have patched all these systems immediately > reading that heartbleed news, as all these servers had the vulnerable > openssl port installed! > > Until googling and I found this: > > https://forums.freebsd.org/viewtopic.php?&t=29644 > > it said "The user accounts are actually stored in a database. It's > possible it got out of sync with your [file]/etc/passwd[/file] file.", and > it suggested running "vipw" to fix it. > > I ran vipw, then saved, and quit. No joy. Then ran vipw again, made a > change, then undid the change, save again. Now "finger postfix" found the > user, and I can change user password now, and all the above problem > disappeared. > > Am I right that, that I am NOT hacked? Is the above problem produced by > the freebsd-update process? Is this supposed to happen? I just followed > the handbook to update from 9.1-RELEASE to 9.2-RELEASE, never compiled > kernel or tweak. > > Thank you! Joe > > _______________________________________________ > 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 > " > -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 18:05:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2E211D4 for ; Sat, 26 Apr 2014 18:05:35 +0000 (UTC) Received: from bay0-omc3-s10.bay0.hotmail.com (bay0-omc3-s10.bay0.hotmail.com [65.54.190.148]) by mx1.freebsd.org (Postfix) with ESMTP id 8B96213C0 for ; Sat, 26 Apr 2014 18:05:35 +0000 (UTC) Received: from BAY180-W61 ([65.54.190.187]) by bay0-omc3-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Apr 2014 11:05:28 -0700 X-TMN: [klg0FHh/Rs7bb/HrfE9gK4A7axzTapw6] X-Originating-Email: [jp4314@outlook.com] Message-ID: From: Joe Parsons To: "freebsd-security@freebsd.org" Subject: RE: am I NOT hacked? Date: Sat, 26 Apr 2014 14:05:29 -0400 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2014 18:05:28.0781 (UTC) FILETIME=[1B3B4FD0:01CF617A] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 18:05:35 -0000 Ok=2C thanks a lot for all your kind help. I learned the pwd_mkdb manpage = and the databases as you suggested. To clarify=2C I understand 9.1 kernel contains the non-vulnerable version o= f openssl library=2C hence mere apache/https is not vulnerable. However th= e vulnerable openssl port is installed for the mail software to provide ima= ps/pops/smtps services=2C so they are vulnerable. The following reply is what I'm confused: > In any case=2C heartbleed does *not* facilitate remote code execution or > code injection=2C only information retrieval=2C so unless your passwords > were stored in cleartext (or a weakly hashed form) in the memory of an > Internet-facing SSL-enabled service (such as https=2C smtp with STARTTLS > or imaps=2C but not ssh)=2C you cannot have been "hacked" as a consequenc= e > of heartbleed.I ssh into the system=2C and I /usr/bin/su to become root. = Do my shell passwords show up in in clear text in the memory briefly=2C so= the attacker could happen to harvest them? In another word=2C on a system= with the vulnerable openssl port=2C do we need to change the shell passwor= d for root and other users=2C if these passwords are ONLY used in ssh and /= usr/bin/su ? I googled and found few result=2C almost all are focused on changing user m= ail passwords and server certificates. Only found this page said they chan= ged server root password: http://digitalopera.com/geek-rants/what-were-doing-to-combat-heartbleed/ Thanks=2C Joe > From: bilbo@hobbiton.org > Date: Sat=2C 26 Apr 2014 12:02:05 -0500 > Subject: Re: am I NOT hacked? > To: jp4314@outlook.com > CC: freebsd-security@freebsd.org >=20 > Joe=2C >=20 > Just thinking about this practically=2C I don't think you were compromise= d. > It seems more like you goofed the upgrade in the same way on each VM. Als= o=2C > if I were attacking=2C I wouldn't leave such overt traces that one would > immediately notice. And if the attacker were goofing up that badly=2C he'= d > likely not do it the same way on every VM. Not that assuming anything abo= ut > an attacker's intelligence guarantees anything=2C but it does seem like a= n > odd thing to do. Not to mention other's comments about pre-10 not being > vulnerable=2C and local compromise requiring that your password or SSH ke= y > was read by a process serving SSL sockets. >=20 > If you decide it's likely your system was compromised while it was > vulnerable=2C shutting off the system is a priority to stop ongoing damag= es. > Then you have to mount its disks in a clean system so that whatever bad > stuff (bots=2C backdoors=2C etc) the attacker added don't just start agai= n at > reboot=2C and to be sure the attacker doesn't merely add backdoors back w= hile > you take them away. It's hard to be sure you fixed every single file that > was touched ...executables=2C dynamic libs=2C configs=2C and much more co= ntain > subtle ways to leave a back door=2C and one could even patch the kernel t= o > hide a malicious process in memory. Starting from a fresh install and > copying your data over is really the quickest and safest approach. Since > "restore your data" usually means home directories=2C be sure to check > everyone's .ssh/authorized_keys for unwanted entries before copying. >=20 > Try "man pwd_mkdb" for info on the password database=3B especially look u= nder > the "FILES" heading. It's a good subsystem to know more about anyway=2C a= nd > not complicated. It is perhaps easier to remember that using vipw to add = a > blank line will sync everything than to remember the cryptic "pwd_mkdb -p > /etc/master.passwd" command though. >=20 > Actually having a machine compromised is no fun=3B I've been there. I do = hope > that's not the case for you. >=20 > - Leif >=20 >=20 > On Sat=2C Apr 26=2C 2014 at 4:55 AM=2C Joe Parsons w= rote: >=20 > > I was slow to patch my multiple vms after that heartbleed disclosure. = I > > just managed to upgrade these systems to 9.2=2C and installed the patch= ed > > openssl=2C then started changing passwords for root and other shell use= rs. > > However I realized that=2C only the root password was changed. For ot= her > > users=2C even though the "passwd userid" issued no warning=2C and "echo= $?" is > > 0=2C the password is NOT changed. > > > > For more debugging=2C I tried to "adduser"=2C the command was successfu= l=2C and > > I can see the new entry "test" in /etc/passwd. However "finger test" > > complains no such user! Also=2C "rm test" complains there is no such u= ser to > > delete as well. > > > > Furthermore=2C the mail server got problem sending email=2C the log fil= e said > > there is no such user "postfix"=2C and sure enough: > > > > # finger postfix > > finger: postfix: no such user > > > > while this "postfix" user certainly existed for years=2C and I can see = see > > its entry in /etc/passwd. > > > > This appeared to all the multiple vms on multiple hosts=2C all running > > FreeBSD 9.2 now. > > > > I was paranoid=2C I really should have patched all these systems immedi= ately > > reading that heartbleed news=2C as all these servers had the vulnerable > > openssl port installed! > > > > Until googling and I found this: > > > > https://forums.freebsd.org/viewtopic.php?&t=3D29644 > > > > it said "The user accounts are actually stored in a database. It's > > possible it got out of sync with your [file]/etc/passwd[/file] file."= =2C and > > it suggested running "vipw" to fix it. > > > > I ran vipw=2C then saved=2C and quit. No joy. Then ran vipw again=2C = made a > > change=2C then undid the change=2C save again. Now "finger postfix" fo= und the > > user=2C and I can change user password now=2C and all the above problem > > disappeared. > > > > Am I right that=2C that I am NOT hacked? Is the above problem produced= by > > the freebsd-update process? Is this supposed to happen? I just follow= ed > > the handbook to update from 9.1-RELEASE to 9.2-RELEASE=2C never compile= d > > kernel or tweak. > > > > Thank you! Joe > > > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe=2C send any mail to "freebsd-security-unsubscribe@freebs= d.org > > " > > >=20 >=20 >=20 > --=20 >=20 > As implied by email protocols=2C the information in this message is > not confidential. Any middle-man or recipient may inspect=2C modify=2C > copy=2C forward=2C reply to=2C delete=2C or filter email for any purpose = unless > said parties are otherwise obligated. As the sender=2C I acknowledge tha= t > I have a lower expectation of the control and privacy of this message > than I would a post-card. Further=2C nothing in this message is > legally binding without cryptographic evidence of its integrity. >=20 > http://bilbo.hobbiton.org/wiki/Eat_My_Sig > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe=2C send any mail to "freebsd-security-unsubscribe@freebsd.= org" = From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 18:18:19 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 997F1AB0 for ; Sat, 26 Apr 2014 18:18:19 +0000 (UTC) Received: from bay0-omc3-s26.bay0.hotmail.com (bay0-omc3-s26.bay0.hotmail.com [65.54.190.164]) by mx1.freebsd.org (Postfix) with ESMTP id 82F0B15CB for ; Sat, 26 Apr 2014 18:18:19 +0000 (UTC) Received: from BAY180-W19 ([65.54.190.188]) by bay0-omc3-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Apr 2014 11:17:13 -0700 X-TMN: [/vm6nAJmVI3tT5P6OEBaR4KHJ/SFOwbT] X-Originating-Email: [jp4314@outlook.com] Message-ID: From: Joe Parsons To: "freebsd-security@freebsd.org" Subject: RE: am I NOT hacked? Date: Sat, 26 Apr 2014 14:17:13 -0400 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2014 18:17:13.0822 (UTC) FILETIME=[BF7807E0:01CF617B] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 18:18:19 -0000 Sorry=2C one paragraph of my last reply appears to be screwed up on the web= archive. You can ignore that reply and just read the following. I'm sor= ry for the confusion. =20 =20 =20 Ok=2C thanks a lot for all your kind help. I learned the pwd_mkdb manpage = and the databases as you suggested.=0D =20 To clarify=2C I understand 9.1 kernel contains the non-vulnerable version o= f openssl library=2C hence mere apache/https is not vulnerable. However th= e vulnerable openssl port is installed for the mail software to provide ima= ps/pops/smtps services=2C so they are vulnerable.=0D =20 The following reply is what I'm confused:=0D =20 > In any case=2C heartbleed does *not* facilitate remote code execution or= =0D > code injection=2C only information retrieval=2C so unless your passwords= =0D > were stored in cleartext (or a weakly hashed form) in the memory of an=0D > Internet-facing SSL-enabled service (such as https=2C smtp with STARTTLS= =0D > or imaps=2C but not ssh)=2C you cannot have been "hacked" as a consequenc= e=0D > of heartbleed.=0D =20 I ssh into the system=2C and I /usr/bin/su to become root. Do my shell pas= swords show up in in clear text in the memory briefly=2C so the attacker co= uld happen to harvest them? In another word=2C on a system with the vulner= able openssl port=2C do we need to change the shell password for root and o= ther users=2C if these passwords are ONLY used in ssh and /usr/bin/su ?=0D =20 I googled and found few result=2C almost all are focused on changing user m= ail passwords and server certificates. Only found this page said they chan= ged server root password:=0D =20 http://digitalopera.com/geek-rants/what-were-doing-to-combat-heartbleed/=0D =20 Thanks=2C Joe = From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 18:33:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21335475 for ; Sat, 26 Apr 2014 18:33:38 +0000 (UTC) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 845C51772 for ; Sat, 26 Apr 2014 18:33:36 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gf5so3900981lab.21 for ; Sat, 26 Apr 2014 11:33:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YQg3IV2X8SP2LvfByXfi/5jHDXogs6l0V0OUq9Jg1y8=; b=Jt+obz5qC1gvn3j3nBYH/VZN2eKF3CnSDU5wyMpqNY3HZZWapsiD+0tINq3Tpsu9SX eSyVcRbIdck3Zxgy9jISTtI4FfaiZCykvjiGLlUEbh5eptlzsjn775qSlJz3cTenizCH s+ktHh3v9nqwqKrx7Bzd3Tixy0T4LKNxIkiv7Mt/b7YiToesfut4C6EGPJkt8fRs7JMA Zi/EX876RVChpeHgdws0mjO9JMK7VMmfyfY/41hFSyPy6kA4ZJutqV6MtqKuEcpmpxlA MNOjj6XEM1pg6b/cyiYG7cATtDV+fpw5meSV46VBXk00tBwf4I8ArlXAbRV9fzF/3VNM DNbw== X-Gm-Message-State: ALoCoQnkTCr25mdby7CNXeLOeFPxc/mPuPhaDBLP1P9WjV0RCcXlG5CVT4V0ENY45hyHT9IHZpMJ MIME-Version: 1.0 X-Received: by 10.112.137.5 with SMTP id qe5mr10596701lbb.16.1398537208400; Sat, 26 Apr 2014 11:33:28 -0700 (PDT) Received: by 10.112.39.71 with HTTP; Sat, 26 Apr 2014 11:33:28 -0700 (PDT) X-Originating-IP: [208.54.40.253] Received: by 10.112.39.71 with HTTP; Sat, 26 Apr 2014 11:33:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Apr 2014 13:33:28 -0500 Message-ID: Subject: RE: am I NOT hacked? From: Leif Pedersen To: Joe Parsons Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 18:33:38 -0000 The vulnerability is contained by the process's memory space, since one process cannot read another's memory by merely referencing it (although with exec priv a process can inspect another ...doesn't apply here). OpenSSH doesn't use OpenSSL, nor does su, so passwords aren't vulnerable when typed into them. If your mail server uses the OpenSSL port/pkg and password authentication, then passwords of users who logged in were vulnerable and need to be changed. Those passwords may have subsequently been used to log in so check their accounts for unwanted .ssh/authorized_keys that an attacker may have dropped in for a back door. If one of those passwords allows root access...consider tje system fully compromised. On 2014-04-26 1:05 PM, "Joe Parsons" wrote: > Ok, thanks a lot for all your kind help. I learned the pwd_mkdb manpage > and the databases as you suggested. > > To clarify, I understand 9.1 kernel contains the non-vulnerable version of > openssl library, hence mere apache/https is not vulnerable. However the > vulnerable openssl port is installed for the mail software to provide > imaps/pops/smtps services, so they are vulnerable. > > The following reply is what I'm confused: > > In any case, heartbleed does *not* facilitate remote code execution or > > code injection, only information retrieval, so unless your passwords > > were stored in cleartext (or a weakly hashed form) in the memory of an > > Internet-facing SSL-enabled service (such as https, smtp with STARTTLS > > or imaps, but not ssh), you cannot have been "hacked" as a consequence > > of heartbleed.I ssh into the system, and I /usr/bin/su to become root. > Do my shell passwords show up in in clear text in the memory briefly, so > the attacker could happen to harvest them? In another word, on a system > with the vulnerable openssl port, do we need to change the shell password > for root and other users, if these passwords are ONLY used in ssh and > /usr/bin/su ? > > I googled and found few result, almost all are focused on changing user > mail passwords and server certificates. Only found this page said they > changed server root password: > > http://digitalopera.com/geek-rants/what-were-doing-to-combat-heartbleed/ > > Thanks, Joe > > > From: bilbo@hobbiton.org > > Date: Sat, 26 Apr 2014 12:02:05 -0500 > > Subject: Re: am I NOT hacked? > > To: jp4314@outlook.com > > CC: freebsd-security@freebsd.org > > > > Joe, > > > > Just thinking about this practically, I don't think you were compromised. > > It seems more like you goofed the upgrade in the same way on each VM. > Also, > > if I were attacking, I wouldn't leave such overt traces that one would > > immediately notice. And if the attacker were goofing up that badly, he'd > > likely not do it the same way on every VM. Not that assuming anything > about > > an attacker's intelligence guarantees anything, but it does seem like an > > odd thing to do. Not to mention other's comments about pre-10 not being > > vulnerable, and local compromise requiring that your password or SSH key > > was read by a process serving SSL sockets. > > > > If you decide it's likely your system was compromised while it was > > vulnerable, shutting off the system is a priority to stop ongoing > damages. > > Then you have to mount its disks in a clean system so that whatever bad > > stuff (bots, backdoors, etc) the attacker added don't just start again at > > reboot, and to be sure the attacker doesn't merely add backdoors back > while > > you take them away. It's hard to be sure you fixed every single file that > > was touched ...executables, dynamic libs, configs, and much more contain > > subtle ways to leave a back door, and one could even patch the kernel to > > hide a malicious process in memory. Starting from a fresh install and > > copying your data over is really the quickest and safest approach. Since > > "restore your data" usually means home directories, be sure to check > > everyone's .ssh/authorized_keys for unwanted entries before copying. > > > > Try "man pwd_mkdb" for info on the password database; especially look > under > > the "FILES" heading. It's a good subsystem to know more about anyway, and > > not complicated. It is perhaps easier to remember that using vipw to add > a > > blank line will sync everything than to remember the cryptic "pwd_mkdb -p > > /etc/master.passwd" command though. > > > > Actually having a machine compromised is no fun; I've been there. I do > hope > > that's not the case for you. > > > > - Leif > > > > > > On Sat, Apr 26, 2014 at 4:55 AM, Joe Parsons wrote: > > > > > I was slow to patch my multiple vms after that heartbleed disclosure. > I > > > just managed to upgrade these systems to 9.2, and installed the patched > > > openssl, then started changing passwords for root and other shell > users. > > > However I realized that, only the root password was changed. For > other > > > users, even though the "passwd userid" issued no warning, and "echo > $?" is > > > 0, the password is NOT changed. > > > > > > For more debugging, I tried to "adduser", the command was successful, > and > > > I can see the new entry "test" in /etc/passwd. However "finger test" > > > complains no such user! Also, "rm test" complains there is no such > user to > > > delete as well. > > > > > > Furthermore, the mail server got problem sending email, the log file > said > > > there is no such user "postfix", and sure enough: > > > > > > # finger postfix > > > finger: postfix: no such user > > > > > > while this "postfix" user certainly existed for years, and I can see > see > > > its entry in /etc/passwd. > > > > > > This appeared to all the multiple vms on multiple hosts, all running > > > FreeBSD 9.2 now. > > > > > > I was paranoid, I really should have patched all these systems > immediately > > > reading that heartbleed news, as all these servers had the vulnerable > > > openssl port installed! > > > > > > Until googling and I found this: > > > > > > https://forums.freebsd.org/viewtopic.php?&t=29644 > > > > > > it said "The user accounts are actually stored in a database. It's > > > possible it got out of sync with your [file]/etc/passwd[/file] file.", > and > > > it suggested running "vipw" to fix it. > > > > > > I ran vipw, then saved, and quit. No joy. Then ran vipw again, made a > > > change, then undid the change, save again. Now "finger postfix" found > the > > > user, and I can change user password now, and all the above problem > > > disappeared. > > > > > > Am I right that, that I am NOT hacked? Is the above problem produced > by > > > the freebsd-update process? Is this supposed to happen? I just > followed > > > the handbook to update from 9.1-RELEASE to 9.2-RELEASE, never compiled > > > kernel or tweak. > > > > > > Thank you! Joe > > > > > > _______________________________________________ > > > 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 > > > " > > > > > > > > > > > -- > > > > As implied by email protocols, the information in this message is > > not confidential. Any middle-man or recipient may inspect, modify, > > copy, forward, reply to, delete, or filter email for any purpose unless > > said parties are otherwise obligated. As the sender, I acknowledge that > > I have a lower expectation of the control and privacy of this message > > than I would a post-card. Further, nothing in this message is > > legally binding without cryptographic evidence of its integrity. > > > > http://bilbo.hobbiton.org/wiki/Eat_My_Sig > > _______________________________________________ > > 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" > > _______________________________________________ > 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 Apr 26 18:59:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88535E33 for ; Sat, 26 Apr 2014 18:59:25 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2D919A2 for ; Sat, 26 Apr 2014 18:59:24 +0000 (UTC) MIME-version: 1.0 Received: from beat.rdnzl.info (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N4N000XLJEB3O60@st11p09mm-asmtp002.mac.com> for freebsd-security@freebsd.org; Sat, 26 Apr 2014 18:59:06 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_8A01CDAA-012A-44C9-BC9F-71782A8737B1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: am I NOT hacked? From: Kimmo Paasiala In-reply-to: Date: Sat, 26 Apr 2014 21:58:55 +0300 Message-id: References: To: Joe Parsons X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHhEKTEMXGx0EGx0YBBIZBBsTEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCH2lsGEROGXhzB xl7GxIfExxrEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxMQGx4aHxsRCl5ZF2FBS0t 8EQpMRhdsa2sRCkNaFxISBBsTHwQbGBIEGRkRCkJeFxsRCkRYFxgRCkRJFxgRCkJFF2Z9fxNNb 1xgZRoSEQpCThdrRRpSUB5DXFlcaBEKQkwXbk0deVljZGh+GEYRCkJsF2FAfFNsSx8YZHt+EQp CQBdkQ38TW357HFBJexEKcGcXYlBGGkNSUm4ZR2sRCnBoF29hQn5MeV4ZZk96EQpwaBdkXB54b UtfZlgFTxEKcGgXYRNAeVseThxoYAURCnBoF24SGxJ/cFJOElgSEQpwaBdpXEdFThx+AVx4WxE KcH8XbFJyeU5yTXB7TGARCnBfF2AZYmJeQ357GVpNEQpwaxdob0MdRnMbSEdtUhEKcEsXYmlyE 1hdXGdtU3MRCnBrF2gaQUQFGmZeXGJPEQpwbBdtZ24FH2FOYRxbGxEKcEwXbEQTGxh8cEJgZHs R X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-26_02:2014-04-25,2014-04-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=15 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404260309 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 18:59:25 -0000 --Apple-Mail=_8A01CDAA-012A-44C9-BC9F-71782A8737B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 26.4.2014, at 21.17, Joe Parsons wrote: > Sorry, one paragraph of my last reply appears to be screwed up on the = web archive. You can ignore that reply and just read the following. = I'm sorry for the confusion. =20 >=20 >=20 > Ok, thanks a lot for all your kind help. I learned the pwd_mkdb = manpage and the databases as you suggested. >=20 > To clarify, I understand 9.1 kernel contains the non-vulnerable = version of openssl library, hence mere apache/https is not vulnerable. = However the vulnerable openssl port is installed for the mail software = to provide imaps/pops/smtps services, so they are vulnerable. >=20 > The following reply is what I'm confused: >=20 >> In any case, heartbleed does *not* facilitate remote code execution = or >> code injection, only information retrieval, so unless your passwords >> were stored in cleartext (or a weakly hashed form) in the memory of = an >> Internet-facing SSL-enabled service (such as https, smtp with = STARTTLS >> or imaps, but not ssh), you cannot have been "hacked" as a = consequence >> of heartbleed. >=20 > I ssh into the system, and I /usr/bin/su to become root. Do my shell = passwords show up in in clear text in the memory briefly, so the = attacker could happen to harvest them? In another word, on a system = with the vulnerable openssl port, do we need to change the shell = password for root and other users, if these passwords are ONLY used in = ssh and /usr/bin/su ? >=20 > I googled and found few result, almost all are focused on changing = user mail passwords and server certificates. Only found this page said = they changed server root password: >=20 > = http://digitalopera.com/geek-rants/what-were-doing-to-combat-heartbleed/ >=20 > Thanks, Joe > =20 You=92re missing a few fundamental properties of a modern operating = system, memory management and memory protection. The sshd or the su = processes might have the passwords in the clear in their own memory for = some time but any other process (for example the web server with the = vulnerable OpenSSL) has no access to that memory because of how virtual = memory works. Every process has its own private memory space and the = process can not address memory owned by other processes. For example, a = process running on i386 can try to address all of the 4GBs that the i386 = instruction set allows it to do but none of the memory that it can read = or write belongs to another process because the OS keeps the those = private address spaces separate from each other using the memory = management hardware on the CPU. -Kimmo --Apple-Mail=_8A01CDAA-012A-44C9-BC9F-71782A8737B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTXAHzAAoJEFvLZC0FWRVpa3cH/34RKCwd8F28n+gvHpH/q+YV k/HD6BW9Qk+dAr3A6wlk57Lty81jxD8U0f9CRCo2DLfJ63s94ZSabwSvKme3tcau G1XQctSGFmzNXydOVR57zDRS9ycQGv9cxaSpCEabGZlmaus2xXoHVIbJbY61430R U1p/BOc1tsY1iSL2+HrZ+wzuboQ9k9IOl9XPxHCntNEFltF/OEwtgKay140tLuxX uDtTzXW5gSq+Lo0RqwAQ3vqE+ZXjLxeZ/IZnYeKIPh8Q8nnepdnY54S5p++Kjkik OHspvWYBno/3u/cvuBKuB13zyHyxsdje4Uc9YBvgfWhdMi0FEr/TmwwXqUXEhto= =L+mB -----END PGP SIGNATURE----- --Apple-Mail=_8A01CDAA-012A-44C9-BC9F-71782A8737B1-- From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 21:14:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EA1CEE for ; Sat, 26 Apr 2014 21:14:16 +0000 (UTC) Received: from bay0-omc3-s19.bay0.hotmail.com (bay0-omc3-s19.bay0.hotmail.com [65.54.190.157]) by mx1.freebsd.org (Postfix) with ESMTP id 18362163A for ; Sat, 26 Apr 2014 21:14:15 +0000 (UTC) Received: from BAY180-W16 ([65.54.190.188]) by bay0-omc3-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Apr 2014 14:14:08 -0700 X-TMN: [W2Ll4BznKNFea9acKExQCqQVhPlxuP5O] X-Originating-Email: [jp4314@outlook.com] Message-ID: From: Joe Parsons To: "freebsd-security@freebsd.org" Subject: RE: am I NOT hacked? Date: Sat, 26 Apr 2014 17:14:09 -0400 Importance: Normal In-Reply-To: References: , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2014 21:14:08.0936 (UTC) FILETIME=[7691E280:01CF6194] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 21:14:16 -0000 Ok=2C crystal clear now. And thanks for reminding the .ssh/ certificates. = The mail users are virtual mail users=2C so no need to change shell passwo= rds=2C mysql passwords. Thanks! Joe = From owner-freebsd-security@FreeBSD.ORG Sun Apr 27 15:09:03 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41531594 for ; Sun, 27 Apr 2014 15:09:03 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2DF01CA2 for ; Sun, 27 Apr 2014 15:09:02 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3RF8sSq014086 for ; Sun, 27 Apr 2014 16:08:54 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3RF8sMA014085 for freebsd-security@freebsd.org; Sun, 27 Apr 2014 16:08:54 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 16:08:53 +0100 To: freebsd-security@freebsd.org Subject: ports requiring OpenSSL not honouring OpenSSL from ports User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Sun, 27 Apr 2014 16:08:54 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 15:09:03 -0000 One of the first things I do on installing a new machine is install OpenSSL from ports. I do build with base OpenSSL due to the many programs that depend on it, but using ports OpenSSL for ports makes things easier to patch/update. In the case of Heartbleed, for example, I was able to fix ports OpenSSL much sooner than base. In the process, however, I discovered a couple of ports that built against base even when the port was installed. I was going to supply patches / notify the maintainers, but first did a check, and discovered that a lot of current ports do similar. It turns out that this wasn't a problem specifically, but more generally, it's possible that someone may think a port has been patched when it hasn't. Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* build against the port if it's installed? I realise this isn't always possible to test, especially if the port Makefile doesn't have any openSSL configuration options, but I'd like to hear others opinions on the matter. [ Not crossposted to ports@ as I'm unsure onbcross-posting etiqurtte, but feel free to add them in if appropriate ] Cheers, Jamie -- No sig From owner-freebsd-security@FreeBSD.ORG Sun Apr 27 15:29:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E817CD for ; Sun, 27 Apr 2014 15:29:08 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 469111FED for ; Sun, 27 Apr 2014 15:29:08 +0000 (UTC) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3RFT2YE043491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 27 Apr 2014 08:29:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Paul Hoffman In-Reply-To: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 08:29:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Sun, 27 Apr 2014 15:52:21 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 15:29:08 -0000 On Apr 27, 2014, at 8:08 AM, Jamie Landeg-Jones = wrote: > Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* > build against the port if it's installed? Yes, that is a reasonable expectation. I certainly had it in my head = when I rebuilt Sendmail+TLS after heartbleed, but I didn't think of = checking it. > I realise this isn't always possible to test, especially if the port = Makefile > doesn't have any openSSL configuration options, but I'd like to hear > others opinions on the matter. It would be good to add such options to as many ports as possible if it = can be done cleanly. Also, note that this is not bashing on OpenSSL: given their new = significant funding, I would certainly expect the OpenSSL project to be = finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. = It is basically impossible to fix such a bug without bad actors being = able to determine and exploit some of the fixes in unpatched systems. --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Sun Apr 27 16:15:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F600CEE for ; Sun, 27 Apr 2014 16:15:40 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F668670 for ; Sun, 27 Apr 2014 16:15:40 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id lx4so5448556iec.23 for ; Sun, 27 Apr 2014 09:15:39 -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=/efe323+GJ+h1zuV2w1q5tR0wGaySLdwNs9XJoP7UHU=; b=Ljsss2EQFHJY015d04Xm997D2utbG7hzzjaQtkA5Ee632wQWoSIplNpdFZl/DOJj7m F27wwcl54ZHxANrYwFpf+/1kQ7INolXGx8gBGdi18TyyG74WhlruqWPLurVW50WlJuku ymkZjOaUsczfLW3IzR2B67gS4ZrSVffwx+Lvxhqwqb80FCI1aVO59D9nemuAzAsj5ssF IMAf95JnE2IyTv+K5J1aFInvJUipKeT6FBO04QQ1Q/av7p2pRsjriLUPlnBoyjeX681C HKNiwN16vGhejw/4fdzeAfF4VznLb68lN2VI1r4wOYST447V7Lhz8awAPH29BC3qx4UV 6Gfg== MIME-Version: 1.0 X-Received: by 10.50.61.177 with SMTP id q17mr18305741igr.44.1398615339039; Sun, 27 Apr 2014 09:15:39 -0700 (PDT) Received: by 10.50.7.74 with HTTP; Sun, 27 Apr 2014 09:15:38 -0700 (PDT) In-Reply-To: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 11:15:38 -0500 Message-ID: Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Scot Hetzel To: Jamie Landeg-Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 16:15:40 -0000 On Sun, Apr 27, 2014 at 10:08 AM, Jamie Landeg-Jones wrote: > One of the first things I do on installing a new machine is install > OpenSSL from ports. I do build with base OpenSSL due to the many programs > that depend on it, but using ports OpenSSL for ports makes things easier > to patch/update. > > In the case of Heartbleed, for example, I was able to fix ports OpenSSL > much sooner than base. > > In the process, however, I discovered a couple of ports that built against > base even when the port was installed. I was going to supply patches / > notify the maintainers, but first did a check, and discovered that a lot > of current ports do similar. > > It turns out that this wasn't a problem specifically, but more generally, > it's possible that someone may think a port has been patched when it hasn't. > > Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* > build against the port if it's installed? > The port should use the OpenSSL port if it is installed, unless the port sets one of these variables in it's Makefile: WITH_OPENSSL_BASE USE_OPENSSL_BASE The port shouldn't be setting these variables. Do you have a list of which ports used the OpenSSL from base, instead of the installed OpenSSL port? Could you check if they set these variables. > I realise this isn't always possible to test, especially if the port Makefile > doesn't have any openSSL configuration options, but I'd like to hear > others opinions on the matter. > > [ Not crossposted to ports@ as I'm unsure onbcross-posting etiqurtte, but > feel free to add them in if appropriate ] > This is more of a ports issue, than a security issue. Post the list of affected ports to ports@, and/or submit PRs to correct the them. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-security@FreeBSD.ORG Sun Apr 27 16:37:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFD562B8 for ; Sun, 27 Apr 2014 16:37:00 +0000 (UTC) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3482B8AB for ; Sun, 27 Apr 2014 16:36:59 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gf5so4382143lab.35 for ; Sun, 27 Apr 2014 09:36:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a68H23/VjJ02p6dwshIvvVGvQY9L/XB19OetIp3NXyY=; b=XAZvSrB1UkmbhlLP4Q3YcIPzrRarXZlBJ61hQMmXSun0cDSZ3mkAO4d56UdHPe3wNJ CieIMlJzZSeQWl4oa4lVr/W7551nmo4MZngIV/x5UvhACbnjwacmXqRI4cKFJNjf0XVs E2L4qsFJqVQSgbTZq9xGlTEdhOsqPm5REq1R2x5/tSH95/49FIunU84LMQ4MWL7A1XXT hx2QaM46JDLQeEwF3Ch8QTDMEopZlQ+nonAA/KM9DpmIugZYl/ARuZLN0rgyj6ewKjrQ hveOZQB/LnGvkG/58zKUccj/y7QYnwF9i3o1vq+Bw020DMT06PTME7Pk3ixZf+gOl6Q3 T4Bg== X-Gm-Message-State: ALoCoQmJ0veg/XkT4b3SGNxyZ+2s3TT+4GWo0C6vVy6iqYjNkJ4xw7z8UfuVxT4GqljKVtb/tYSC MIME-Version: 1.0 X-Received: by 10.112.118.198 with SMTP id ko6mr14639146lbb.6.1398616617519; Sun, 27 Apr 2014 09:36:57 -0700 (PDT) Received: by 10.112.39.71 with HTTP; Sun, 27 Apr 2014 09:36:57 -0700 (PDT) X-Originating-IP: [208.54.40.253] Received: by 10.112.39.71 with HTTP; Sun, 27 Apr 2014 09:36:57 -0700 (PDT) In-Reply-To: References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 11:36:57 -0500 Message-ID: Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Leif Pedersen To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 16:37:00 -0000 With respect that there are valid reasons to have port build options, I kind of hate them. You can't choose them with pkg, and if you pick the wrong one changing it later is a fragile process, and there's no indication if a dependency needs options set a particular way. I'm not bashing the necessary ones, just agonizing against adding more unless it's *really* necessary. Are there any ld tricks one could use to make everything use /usr/local/lib/openssl or /usr/lib/openssl at runtime, system wide, including base tools? Or are the ABIs different? Then ports could always build against the base version all the time, and you could switch the whole system cleanly to the ported version when needed. It seems to me that picking one or the other per port is never desirable and means base tools cannot use an upgraded version. Such a strategy would fix that, if it's possible. But I admit I'm not an ld expert. Is this strategy possible? On 2014-04-27 10:52 AM, "Paul Hoffman" wrote: > On Apr 27, 2014, at 8:08 AM, Jamie Landeg-Jones > wrote: > > > Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* > > build against the port if it's installed? > > Yes, that is a reasonable expectation. I certainly had it in my head when > I rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it. > > > I realise this isn't always possible to test, especially if the port > Makefile > > doesn't have any openSSL configuration options, but I'd like to hear > > others opinions on the matter. > > It would be good to add such options to as many ports as possible if it > can be done cleanly. > > Also, note that this is not bashing on OpenSSL: given their new > significant funding, I would certainly expect the OpenSSL project to be > finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. It > is basically impossible to fix such a bug without bad actors being able to > determine and exploit some of the fixes in unpatched systems. > > --Paul Hoffman > _______________________________________________ > 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 Sun Apr 27 17:00:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EB85A1B for ; Sun, 27 Apr 2014 17:00:17 +0000 (UTC) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76EF9AB5 for ; Sun, 27 Apr 2014 17:00:15 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id p9so1400792lbv.20 for ; Sun, 27 Apr 2014 10:00:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=spZq2r0GndThaKwOv6QSgAZSe8zfR4nHr5eesubcie8=; b=IJ6gFnIw3/Jgs0UQjMS1OX76fkh+4oDbTdLesZuMYxX4dSQjUtI2ACEtc7ecIUYy+H ccE7K2iMP0iqjRAgHICEoguDAcVmYMZxFuxWsV3X8zi+mnTblZib30BJYrco8YqnvMt7 JaBvvG4r87mMRX63Xk0krIxMTVAHoMbmc89HcG7vu+RV5pnyxidSSn9xE7mq0aYFWD+P 8oehjc0zH9AJW9u5B5Qtf+oUcleZAdjiFPh8Fl0YLoz+xv3G/qoNNT/e8z7SVO+xU79k 7TCILA63VqERzcMAenDh/TkPLtQg1ymjr8K3z1hMoPaV0sO7RiZhvBWgD2EPrbJzqJJk IRyg== X-Gm-Message-State: ALoCoQkJv+jUtKwOwzVI7ojiVpmCzxe0c2Ydwu9lQF+GGk+sLtQ8xv4xTqtSLwG0ns3YymHdcEiz MIME-Version: 1.0 X-Received: by 10.112.173.196 with SMTP id bm4mr1990168lbc.38.1398617650459; Sun, 27 Apr 2014 09:54:10 -0700 (PDT) Received: by 10.112.39.71 with HTTP; Sun, 27 Apr 2014 09:54:10 -0700 (PDT) X-Originating-IP: [208.54.40.253] Received: by 10.112.39.71 with HTTP; Sun, 27 Apr 2014 09:54:10 -0700 (PDT) In-Reply-To: References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 11:54:10 -0500 Message-ID: Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Leif Pedersen To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 17:00:17 -0000 I realized that we don't really need any extravagance from ld at all. Move the files for the base version of openssl to a different location, and replace them with symlinks. Then when installing the port/pkg, change those symlinks to point to the newly installed version. Include an uninstall script to put them back. It's kind of like how having multiple versions of perl installed works. This would also fix the problem that if you have both installed then which openssl executables you get depends on $PATH. Thoughts? On 2014-04-27 11:36 AM, "Leif Pedersen" wrote: > With respect that there are valid reasons to have port build options, I > kind of hate them. You can't choose them with pkg, and if you pick the > wrong one changing it later is a fragile process, and there's no indication > if a dependency needs options set a particular way. > > I'm not bashing the necessary ones, just agonizing against adding more > unless it's *really* necessary. > > Are there any ld tricks one could use to make everything use > /usr/local/lib/openssl or /usr/lib/openssl at runtime, system wide, > including base tools? Or are the ABIs different? Then ports could always > build against the base version all the time, and you could switch the whole > system cleanly to the ported version when needed. > > It seems to me that picking one or the other per port is never desirable > and means base tools cannot use an upgraded version. Such a strategy would > fix that, if it's possible. But I admit I'm not an ld expert. > > Is this strategy possible? > On 2014-04-27 10:52 AM, "Paul Hoffman" wrote: > >> On Apr 27, 2014, at 8:08 AM, Jamie Landeg-Jones >> wrote: >> >> > Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* >> > build against the port if it's installed? >> >> Yes, that is a reasonable expectation. I certainly had it in my head when >> I rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it. >> >> > I realise this isn't always possible to test, especially if the port >> Makefile >> > doesn't have any openSSL configuration options, but I'd like to hear >> > others opinions on the matter. >> >> It would be good to add such options to as many ports as possible if it >> can be done cleanly. >> >> Also, note that this is not bashing on OpenSSL: given their new >> significant funding, I would certainly expect the OpenSSL project to be >> finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. It >> is basically impossible to fix such a bug without bad actors being able to >> determine and exploit some of the fixes in unpatched systems. >> >> --Paul Hoffman >> _______________________________________________ >> 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 Sun Apr 27 22:50:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D96EFE3D for ; Sun, 27 Apr 2014 22:50:07 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BBAE9C2 for ; Sun, 27 Apr 2014 22:50:05 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3RMo2rw095772; Sun, 27 Apr 2014 23:50:02 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3RMo2NZ095771; Sun, 27 Apr 2014 23:50:02 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 23:50:02 +0100 To: swhetzel@gmail.com, jamie@dyslexicfish.net Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Sun, 27 Apr 2014 23:50:03 +0100 (BST) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 22:50:07 -0000 Scot Hetzel wrote: > The port should use the OpenSSL port if it is installed, unless the > port sets one of these variables in it's Makefile: > > WITH_OPENSSL_BASE > USE_OPENSSL_BASE > > The port shouldn't be setting these variables. Thanks. As I expected. > Do you have a list of which ports used the OpenSSL from base, instead > of the installed OpenSSL port? > Could you check if they set these variables. Well, I can only check the ones I have installed. Here's a list of some that link against /lib/libcrypto.so.7 and/or /lib/libssl.so.7 retrieved using the following command: # grep -EaHlr -D skip 'libssl\.so\.7|libcrypto\.so\.7' /usr/local | awk '{print "pkg which -oq " $1}' | sh | sort | uniq [ N.B. 'grep -r' follows symlinks. You'd need to use 'find ... | grep ...' instead to be more bulletproof ] devel/android-tools-adb net-p2p/transmission-cli net-p2p/transmission-daemon net/socat net/svnup ports-mgmt/pkg security/john security/scrypt security/trousers sysutils/tarsnap Again, as expected, none of these contain references to WITH_OPENSSL_BASE or USE_OPENSSL_BASE, though I do get some ld conflict warnings in some cases (e.g. when linking to libcurl, which does do the right thing) > This is more of a ports issue, than a security issue. > > Post the list of affected ports to ports@, and/or submit PRs to > correct the them. I wanted to discuss the issue and make aware the security community before discussing actual changes with @ports As I said. there could be security implications if someone thinks a patched previously vulnerable openssl port has secured all of their other ports. Also, it's not reliably possible to check which ports are affected without at least downloading the distfile - some of the ports make no reference to ssl in their ports template. Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Sun Apr 27 22:59:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34586F75 for ; Sun, 27 Apr 2014 22:59:39 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4CEAA8D for ; Sun, 27 Apr 2014 22:59:38 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s3RMxafr095851 for ; Sun, 27 Apr 2014 23:59:36 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s3RMxaqM095850 for freebsd-security@freebsd.org; Sun, 27 Apr 2014 23:59:36 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201404272259.s3RMxaqM095850@catnip.dyslexicfish.net> Date: Sun, 27 Apr 2014 23:59:36 +0100 To: freebsd-security@freebsd.org Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Sun, 27 Apr 2014 23:59:36 +0100 (BST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2014 22:59:39 -0000 Paul Hoffman wrote: > Yes, that is a reasonable expectation. I certainly had it in my head when I rebuilt Sendmail+TLS after heartbleed, but I didn't think of checking it. Been there :-) Fortunately, sendmail 'does the right thing'! > It would be good to add such options to as many ports as possible if it can be done cleanly. This is more for ports@ than security@, but isn't mixing of 2 different versions potentially problematic? I have noticed one port that links against base, but uses libcurl which links against ports, so there is a version conflict there right away. I'd expect that some magic would need to be done in the bsd.ports.Mk files, as you can't necessarily tell from just scanning the port template. > Also, note that this is not bashing on OpenSSL: given their new significant funding, I would certainly expect the OpenSSL project to be finding-and-fixing Heartbleed-level bugs repeatedly in the coming years. It is basically impossible to fix such a bug without bad actors being able to determine and exploit some of the fixes in unpatched systems. Ditto. My concern is more general, and aligned to the POLA principle! Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 10:30:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A250CA79 for ; Mon, 28 Apr 2014 10:30:44 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 62A67174C for ; Mon, 28 Apr 2014 10:30:43 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 31A876223; Mon, 28 Apr 2014 10:30:43 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id B97FC30B22; Mon, 28 Apr 2014 12:30:43 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Leif Pedersen Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> Date: Mon, 28 Apr 2014 12:30:43 +0200 In-Reply-To: (Leif Pedersen's message of "Sun, 27 Apr 2014 11:54:10 -0500") Message-ID: <86eh0hsq3w.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, Paul Hoffman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 10:30:44 -0000 Leif Pedersen writes: > I realized that we don't really need any extravagance from ld at all. > Move the files for the base version of openssl to a different > location, and replace them with symlinks. ...and break your system. OpenSSL 0.9.x and 1.0.x are *not* binary compatible. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 11:48:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 392C8B09 for ; Mon, 28 Apr 2014 11:48:10 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C21F011BA for ; Mon, 28 Apr 2014 11:48:09 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id w61so6146620wes.4 for ; Mon, 28 Apr 2014 04:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=muAMFjiNTwNL6Spa7onkedQZkjrK76C4BfBWbgeVsXM=; b=GP/YwXxj92jRccpRRnIkecFmLjby7QAEKCzzKpUtBSBQmWKU6CtoDNs5kO/KdCFjC3 aVrcOa4r+2VWpR4PG3us5DscwZJpMkM1W32RNfKuz2E+JpDYsq2G5rlWVXvwSvEBgMJl S0RM/BLuJvNGKnvwLMWt76anfJ/V+0RINydAgOGqBu1H2vOvNe/WJ6uTkWeRa0fI6JHk cH6NXOv0DE00YpWa7Pc1yaO40tqkfRYNb59D4kcxoVD4Ro1DFEBcM9Ns4BFheA9entGe Z8w1V1gqxvdcYAancCVDVmwzlWOj4or6r2KXHRvnDfLS9WvfjroFT9WIA+nFAaryL53m Pm3w== MIME-Version: 1.0 X-Received: by 10.194.94.39 with SMTP id cz7mr516959wjb.78.1398685687267; Mon, 28 Apr 2014 04:48:07 -0700 (PDT) Received: by 10.217.55.138 with HTTP; Mon, 28 Apr 2014 04:48:07 -0700 (PDT) In-Reply-To: <20140425180217.GC8508@glaze.hydra> References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <20140414144155.C55844@sola.nimnet.asn.au> <20140425180217.GC8508@glaze.hydra> Date: Mon, 28 Apr 2014 06:48:07 -0500 Message-ID: Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] From: David Noel To: code@apotheon.net Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David.I.Noel@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:48:10 -0000 On 4/25/14, Chad Perrin wrote: > On Mon, Apr 14, 2014 at 12:36:28AM -0500, David Noel wrote: >> Thanks. I'm happy to, and it's on my to-do list, the only problem is >> that I'm swamped with other projects and it's been sitting on that >> list for the past 2 years. It seems to be a similar problem for Colin >> and the Security Team. I'm hoping that by bringing this bug to the >> list that someone with more free time will be able to patch it. > > Would you be willing to put the time into training up someone to do that > work? I'm a bit of a fixer-upper, but I am willing and eager to > contribute. Hi Chad, sorry for the slow reply. Awesome. I'm so glad to find someone with more free time than myself. I'm absolutely willing to contribute as much knowledge as possible to anyone willing to tackle these bugs. How can I help you get started? The server-side/build code wasn't available back when I was reviewing it initially but it's all on subversion now. The build code in here: http://svnweb.freebsd.org/base/user/cperciva/. freebsd-update is here: http://svnweb.freebsd.org/base/head/usr.sbin/freebsd-update/ portsnap is here: http://svnweb.freebsd.org/base/head/usr.sbin/portsnap/ The bugs in the client-side code are fairly simple to find -- just search the code for every instance of "fetch" and follow it until the file is decompressed. Instead of decompressing then sha256 verifying files, it should sha256 verify then decompress them. A pretty simple fix. IIRC in pmirror.sh there's also the issue of files being fetched and mirrored without verification. A benefit of reworking the code is that it should speed things up -- instead of sha256 verifying each individual [decompressed] file it will only have to sha256-verify once -- on the compressed archive. >From the notes I took 2 years ago (that should still be relevant today), the functions/lines of concern are: portsnap.sh: fetch_snapshot(), fetch_update(), and fetch_snapshot_verify(). pmirror.sh: 99-103, 121-125, 138-149, and 153-157 (using revision 257073). freebsd-update.sh are fetch_metadata(), fetch_files_premerge(), and fetch_files(). I think the easiest way to approach this would be to trace through the code. IIRC the portsnap system is less than 2k lines and freebsd-update is around 5k. I don't know how much RAM your brain came with but when I went through it I found it easiest to take notes on key function names as I followed the path of execution. Unless you write scripts regularly it's just large enough that you might need to take notes. But it's super clean code and really easy to follow. I was fairly new to scripting when I first started reading it but by the time I'd worked my way through it I was confident that I could patch it without too much trouble (I do also code in C/Java/etc, so that might have made it easier, but I really do think that if you can work your way through the code you'll be able to patch it without a problem). Another thing that makes this such an easy fix is that everything that needs to be done is done somewhere in the code already. You could pretty much copy and paste for the entire patch. That's all I can think of for now. Let me know if there's anything else, or if you get stuck walking through the code. -David PS: If you're debating which project to start on first I would like to make the case for freebsd-update: Granted, it's twice the side of portsnap, so it might seem more intimidating to take on first, but technically we already have a secure way to check out the ports tree (svn over http secure). So if someone was concerned about security they'd just use that alternative. Given this bug we don't however have a secure way to quickly and easily perform system updates. For the security conscious the only alternative is to manually build from source (so slow!). From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 14:12:03 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08C58D75 for ; Mon, 28 Apr 2014 14:12:03 +0000 (UTC) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [IPv6:2001:4978:1fb:6400::d2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fnord.ir.bbn.com", Issuer "ir.bbn.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB59E125A for ; Mon, 28 Apr 2014 14:12:02 +0000 (UTC) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id A4FF8A8BD; Mon, 28 Apr 2014 10:11:57 -0400 (EDT) From: Greg Troxel To: Paul Hoffman Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> OpenPGP: id=32611E25 X-Hashcash: 1:20:140428:paul.hoffman@vpnc.org::1nhyYvR1gLCCe9CT:00000000000000000000000000000000000000002+8P X-Hashcash: 1:20:140428:freebsd-security@freebsd.org::zY4rPDwrYpmT5Gz1:0000000000000000000000000000000007et0 Date: Mon, 28 Apr 2014 10:11:55 -0400 In-Reply-To: (Paul Hoffman's message of "Sun, 27 Apr 2014 08:29:01 -0700") Message-ID: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:12:03 -0000 --=-=-= Content-Type: text/plain Paul Hoffman writes: > On Apr 27, 2014, at 8:08 AM, Jamie Landeg-Jones wrote: > >> Basically what I'm asking: Shouldn't a port that uses OpenSSL *always* >> build against the port if it's installed? > > Yes, that is a reasonable expectation. I certainly had it in my head > when I rebuilt Sendmail+TLS after heartbleed, but I didn't think of > checking it. I can see your point, but simply using a package that is installed violates one of the basic design points of packaging systems. The built package should not depend on the environment in ways that are not expressed within packaging metadata. In pkgsrc (NetBSD), pkgsrc openssl can be used. But, there is a calculated default (per platform) of whether the builtin version is good enough. Currently, netbsd-5's 0.9.9 is deemed too crufty (due to features; this is not about heartbleed). There are also variables to set to prefer/use pkgsrc openssl even if builtin is deemed adequate, for people that want to build that way. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlNeYasACgkQ+vesoDJhHiVGcgCfbh9MImTC0roNC7UdepqGI9Ww lGAAoLekMldntoZDX4+ZYmta7pV3uknd =waHm -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 18:11:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DB1AF97 for ; Mon, 28 Apr 2014 18:11:35 +0000 (UTC) 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)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F07721DCB for ; Mon, 28 Apr 2014 18:11:34 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s3SIBPgu069858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 11:11:28 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <535E99C8.7050309@freebsd.org> Date: Tue, 29 Apr 2014 02:11:20 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Leif Pedersen Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <86eh0hsq3w.fsf@nine.des.no> In-Reply-To: <86eh0hsq3w.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, Paul Hoffman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:11:35 -0000 On 4/28/14, 6:30 PM, Dag-Erling SmĆørgrav wrote: > Leif Pedersen writes: >> I realized that we don't really need any extravagance from ld at all. >> Move the files for the base version of openssl to a different >> location, and replace them with symlinks. > ...and break your system. > > OpenSSL 0.9.x and 1.0.x are *not* binary compatible. are they somewhat "API" compatible? can you compile most code against either? > > DES From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 18:25:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09112670; Mon, 28 Apr 2014 18:25:55 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD0681075; Mon, 28 Apr 2014 18:25:54 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 059031C175; Mon, 28 Apr 2014 11:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398709553; bh=fVbkl0nsFAcBwB6bsBFjEYx+T4ZCp9IRON6ROU8ujlY=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=AJG9YtQ0mG6x3b5uAaEXWM5kNTEuqCkwuzLw/bjkR4PS3JFuzlpGvkCSb/CS0P5sJ Mp1f6EwN11qA64C+Eegg50QpBx6lfkYJnLcAVrIMCuRwt8Uws/o9nBoaVerOMZtfCe eJK9liDKEKuSZM885Wx04IpZuQtQVza5QBeNP3Dc= Message-ID: <535E9D2C.1020706@delphij.net> Date: Mon, 28 Apr 2014 11:25:48 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Julian Elischer , =?UTF-8?B?RGFnLUVybGluZyBTbcO4cg==?= =?UTF-8?B?Z3Jhdg==?= , Leif Pedersen Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <86eh0hsq3w.fsf@nine.des.no> <535E99C8.7050309@freebsd.org> In-Reply-To: <535E99C8.7050309@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org, Paul Hoffman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:25:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/28/14 11:11, Julian Elischer wrote: > On 4/28/14, 6:30 PM, Dag-Erling SmĆørgrav wrote: >> Leif Pedersen writes: >>> I realized that we don't really need any extravagance from ld >>> at all. Move the files for the base version of openssl to a >>> different location, and replace them with symlinks. >> ...and break your system. >> >> OpenSSL 0.9.x and 1.0.x are *not* binary compatible. > > are they somewhat "API" compatible? can you compile most code > against either? Yes you can. They are just not so guaranteed to be ABI compatible. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTXp0sAAoJEJW2GBstM+ns3RMP/RTh8PJ39cHTzYAWB5svSTVP Z+pxt9/C3422RAkgXhOTbC0GSF/AP/sm+kNDiUZpV3JmJ6s6kPYW9HlbRvZf38c3 ltwZbOzOFwY3iZ6+0PsKq99HhSjDuwHCa6E7QWcM2Y+Q4edR+55q+gew4gI7P9S6 r93BO4YYlTXv/Jg1goRT8MlGGDvKH5wdLQn3PfFV4xdLy1yw5I8LzDxNYZdDu547 /P0jfsOa1mGdCiDdKcVpZnCwINNHbrZqfo5P2YfO9eAMdnOQ8pDEx4S79yaOEqze UR74izdHvPYsTiemKKOaN6t/Yp4+NZnfRNJfPbftltjH3+gdlcQb+qb5eBPmCXYY /nRHss5H3Vm3Ta+bjbKWln0DsFfkK6Ej/s33QqJagMF34OizOP1UQsxdgcdg0I/e YFsKWT31JHOpsiNPTwmWbYJWHsSR5vZgXoUJv3PR23IV5m8xNKIib/iooY+aTOJ3 G7SbE0JwXhE5lE2jgE1q4CsCWVBzz3I+aDn/s61pVB2tttHmdjFVU5Fy2Lr3lD+F W8p3oNjQLBJB1t+Kwi0TgYAZ26yt0HUtyfKh6M4oM8jyV1v/IAiugYXD9AU9wD9b wu1wa9hc/H0VWX4v6d5BfNZIr2QdTtPOuqvFN/KzAouhMQkfyiE97wh3NTT1fR2l eOQ5saNXkLnE6PAik+l5 =T+vN -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 19:07:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9823E290; Mon, 28 Apr 2014 19:07:45 +0000 (UTC) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 739FB1472; Mon, 28 Apr 2014 19:07:45 +0000 (UTC) MIME-version: 1.0 Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4R00C008QICP00@local.mail-out.apple.com>; Mon, 28 Apr 2014 12:07:45 -0700 (PDT) Received: from relay7.apple.com ([17.128.113.101]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4R004WD94P7F40@local.mail-out.apple.com>; Mon, 28 Apr 2014 12:07:44 -0700 (PDT) X-AuditID: 11807165-f79076d0000015d9-7c-535ea6f76381 Received: from [17.149.239.226] (Unknown_Domain [17.149.239.226]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 2B.C2.05593.7F6AE535; Mon, 28 Apr 2014 12:07:36 -0700 (PDT) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Charles Swiger In-reply-to: <535E99C8.7050309@freebsd.org> Date: Mon, 28 Apr 2014 12:07:44 -0700 Message-id: <48F0201D-506E-4CDE-B758-D10A65CBBF9F@mac.com> References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <86eh0hsq3w.fsf@nine.des.no> <535E99C8.7050309@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUiOPX9I90fy+KCDb7kW/RsesJmcXXuT2YH Jo8Zn+azBDBGcdmkpOZklqUW6dslcGU0vFnNVNBqXnF6VztbA+M7/S5GTg4JAROJjsf3mCFs MYkL99azdTFycQgJ9DNJdPR8YwNJMAskSOzdvBCoiIODV0BPYvsvORBTWMBV4sZ/IRCTTUBN YsJEHpBiTgFtiUVtR8EaWQRUJWYemcAEMcRL4tHjiYwgNq+AlcSbKU/YITZtZ5I4vug7O0hC REBD4vqOGawQ58hKnD73nGUCI98sJEfMQjgCIqwtsWzha7Aws4COxOSFjKjCEPbH80eYFjCy rWIUKErNSaw010ssKMhJ1UvOz93ECArIhsLUHYyNy60OMQpwMCrx8HbExAULsSaWFVfmHmKU 4GBWEuG1bQUK8aYkVlalFuXHF5XmpBYfYpTmYFES5z0UGRssJJCeWJKanZpakFoEk2Xi4JRq YFyVkfhS0I2hxFN3d9xHjdkStWuneLrXLNd4MPVarUndFvUwEcvKIzduTOzrrXkltUvGlVHs q99cf/6iR85e2zj+NUi+VdxvKZDvHlmxoeoWY+zaqS2X2zedvPZqP+vPyiaxqbFGW2t+13xg XrWR6XA+6/ybl2JqExuv/NEUOtjt6RDDIByop8RSnJFoqMVcVJwIAJVerh5EAgAA Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:07:45 -0000 Hi-- On Apr 28, 2014, at 11:11 AM, Julian Elischer wrote: >> OpenSSL 0.9.x and 1.0.x are *not* binary compatible. > > are they somewhat "API" compatible? can you compile most code against either? Yes, you can compile most code against either OpenSSL 0.9x or 1.x. The OpenSSL API defines OPENSSL_VERSION_NUMBER like so to distinguish new functionality in 1.x: /* ECC support came along in OpenSSL 1.0.0 */ #if (OPENSSL_VERSION_NUMBER < 0x10000000) #define OPENSSL_NO_EC #endif That's the only test for OpenSSL 1 functionality in Apache, taken from httpd-2.2.27/modules/ssl/ssl_toolkit_compat.h. A quick check of other common users of SSL like curl, OpenLDAP, nmap, & nginx is pretty similar. Regards, -- -Chuck PS: curl seems to have the most checks against OpenSSL 1.x, in order to force SSLv3 vs TLS versions if the user specifies such. See curl-7.35.0/lib/vtls/openssl.c: case CURL_SSLVERSION_SSLv3: ctx_options |= SSL_OP_NO_SSLv2; ctx_options |= SSL_OP_NO_TLSv1; #if OPENSSL_VERSION_NUMBER >= 0x1000100FL ctx_options |= SSL_OP_NO_TLSv1_1; ctx_options |= SSL_OP_NO_TLSv1_2; #endif break; case CURL_SSLVERSION_TLSv1: ctx_options |= SSL_OP_NO_SSLv2; ctx_options |= SSL_OP_NO_SSLv3; break; case CURL_SSLVERSION_TLSv1_0: ctx_options |= SSL_OP_NO_SSLv2; ctx_options |= SSL_OP_NO_SSLv3; #if OPENSSL_VERSION_NUMBER >= 0x1000100FL ctx_options |= SSL_OP_NO_TLSv1_1; ctx_options |= SSL_OP_NO_TLSv1_2; #endif break; #if OPENSSL_VERSION_NUMBER >= 0x1000100FL case CURL_SSLVERSION_TLSv1_1: ctx_options |= SSL_OP_NO_SSLv2; ctx_options |= SSL_OP_NO_SSLv3; ctx_options |= SSL_OP_NO_TLSv1; ctx_options |= SSL_OP_NO_TLSv1_2; break; case CURL_SSLVERSION_TLSv1_2: ctx_options |= SSL_OP_NO_SSLv2; ctx_options |= SSL_OP_NO_SSLv3; ctx_options |= SSL_OP_NO_TLSv1; ctx_options |= SSL_OP_NO_TLSv1_1; break; #endif From owner-freebsd-security@FreeBSD.ORG Mon Apr 28 21:46:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5B1A265 for ; Mon, 28 Apr 2014 21:46:08 +0000 (UTC) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by mx1.freebsd.org (Postfix) with SMTP id 86A9115E4 for ; Mon, 28 Apr 2014 21:46:08 +0000 (UTC) Received: (qmail 32656 invoked by uid 0); 28 Apr 2014 21:46:03 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 28 Apr 2014 21:46:03 -0000 Received: from box543.bluehost.com ([74.220.219.143]) by cmgw2 with id vZlz1n01936DqkS01Zm27B; Mon, 28 Apr 2014 15:46:02 -0600 X-Authority-Analysis: v=2.1 cv=Q9RBveGa c=1 sm=1 tr=0 a=m1eD20qHdBbyQr3wvGb0tQ==:117 a=m1eD20qHdBbyQr3wvGb0tQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=J0QyKEt1u0cA:10 a=CJn5o44HT8MA:10 a=ZzjhlJrv0foA:10 a=kj9zAlcOel0A:10 a=hBmbxFWgAAAA:8 a=O5JQB85wRqYA:10 a=9NnC__TRAO0A:10 a=70qzlKQjAAAA:8 a=Eq_KJST5NxJDZYo03FEA:9 a=CjuIK1q_8ugA:10 a=1Rfx88tpER0A:10 a=jbrg_-RNVrAA:10 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:Cc:To:From:Date; bh=3hEnEWftmSySMhXKqRtHR6N3Fg9NBaNZXOjUzeVBMz4=; b=JeUUtZun6qFCBsTLu2rBUBCd3O98J3ZTeRQMb90+wKD5OXh855IGbyOUGysEFqMlIRyXcXo++H6geSBL8B9x1kRpdaQ277Fj+iSaVUmZmsNPm8hnGBGCQEAxizdQ8/X6; Received: from [98.245.97.34] (port=60121 helo=localhost) by box543.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WetNA-0003yk-Na; Mon, 28 Apr 2014 15:46:00 -0600 Date: Mon, 28 Apr 2014 15:45:57 -0600 From: Chad Perrin To: David Noel Subject: Re: Retiring portsnap [was MITM attacks against portsnap and freebsd-update] Message-ID: <20140428214557.GC5491@glaze.hydra> Mail-Followup-To: David Noel , freebsd-security@freebsd.org References: <53472B7F.5090001@FreeBSD.org> <53483074.1050100@delphij.net> <44bnw5uwmm.fsf@lowell-desk.lan> <20140414144155.C55844@sola.nimnet.asn.au> <20140425180217.GC8508@glaze.hydra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Identified-User: {2737:box543.bluehost.com:apotheon:apotheon.net} {sentby:smtp auth 98.245.97.34 authed with code@apotheon.net} Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:46:08 -0000 On Mon, Apr 28, 2014 at 06:48:07AM -0500, David Noel wrote: > > [snip a bunch of stuff] Great. I'll start looking at stuff this week, then probably ping you off-list to ask questions. Now I just need to add a note about this to my todo-queue so I don't make a liar of myself. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 04:35:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F06AD975; Wed, 30 Apr 2014 04:35:10 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC1C61440; Wed, 30 Apr 2014 04:35:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3U4ZAnp093729; Wed, 30 Apr 2014 04:35:10 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3U4ZAw1093717; Wed, 30 Apr 2014 04:35:10 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 30 Apr 2014 04:35:10 GMT Message-Id: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 04:35:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:08.tcp Security Advisory The FreeBSD Project Topic: TCP reassembly vulnerability Category: core Module: inet Announced: 2014-04-30 Credits: Jonathan Looney Affects: All supported versions of FreeBSD. Corrected: 2014-04-30 04:04:20 UTC (stable/8, 8.4-STABLE) 2014-04-30 04:05:47 UTC (releng/8.4, 8.4-RELEASE-p9) 2014-04-30 04:05:47 UTC (releng/8.3, 8.3-RELEASE-p16) 2014-04-30 04:04:20 UTC (stable/9, 9.2-STABLE) 2014-04-30 04:05:47 UTC (releng/9.2, 9.2-RELEASE-p5) 2014-04-30 04:05:47 UTC (releng/9.1, 9.1-RELEASE-p12) 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: CVE-2014-3000 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. When network packets making up a TCP stream (``TCP segments'') are received out-of-sequence, they are maintained in a reassembly queue by the destination system until they can be re-ordered and re-assembled. II. Problem Description FreeBSD may add a reassemble queue entry on the stack into the segment list when the reassembly queue reaches its limit. The memory from the stack is undefined after the function returns. Subsequent iterations of the reassembly function will attempt to access this entry. III. Impact An attacker who can send a series of specifically crafted packets with a connection could cause a denial of service situation by causing the kernel to crash. Additionally, because the undefined on stack memory may be overwritten by other kernel threads, while extremely difficult, it may be possible for an attacker to construct a carefully crafted attack to obtain portion of kernel memory via a connected socket. This may result in the disclosure of sensitive information such as login credentials, etc. before or even without crashing the system. IV. Workaround It is possible to defend to these attacks by doing traffic normalization using a firewall. This can be done by including the following /etc/pf.conf configuration: scrub in all This requires pf(4) to be enabled, and have the mentioned configuration loaded. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:08/tcp.patch # fetch http://security.FreeBSD.org/patches/SA-14:08/tcp.patch.asc # gpg --verify tcp.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/ r265123 releng/8.3/ r265125 releng/8.4/ r265125 stable/9/ r265123 releng/9.1/ r265125 releng/9.2/ r265125 stable/10/ r265122 releng/10.0/ r265124 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYHsHAAoJEO1n7NZdz2rngywP/joAE0afufOlFvOsSxeeXUWg kNhtEQV5iXgsbu8QPwM/ikmAgg2ONGLQ47A7w7vHF98qg8jk6W1aZCcRE5lIg8hg WP5boSFvzvTXIQCo8EsIdcbnNBEA6CrtVQOIvWtuow2z8T0MtSou78Ctq2SO0O+8 7lY9pFYguFBgUNmVC6jpChIGJS9uZtdz2Vn697B4fOyv1pn6wenW7teOsyN+4Dyj 7Wq/qppZDrYSnd+YdveUAFCyCoYIXcsLXbeeIVJC2g8x6LlDw8swZElZL6refX6L UPDBViI3ctAcjEgzAP1fN3d9FpA5oGJ67J9QcDxYIfTj5YrQiYoTs49ER9FD7k9Q UxrgLamZ45/D762/IpmLHCwD+FWdzhl9wufklUptrHNIyNyovwMxQDNnoGZUIKeZ x1fAfctXRAztISyQ5xqVw3nKLauPCSG6IniyyZ12BcFxmDvoEcyOFLqB1eN+l5DB aJvfiA4PjWIV1nVU+w4MKKAQbHQSgh9bu8EvYUuwNrGOtP49RV1HejWD85ePSgtr KOQ0HU8CGmTpWOMkDQBl8Ap1boP9iUOTRp/WuIxwMi+AqoKRuDrWs0sOAXIksu2s 0sgGnbI0lrg77lBW4FPvMaCg1dlzlfv4J9AExAh6Ur52qxh5GaOcI2NhYWbxvijh 5wgOBszZXV2kPRDAaJTa =uhXC -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 04:35:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08D98976; Wed, 30 Apr 2014 04:35:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD1621442; Wed, 30 Apr 2014 04:35:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3U4ZAet093731; Wed, 30 Apr 2014 04:35:10 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3U4ZA45093722; Wed, 30 Apr 2014 04:35:10 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 30 Apr 2014 04:35:10 GMT Message-Id: <201404300435.s3U4ZA45093722@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 04:35:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:07.devfs Security Advisory The FreeBSD Project Topic: devfs rules not applied by default for jails Category: core Module: etc_rc.d Announced: 2014-04-30 Affects: FreeBSD 10.0 Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: CVE-2014-3001 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The device file system, or devfs(5), provides access to kernel's device namespace in the global file system namespace. The devfs(5) rule subsystem provides a way for the administrator of a system to control the attributes of DEVFS nodes. Each DEVFS mount-point has a ``ruleset'', or a list of rules, associated with it, allowing the administrator to change the properties, including the visibility, of certain nodes. II. Problem Description The default devfs rulesets are not loaded on boot, even when jails are used. Device nodes will be created in the jail with their normal default access permissions, while most of them should be hidden and inaccessible. III. Impact Jailed processes can get access to restricted resources on the host system. For jailed processes running with superuser privileges this implies access to all devices on the system. This level of access could lead to information leakage and privilege escalation. IV. Workaround Systems that do not run jails are not affected. The system administrator can do the following to load the default ruleset: /etc/rc.d/devfs onestart Then apply the default ruleset for jails on a devfs mount using: devfs -m ${devfs_mountpoint} rule -s 4 applyset Or, alternatively, the following command will apply the ruleset over all devfs mountpoints except the host one: mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | \ xargs -n 1 -J % devfs -m % rule -s 4 applyset After this, the system administrator should add the following configuration to /etc/rc.conf to make it permanent, so the above operations do not have to be done each time the host system reboots. devfs_load_rulesets="YES" V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch.asc # gpg --verify devfs.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # install -o root -g wheel -m 444 etc/defaults/rc.conf /etc/defaults/ Follow the steps described in the "Workaround" section, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r265122 releng/10.0/ r265124 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYHsGAAoJEO1n7NZdz2rnXsQP/iInaOcBlBDIsZokdpQCgAoF eSKuD5ihYTnlUew9l7lsizOn9se8Lj692FOXWsAjVqodp+A+ew8mUYNBjrOZnPDq HMo/yV7iYHNMUFHOOa7baeUO5M84KIGwTvaWIhMtb7QsRIn3KkJaxBL75LbTjtAa odBrXv+/3K2aG0s7rVGtykmWaWmmo/fln27wtZTo0jzLikw3l/iSNsW7qy3RZWKh g48nf+yNlFPhUpcNnvtjdziw04aCT9KGLfJ8csY5inM5LgLs9TcXCYoHyFqyNWeD f0+dEbUDTp/ATppz6cCovjpFbBS6wKfg1k3JoVBNtrVOyu7+qgTQi58JnVpmLdBx s7msIWf/LlIiA9Jz0RKEdFbRBw1UVc45Zxse8gzVRnCxIwywFEuXDPQ0a3UxnQ1c Te0/QQ/rodS/WpELhhu3DGq3aONbznuP/NzQRSQpe1Oqr56+ATiiUo7ITXjm7fpW iqJ9I0BfeyrP/mI3cs2D8V6hOHqrlgdOSgoUwjpNcZCkO2yo/vl0Sk/NEhMhfHYO Wn3Dc/dQYwgFjqL1UW4WGKe/j/SW/JFLyb0+r/mIDq8Z2en1kBSHWBtvRu2hoFc+ mMZ2UpwxBXF71zeslajuGIZ/tfIsHmGLjj6BsRQcdbinEodwIJnlDb5y/KmsBV0w Yyigteth/aK/m3ikDCGs =qxER -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 04:35:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 091B3977; Wed, 30 Apr 2014 04:35:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD0341441; Wed, 30 Apr 2014 04:35:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3U4ZAwO093733; Wed, 30 Apr 2014 04:35:10 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3U4ZAga093727; Wed, 30 Apr 2014 04:35:10 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 30 Apr 2014 04:35:10 GMT Message-Id: <201404300435.s3U4ZAga093727@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 04:35:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:09.openssl Security Advisory The FreeBSD Project Topic: OpenSSL use-after-free vulnerability Category: contrib Module: openssl Announced: 2014-04-30 Affects: FreeBSD 10.x. Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: CVE-2010-5298 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. OpenSSL context can be set to a mode called SSL_MODE_RELEASE_BUFFERS, which requests the library to release the memory it holds when a read or write buffer is no longer needed for the context. II. Problem Description The buffer may be released before the library have finished using it. It is possible that a different SSL connection in the same process would use the released buffer and write data into it. III. Impact An attacker may be able to inject data to a different connection that they should not be able to. IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, or not using SSL_MODE_RELEASE_BUFFERS and use the same process to handle multiple SSL connections, are not vulnerable. The FreeBSD base system service daemons and utilities do not use the SSL_MODE_RELEASE_BUFFERS mode. However, many third party software uses this mode to reduce their memory footprint and may therefore be affected by this issue. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch.asc # gpg --verify openssl.patch.asc Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r265122 releng/10.0/ r265124 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYHsHAAoJEO1n7NZdz2rn2EsP+wYlobS4EiYtgspXAFgKLha1 0aeA7UokUs21QRTV9tIiFD0Se5HwdmHdh94bRJMRFraU22QYbAelG5GPsZPdRCt4 0ECLKUBDK6ng2M7UNyKhkstsL0+wBq6y5dzKjpR49QX4Vh2zEUYw5BcC5vrIk+YK Qazq8l1t5bl9ebm9rIDmd2uCv/Qe1MgnMlAczeH9HckfzMiH6NhnAuiYpP7K0mIL By6gpSxsHPeQShgJN/5kJjVGkdQK1/A1q0KnNf5r/itQdSC96NazKpCCpkud6RMm k9aPxI5As5Scl70zuCUDAS6vbNI3dvzCU46k8t65/FTeYQO2lxje0QZpqaDiB3+2 tbN5kDviQdWHlJyygCeNK3jxdv0H3+zUZidjPuo158Zcbhb4ckTEZtMtgTn0fRoY alG8qLn3hLj51fPHQK3Ff96xL+1DrhT+3D18OYIbjx7LKtsJJbnorB3jrbW68Ggr h0bW+8yAm1jDFM4kPQw6gcrmtyjxNhnVRLoeoBPSIkmS9cm+12YcXufbSyLm/WqG hkpPCrvUXibZmLi0CDlRMhLkjaOUhEXQsV3OR0gCmuFtN52gncyrIoPaxs79HZ1A g2JxLp7b56B2XOyakEmNc+rqJJkzi+LV8HTp5DcrbXjAunYk9ipfxPakqXFDD6jV L3ElC6aFDJ2UchtmjBRk =Y+tE -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 08:21:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B36558C8 for ; Wed, 30 Apr 2014 08:21:20 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 706B21082 for ; Wed, 30 Apr 2014 08:21:20 +0000 (UTC) Received: from [10.10.2.24] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 8010A211C5D for ; Wed, 30 Apr 2014 08:21:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 8010A211C5D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1398846069; bh=vc48mTTAPpK4MSAgy0FR8bLnXIZ3aKNaVKNFDtw4b5M=; h=Date:From:To:Subject:References:In-Reply-To; b=qpptSW2tcrIWdmtJ0WHrqjtt1UmMm/YmPvTh6zehocR1l8ZlM/0cLhzRYZ+cOsov1 7E/0ilqXxxa2NjE3i7xDB+lAqWSZRBPqN3/C/qp9i3F3Kt99LTSeAhJwVOPJZvtnwL zDMHB8pB6gVQwmgN020x62DJ7gu0hTwb23uJUIAOKpbNGgud1Fvqavc20HMesVALCU 28QhrCcXylSWa2lQCi/EUAeU2t1jR3ICpstX4sMaKtB/WBE7Gw+zvJUs+0Y+6JK/0X HA1JcLEAQSqFnafc1PfYomHaRIbnY17BX4NHDKEgQihuR0+JchgpCKMFy0M1L5MTAj 2qZBll8xkfHEQ== Message-ID: <5360B273.102@gibfest.dk> Date: Wed, 30 Apr 2014 10:21:07 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> In-Reply-To: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 08:21:20 -0000 On 30-04-2014 06:35, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-14:08.tcp Security Advisory > The FreeBSD Project > > Topic: TCP reassembly vulnerability > Hello everyone, Does anyone have a PoC exploit for this ? I want to see what we can do in IPS and so on at $work to protect against this until the patches can be applied. Thanks! /Thomas From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 09:23:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87DB447E for ; Wed, 30 Apr 2014 09:23:18 +0000 (UTC) Received: from mail1.canodus2.canodus.be (mail1.canodus2.canodus.be [83.149.89.9]) by mx1.freebsd.org (Postfix) with ESMTP id 35C69169B for ; Wed, 30 Apr 2014 09:23:18 +0000 (UTC) Received: by mail1.canodus2.canodus.be (Postfix, from userid 65534) id 45C6A32AD65; Wed, 30 Apr 2014 11:16:50 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail1.canodus2.canodus.be X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from [192.168.1.35] (d51532D1F.access.telenet.be [81.83.45.31]) by mail1.canodus2.canodus.be (Postfix) with ESMTPSA id C667E32AC39 for ; Wed, 30 Apr 2014 11:16:49 +0200 (CEST) Message-ID: <1398849409.4521.12.camel@debian.wout-t440s> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs From: Wout =?ISO-8859-1?Q?Decr=E9?= To: freebsd-security@freebsd.org Date: Wed, 30 Apr 2014 11:16:49 +0200 In-Reply-To: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> Organization: Canodus Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 09:23:18 -0000 On Wed, 2014-04-30 at 04:35 +0000, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-14:07.devfs Security Advisory > The FreeBSD Project > > Topic: devfs rules not applied by default for jails > > Category: core > Module: etc_rc.d > Announced: 2014-04-30 > Affects: FreeBSD 10.0 > Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) > CVE Name: CVE-2014-3001 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > The device file system, or devfs(5), provides access to kernel's device > namespace in the global file system namespace. > > The devfs(5) rule subsystem provides a way for the administrator of a system > to control the attributes of DEVFS nodes. Each DEVFS mount-point has a > ``ruleset'', or a list of rules, associated with it, allowing the > administrator to change the properties, including the visibility, of certain > nodes. > > II. Problem Description > > The default devfs rulesets are not loaded on boot, even when jails are used. > Device nodes will be created in the jail with their normal default access > permissions, while most of them should be hidden and inaccessible. > > III. Impact > > Jailed processes can get access to restricted resources on the host system. > For jailed processes running with superuser privileges this implies access > to all devices on the system. This level of access could lead to information > leakage and privilege escalation. > > IV. Workaround > > Systems that do not run jails are not affected. > > The system administrator can do the following to load the default ruleset: > > /etc/rc.d/devfs onestart > > Then apply the default ruleset for jails on a devfs mount using: > > devfs -m ${devfs_mountpoint} rule -s 4 applyset > > Or, alternatively, the following command will apply the ruleset over all devfs > mountpoints except the host one: > > mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | \ > xargs -n 1 -J % devfs -m % rule -s 4 applyset > > After this, the system administrator should add the following configuration > to /etc/rc.conf to make it permanent, so the above operations do not have > to be done each time the host system reboots. > > devfs_load_rulesets="YES" I have always used the following rc.conf options to start jails: jail_xxx_devfs_enable="YES" jail_xxx_devfs_ruleset="devfsrules_jail" If jail_xxx_devfs_enable is set to NO, would there be a problem? I thought you always had to set jail_xxx_devfs_ruleset when enabling devfs on jails. I think this has the same effect as the workaround above? > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch > # fetch http://security.FreeBSD.org/patches/SA-14:07/devfs.patch.asc > # gpg --verify devfs.patch.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # install -o root -g wheel -m 444 etc/defaults/rc.conf /etc/defaults/ > > Follow the steps described in the "Workaround" section, or reboot the > system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > ------------------------------------------------------------------------- > stable/10/ r265122 > releng/10.0/ r265124 > ------------------------------------------------------------------------- > > 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 > > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 05:36:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BA26D60 for ; Wed, 30 Apr 2014 05:36:11 +0000 (UTC) Received: from fate.ctgameinfo.com (ns1.ctgameinfo.com [184.172.20.152]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 51B7F1FAB for ; Wed, 30 Apr 2014 05:36:10 +0000 (UTC) Received: from [192.168.2.10] (S0106687f749dc87e.vs.shawcable.net [184.65.77.230]) by fate.ctgameinfo.com (Postfix) with ESMTPA id 380344513F for ; Tue, 29 Apr 2014 22:27:17 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at spamass Message-ID: <536089BC.3060002@ctgameinfo.com> Date: Tue, 29 Apr 2014 22:27:24 -0700 From: Cstdenis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-14:09.openssl References: <201404300435.s3U4ZA17093706@freefall.freebsd.org> In-Reply-To: <201404300435.s3U4ZA17093706@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 Apr 2014 11:24:14 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 05:36:11 -0000 Based on the CVE, it looks like older versions may also be vulnerable. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5298 On 4/29/2014 9:35 PM, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-14:09.openssl Security Advisory > The FreeBSD Project > > Topic: OpenSSL use-after-free vulnerability > > Category: contrib > Module: openssl > Announced: 2014-04-30 > Affects: FreeBSD 10.x. > Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) > CVE Name: CVE-2010-5298 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is > a collaborative effort to develop a robust, commercial-grade, full-featured > Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) > and Transport Layer Security (TLS v1) protocols as well as a full-strength > general purpose cryptography library. > > OpenSSL context can be set to a mode called SSL_MODE_RELEASE_BUFFERS, which > requests the library to release the memory it holds when a read or write buffer > is no longer needed for the context. > > II. Problem Description > > The buffer may be released before the library have finished using it. It is > possible that a different SSL connection in the same process would use the > released buffer and write data into it. > > III. Impact > > An attacker may be able to inject data to a different connection that they > should not be able to. > > IV. Workaround > > No workaround is available, but systems that do not use OpenSSL to implement > the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) > protocols, or not using SSL_MODE_RELEASE_BUFFERS and use the same process > to handle multiple SSL connections, are not vulnerable. > > The FreeBSD base system service daemons and utilities do not use the > SSL_MODE_RELEASE_BUFFERS mode. However, many third party software uses this > mode to reduce their memory footprint and may therefore be affected by this > issue. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch > # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch.asc > # gpg --verify openssl.patch.asc > > Restart all deamons using the library, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/10/ r265122 > releng/10.0/ r265124 > - ------------------------------------------------------------------------- > > 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 v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTYHsHAAoJEO1n7NZdz2rn2EsP+wYlobS4EiYtgspXAFgKLha1 > 0aeA7UokUs21QRTV9tIiFD0Se5HwdmHdh94bRJMRFraU22QYbAelG5GPsZPdRCt4 > 0ECLKUBDK6ng2M7UNyKhkstsL0+wBq6y5dzKjpR49QX4Vh2zEUYw5BcC5vrIk+YK > Qazq8l1t5bl9ebm9rIDmd2uCv/Qe1MgnMlAczeH9HckfzMiH6NhnAuiYpP7K0mIL > By6gpSxsHPeQShgJN/5kJjVGkdQK1/A1q0KnNf5r/itQdSC96NazKpCCpkud6RMm > k9aPxI5As5Scl70zuCUDAS6vbNI3dvzCU46k8t65/FTeYQO2lxje0QZpqaDiB3+2 > tbN5kDviQdWHlJyygCeNK3jxdv0H3+zUZidjPuo158Zcbhb4ckTEZtMtgTn0fRoY > alG8qLn3hLj51fPHQK3Ff96xL+1DrhT+3D18OYIbjx7LKtsJJbnorB3jrbW68Ggr > h0bW+8yAm1jDFM4kPQw6gcrmtyjxNhnVRLoeoBPSIkmS9cm+12YcXufbSyLm/WqG > hkpPCrvUXibZmLi0CDlRMhLkjaOUhEXQsV3OR0gCmuFtN52gncyrIoPaxs79HZ1A > g2JxLp7b56B2XOyakEmNc+rqJJkzi+LV8HTp5DcrbXjAunYk9ipfxPakqXFDD6jV > L3ElC6aFDJ2UchtmjBRk > =Y+tE > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-announce@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 11:09:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B91E8C1 for ; Wed, 30 Apr 2014 11:09:31 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 630FE11AB for ; Wed, 30 Apr 2014 11:09:31 +0000 (UTC) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s3UB9FNl099557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 30 Apr 2014 12:09:20 +0100 (BST) (envelope-from matthew@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s3UB9FNl099557 Authentication-Results: smtp.infracaninophile.co.uk/s3UB9FNl099557; dkim=none reason="no signature"; dkim-adsp=none X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <5360D9CF.6000103@freebsd.org> Date: Wed, 30 Apr 2014 12:09:03 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <201404300435.s3U4ZA45093722@freefall.freebsd.org> In-Reply-To: <201404300435.s3U4ZA45093722@freefall.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2PK2AXvijDGFIqERQB1mk36GOmfLmqsmP" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-Mailman-Approved-At: Wed, 30 Apr 2014 12:41:20 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 11:09:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2PK2AXvijDGFIqERQB1mk36GOmfLmqsmP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/30/14 05:35, FreeBSD Security Advisories wrote: > Then apply the default ruleset for jails on a devfs mount using: >=20 > devfs -m ${devfs_mountpoint} rule -s 4 applyset >=20 > Or, alternatively, the following command will apply the ruleset over al= l devfs > mountpoints except the host one: >=20 > mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | \ > xargs -n 1 -J % devfs -m % rule -s 4 applyset >=20 > After this, the system administrator should add the following configura= tion > to /etc/rc.conf to make it permanent, so the above operations do not ha= ve > to be done each time the host system reboots. >=20 > devfs_load_rulesets=3D"YES" >=20 Verb. Sap. Doing this in a jail where you're running net-snmpd will prevent snmpd from starting up correctly. Apr 30 12:02:30 xxxxx snmpd[33871]: init_kmem: kvm_openfiles failed: /dev/mem: No such file or directory Apr 30 12:02:30 xxxxx snmpd[33871]: Agent initialization failed Cheers, Matthew --2PK2AXvijDGFIqERQB1mk36GOmfLmqsmP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYNnaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnMAgP/3aGdt4LGLa8c5q+AAKR+1j6 FUGVLCVEhH5V1uDOTopXcsRUPBFDGmXGCtLEji21tHOu39fDis2zMBTsvonfReJE 5htGoJDWAQqqLUfep97BiN9Hh9kw+lqn26i2i3vDHjgk3Dmp5r0UGVa9FatLyLuL j/rVynFVf/+fotP4nXon4OoMw8f9PXGpujuzrL95s4VSNtORdW4zyep5NQaOhJ5r Lc8UPvGn9mEeWe07bXB3BRGVyevqNW7OmKrZKVwTRNaVVgYQn60f43iJ+FKkiS8B s/fJ3GJh0KxaMuNMqGXP5Eglg06S5Y53SXPkZNnZVnIISKd9Rl6XbXLjaQuaNuna OxlB/gvba0gNC1GmP+ZA82F1wpFDTWHvRa6d1d5lSQNtmh28dacn69EupMuzghEm UIPIb3y/TGqapItxpsh/WYgPS6tXTpyMamIMKCJTkzTW6pfejuEO4Tn5n4SkZRCx GwnCmjDdbJUH9zLOkmYN3M3NxV+7xWCVX+mMF2O9D+np1/8zkHt0WDWoAISYf1P/ uS7kudfTeFqpxQH0bu0mZUIsl4ztay7+ICUUMpC1csg6w0P+jK3WNRZO2qUYHH04 dtD/Eb40TVedbPVSm5eNCqqUY4+93JtDo2xolQmo2opHcXpPwkQPt3nvqwdd9RBQ elHWMBFy0kfTB6l/f+20 =RA2A -----END PGP SIGNATURE----- --2PK2AXvijDGFIqERQB1mk36GOmfLmqsmP-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 12:58:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD363282 for ; Wed, 30 Apr 2014 12:58:56 +0000 (UTC) Received: from chroot.pl (unknown [IPv6:2001:470:1f0b:3ba::3]) by mx1.freebsd.org (Postfix) with ESMTP id 048431D36 for ; Wed, 30 Apr 2014 12:58:56 +0000 (UTC) Message-ID: <5360F38B.3000205@chroot.pl> Date: Wed, 30 Apr 2014 14:58:51 +0200 From: Lukasz User-Agent: WebMail MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl References: <201404300435.s3U4ZAga093727@freefall.freebsd.org> In-Reply-To: <201404300435.s3U4ZAga093727@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.1 at chroot.pl X-Virus-Status: Clean X-Spam-Status: No, score=-0.9 required=3.0 tests=ALL_TRUSTED,MISSING_MID autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on chroot.pl X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 12:58:56 -0000 Hi! Is there something missing in this SA? 2) "b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in ." Regards. On 04/30/2014 06:35 AM, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-14:09.openssl Security Advisory > The FreeBSD Project > > Topic: OpenSSL use-after-free vulnerability > > Category: contrib > Module: openssl > Announced: 2014-04-30 > Affects: FreeBSD 10.x. > Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) > CVE Name: CVE-2010-5298 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is > a collaborative effort to develop a robust, commercial-grade, full-featured > Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) > and Transport Layer Security (TLS v1) protocols as well as a full-strength > general purpose cryptography library. > > OpenSSL context can be set to a mode called SSL_MODE_RELEASE_BUFFERS, which > requests the library to release the memory it holds when a read or write buffer > is no longer needed for the context. > > II. Problem Description > > The buffer may be released before the library have finished using it. It is > possible that a different SSL connection in the same process would use the > released buffer and write data into it. > > III. Impact > > An attacker may be able to inject data to a different connection that they > should not be able to. > > IV. Workaround > > No workaround is available, but systems that do not use OpenSSL to implement > the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) > protocols, or not using SSL_MODE_RELEASE_BUFFERS and use the same process > to handle multiple SSL connections, are not vulnerable. > > The FreeBSD base system service daemons and utilities do not use the > SSL_MODE_RELEASE_BUFFERS mode. However, many third party software uses this > mode to reduce their memory footprint and may therefore be affected by this > issue. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch > # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch.asc > # gpg --verify openssl.patch.asc > > Restart all deamons using the library, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > ------------------------------------------------------------------------- > stable/10/ r265122 > releng/10.0/ r265124 > ------------------------------------------------------------------------- > > 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 > > _______________________________________________ > 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 Wed Apr 30 13:55:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EDD89CD for ; Wed, 30 Apr 2014 13:55:20 +0000 (UTC) Received: from ns1.mdounin.ru (ns1.mdounin.ru [88.198.19.180]) by mx1.freebsd.org (Postfix) with ESMTP id 3208714CD for ; Wed, 30 Apr 2014 13:55:19 +0000 (UTC) Received: from mdounin.ru (ns1.mdounin.ru [88.198.19.180]) by ns1.mdounin.ru (Postfix) with ESMTP id 34870ED8C00; Wed, 30 Apr 2014 17:47:07 +0400 (MSK) Date: Wed, 30 Apr 2014 17:47:07 +0400 From: Maxim Dounin To: Cstdenis Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-14:09.openssl Message-ID: <20140430134706.GD34696@mdounin.ru> References: <201404300435.s3U4ZA17093706@freefall.freebsd.org> <536089BC.3060002@ctgameinfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536089BC.3060002@ctgameinfo.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:55:20 -0000 Hello! On Tue, Apr 29, 2014 at 10:27:24PM -0700, Cstdenis wrote: > Based on the CVE, it looks like older versions may also be vulnerable. > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5298 Information on the link in question is misleading. Affected code appeared in OpenSSL 1.0.0 and doesn't exists in previous versions, hence this problem only affects FreeBSD 10.x. -- Maxim Dounin http://nginx.org/ From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 13:56:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A2CDAED for ; Wed, 30 Apr 2014 13:56:52 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 23F061510 for ; Wed, 30 Apr 2014 13:56:52 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.8/8.14.8) with ESMTP id s3UDukea093973 for ; Wed, 30 Apr 2014 09:56:46 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <53610127.5000603@sentex.net> Date: Wed, 30 Apr 2014 09:56:55 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> In-Reply-To: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:56:52 -0000 On 4/30/2014 12:35 AM, FreeBSD Security Advisories wrote: > IV. Workaround > > It is possible to defend to these attacks by doing traffic normalization > using a firewall. This can be done by including the following /etc/pf.conf > configuration: > > scrub in all Hi, Is this the only pf option that will work, or is scrub fragment reassemble sufficient ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:45:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6CB8538; Wed, 30 Apr 2014 18:45:18 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CCAD015FA; Wed, 30 Apr 2014 18:45:18 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 53A4E23E36; Wed, 30 Apr 2014 11:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398883511; bh=ZvRcMQ8mkiDqzflfgfSPZ+J4o0SoCtr5bJzg2jLXg0g=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=u0nj9IFCR8jBuMZqKNCeJVj4ZUr2AE7K65fTHzrIvZZCuXwaueqxhr+dFSNXRDGZT 2n821bx3ue5TBskh/JkK1f+3nGUx9OwiuS3lGM4ltSQ0c/6G7DYsgoMIHHTReQSrOq fOQC3IkBIFOQyThephfpGUiIjiguRRDED0nmjNt8= Message-ID: <536144B6.7030305@delphij.net> Date: Wed, 30 Apr 2014 11:45:10 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Matthew Seaman , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <201404300435.s3U4ZA45093722@freefall.freebsd.org> <5360D9CF.6000103@freebsd.org> In-Reply-To: <5360D9CF.6000103@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:45:19 -0000 On 04/30/14 04:09, Matthew Seaman wrote: > On 04/30/14 05:35, FreeBSD Security Advisories wrote: >> Then apply the default ruleset for jails on a devfs mount using: >> >> devfs -m ${devfs_mountpoint} rule -s 4 applyset >> >> Or, alternatively, the following command will apply the ruleset >> over all devfs mountpoints except the host one: >> >> mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | >> \ xargs -n 1 -J % devfs -m % rule -s 4 applyset >> >> After this, the system administrator should add the following >> configuration to /etc/rc.conf to make it permanent, so the above >> operations do not have to be done each time the host system >> reboots. >> >> devfs_load_rulesets="YES" >> > > Verb. Sap. Doing this in a jail where you're running net-snmpd > will prevent snmpd from starting up correctly. > > Apr 30 12:02:30 xxxxx snmpd[33871]: init_kmem: kvm_openfiles > failed: /dev/mem: No such file or directory Apr 30 12:02:30 xxxxx > snmpd[33871]: Agent initialization failed This is pretty much expected behavior. The reason is that /dev/mem provides an interface to physical memory, this would have defeated the purpose of doing jails by definition. It would be interesting to find out if we could teach net-snmpd to use alternative methods to access data it needs, e.g. via sysctl I think? Not all data are exposed via sysctl at this time, though. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:46:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6F7A61E for ; Wed, 30 Apr 2014 18:46:01 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBB671616 for ; Wed, 30 Apr 2014 18:46:01 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 45D9523F52; Wed, 30 Apr 2014 11:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398883561; bh=pwgOt4wsBvZFrCyEIPnn5tTqzoKyj8SLUys0dQ2Gu84=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=BYsednDjALXYDHNZjyGQEgrn8QLsjk1CIgIDvtW1c8v8DPUpiPot/a9KMx1LnOhso ZRfHFBsoluelxXj16tm7IKXuR2ruQ8LY/ZJ167jtOkUIuqHK4cHLsiTtaOsY6/564S wjFTQ8wL5jsBWlJEWa3NaytN7KxdO53eEM56FfU4= Message-ID: <536144E8.4020502@delphij.net> Date: Wed, 30 Apr 2014 11:46:00 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wout_Decr=E9?= , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> <1398849409.4521.12.camel@debian.wout-t440s> In-Reply-To: <1398849409.4521.12.camel@debian.wout-t440s> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:46:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/30/14 02:16, Wout Decré wrote: > On Wed, 2014-04-30 at 04:35 +0000, FreeBSD Security Advisories > wrote: >> ============================================================================= >> >> FreeBSD-SA-14:07.devfs Security Advisory >> The FreeBSD Project >> >> Topic: devfs rules not applied by default for jails >> >> Category: core Module: etc_rc.d Announced: >> 2014-04-30 Affects: FreeBSD 10.0 Corrected: >> 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 >> 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: >> CVE-2014-3001 >> >> For general information regarding FreeBSD Security Advisories, >> including descriptions of the fields above, security branches, >> and the following sections, please visit >> . >> >> I. Background >> >> The device file system, or devfs(5), provides access to kernel's >> device namespace in the global file system namespace. >> >> The devfs(5) rule subsystem provides a way for the administrator >> of a system to control the attributes of DEVFS nodes. Each DEVFS >> mount-point has a ``ruleset'', or a list of rules, associated >> with it, allowing the administrator to change the properties, >> including the visibility, of certain nodes. >> >> II. Problem Description >> >> The default devfs rulesets are not loaded on boot, even when >> jails are used. Device nodes will be created in the jail with >> their normal default access permissions, while most of them >> should be hidden and inaccessible. >> >> III. Impact >> >> Jailed processes can get access to restricted resources on the >> host system. For jailed processes running with superuser >> privileges this implies access to all devices on the system. >> This level of access could lead to information leakage and >> privilege escalation. >> >> IV. Workaround >> >> Systems that do not run jails are not affected. >> >> The system administrator can do the following to load the default >> ruleset: >> >> /etc/rc.d/devfs onestart >> >> Then apply the default ruleset for jails on a devfs mount using: >> >> devfs -m ${devfs_mountpoint} rule -s 4 applyset >> >> Or, alternatively, the following command will apply the ruleset >> over all devfs mountpoints except the host one: >> >> mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | >> \ xargs -n 1 -J % devfs -m % rule -s 4 applyset >> >> After this, the system administrator should add the following >> configuration to /etc/rc.conf to make it permanent, so the above >> operations do not have to be done each time the host system >> reboots. >> >> devfs_load_rulesets="YES" > > I have always used the following rc.conf options to start jails: > > jail_xxx_devfs_enable="YES" > jail_xxx_devfs_ruleset="devfsrules_jail" > > If jail_xxx_devfs_enable is set to NO, would there be a problem? I > thought you always had to set jail_xxx_devfs_ruleset when enabling > devfs on jails. > > I think this has the same effect as the workaround above? Assuming the jail have no access to the device file system at all, you would not be affected by the problem. Setting jail_*_devfs_ruleset by itself is not sufficient because a recent change (only in 10.x) have removed the loading of default rules, making setting the rule set no-op. No, you don't have to set per-jail ruleset explicitly, the default is devfsrules_jail unless overridden. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYUToAAoJEJW2GBstM+nsnCEP/RnPDhR+QmvOhbdRwKeuDdcn SmcDtm+LmJSCxMfkVdDEuskQiI474xfrkGe6+6iIFkjilTU3/0xdKo4eIybp3ARd osYHJg9zUINIzHh2ez9CR+IqzYS/FD1jWMShhoB/qqWJayclXyz+HdfLCcryOQDn oYwneuYBRTKLSvViBAbq0pQmfzQX9mmeoSm8rR0lHuOdAfDTNyYKrod7Gku62BHL 2WZmXlgIFVsn+F3k0Ay2eG36D0ZxoAe/gQVhA3VAjSQXsgzWXmUccwpiPqK32mba gfRVfnC+ARdW0EQxWk258Z5oaAuLWXq2ntaVyr0RjODHXZr2Wi7nDRHSxczDGCrk yMSdcvHhSOx7dJxRkTashCS+5wwf2yPHChYI7t5XgO2aXukLlOTvM/HHKs0KZiyE MP1hNjujXu3t6JcIDLcuOogn2YrRYtkprphpjn0W3fN6dOjn2cyjn2o0fRoORerW ouqaunygcdCxWHUVWJeyql5aTPUJNMPEhkE/xIHNDtwlg9SNVUopMUsHzTN++yMB QEwMH91p4YaUnllW3u4At6WishkiwObIr6Ygtz7YvJja45F8g5ftRaOUdNNWONse WHDh/e0sxV6RIGr/yr28h2NVk2Kxqu7bP6XyVIV1F/qtuXkJPYyE5x9/DERreeYw 9sXDbKH7qzj/ANF4kUsY =bdkk -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:48:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C742F738 for ; Wed, 30 Apr 2014 18:48:45 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A0981655 for ; Wed, 30 Apr 2014 18:48:45 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id to1so2442256ieb.16 for ; Wed, 30 Apr 2014 11:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=HxTzoDQXlF+iedlw3Q58GY1yY7bFT8R2MeWWXV9qMN4=; b=LI1pRomWA3jHCFhCzmre/cFDuVEsiRrIoqqShG05YQ35guwAoKZqjyiYYXS0KpFciK XcTsE4o3blvZVX+ArQiIfczBqRU9ekHPH+OL/0Z4P7PpYVpWa5e8r7d5NSx861vIYc0I sZCnfsNCmd0Rom3bJE0yB1chGK/D18wrsbQBo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=HxTzoDQXlF+iedlw3Q58GY1yY7bFT8R2MeWWXV9qMN4=; b=WRDJ5wpSISEO0Cj+hCYL6rNyBPUK6yP24LO7gjcapFFTZRIdmP9gLBTYl5iDWL8KxZ NG577hz9cKasEmUBHFezno11VWNpzMfj7jpCFHCb8NH5OQ8nhVkLL03sNUErcXxy+WA2 zp3Sp4e+1qpQqVSQfpSDZhy2ibAbo3BNFrLmDiq3AB8xOS2lsj3c8FOTPvVUtAN1y9P4 MPCwfpZ5ff/5xWwHSUSfrbYs932XnadlfPrXSHHtjQkqZK2Rt1ubbQxf6CNei1TzlLiY RvhjiVlEZ9z7YMdU7pt02ENMBwU4Ry9dlNBOiAGkTPakiCAsV3EiRedw6NatCtjBxLnl aZmQ== X-Gm-Message-State: ALoCoQkHl5jJ+lhMRHQ0nLagY/93yg6mkwjU7nMuMmaYHdiNgzsgKEeqJ52dB7fR2COWgzgsYaD2 X-Received: by 10.50.154.66 with SMTP id vm2mr7210935igb.4.1398883724766; Wed, 30 Apr 2014 11:48:44 -0700 (PDT) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPSA id vc5sm8217816igb.3.2014.04.30.11.48.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 11:48:43 -0700 (PDT) From: Kevin Day Content-Type: multipart/signed; boundary="Apple-Mail=_EE42CB53-5F9E-4563-8BA5-F058FB7EC749"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <6D007FDB-D94D-48BD-B066-30A23F9CB472@dragondata.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.0\)) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Date: Wed, 30 Apr 2014 13:48:41 -0500 References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> To: freebsd-security@freebsd.org In-Reply-To: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> X-Mailer: Apple Mail (2.1878) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:48:45 -0000 --Apple-Mail=_EE42CB53-5F9E-4563-8BA5-F058FB7EC749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Affects: All supported versions of FreeBSD. > Corrected: 2014-04-30 04:04:20 UTC (stable/8, 8.4-STABLE) > 2014-04-30 04:05:47 UTC (releng/8.4, 8.4-RELEASE-p9) > 2014-04-30 04:05:47 UTC (releng/8.3, 8.3-RELEASE-p16) > 2014-04-30 04:04:20 UTC (stable/9, 9.2-STABLE) > 2014-04-30 04:05:47 UTC (releng/9.2, 9.2-RELEASE-p5) > 2014-04-30 04:05:47 UTC (releng/9.1, 9.1-RELEASE-p12) > 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) Does anyone know the lower bound for how far back this bug exists? Is it = only present in the above versions, or does it affect earlier versions = that aren=92t listed? (trying to come up with a deployment plan for some servers stuck on 8.1 = and 7.x due to vendors abandoning device drivers) =97 Kevin --Apple-Mail=_EE42CB53-5F9E-4563-8BA5-F058FB7EC749 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPLzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSwwggQUoAMC AQICEQDbETdDYf7wYKjx8ymk38yAMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMDYxNjAwMDAwMFoXDTE0MDYxNjIzNTk1OVowJjEkMCIGCSqG SIb3DQEJARYVdG9hc3R5QGRyYWdvbmRhdGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAvoIO+cLWLe7YYAGV/WdoWC85K8uIgstlYMg/bC8eGbC7AY/nuQXpRV5+xlTXgN7qry/m 6XErlaw1U3rmwlNyjMhJdYaPZclywBKKpYnc3sp0q2A6naeVmOF/t4QDImtfc3sV7SaEkIr7zssK MFTnkOX57g1r3MuiYoHBx1cMaWXYCJ5LDzsynwHGAExYuziRzXcu4sRZ1HBJlQ8hM3yhTTGGOQv1 H1ky13a1RxXC+uoTtYFyrxdBgPUd4eGF1tILHtK9NXnU6lhey90wDa2jmQOJQErgYuYPZriSuBXz QobK7tGcjMBgBQ1U+gxaTyThbXgxfb1MTjDx46hSl8Z35wIDAQABo4IB5TCCAeEwHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFO9wHp89I1B980w64KR38bmtuHFYMA4G A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZG aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0 MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVdG9hc3R5 QGRyYWdvbmRhdGEuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCBaQ8dcaprzzREiMtsc2UtOPSHFiCy dcd5OjE6BN+pkcQozhx3nol9dFKJ+YfGvIxIjHmDGFTOgJgJvjRZ0D1Hw2WJCEtyD+U6yi/cnDFu Ksl039qafzbah6ft2r+GM0QufuFmrBi/bTWU3lGuhL8TKOvsWeLFkyGqtv9AJz2vg7j7dpxutLQY NWnrt7nS2x6p4f1LXu3iwczefyNNFUYwE9zXAT0Uwn48g2iijuf9vekfpqtHBmfSu0tSfd3FS3JC hmFp1fMxnWOnuZ529HFtGeYzr1K8Tp+JEVPjzPCxymVFsZ945Vzj0kc0DT3f9N5Gdw6uybrUwupM NHJJCB9VMYIDrjCCA6oCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1h bmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EC EQDbETdDYf7wYKjx8ymk38yAMAkGBSsOAwIaBQCgggHZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDQzMDE4NDg0MlowIwYJKoZIhvcNAQkEMRYEFDjPlMoxk9KB ySOyd+Zmt+iVoqOcMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0ECEQDbETdDYf7wYKjx8ymk38yAMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANsRN0Nh/vBgqPHzKaTfzIAwDQYJKoZI hvcNAQEBBQAEggEAHhWBDurb1+v/1qgjhTJiyzWEXnV2rkVbnti1p/2f01pwnV16Q5weMCxebG4x pTjTytUWuUO75zHiQvm4yyKPeGNxEfQi/54ZPDVUfotku+euTJgHwbGhkQOloN51SbRmn79t0/Mq iwujC9cAjUHX77pvWjvWHXqlVbIO3xpYsS6n2FSHY5aQCybr7rXVC4KFtgRek0XoNMbTU2qIyXiJ 5o1lNoJbLROej/p6w3PWq0iErpGyCcTBgStH25Mr6Z8H6AWLBoYXeEYc/MuE+DnxM9UbJzac6Vba LjHt2t4vEJfAuNaDm5vVosiSElJV5YQTuWnPdtBjE24CNAdny9WhyAAAAAAAAA== --Apple-Mail=_EE42CB53-5F9E-4563-8BA5-F058FB7EC749-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:58:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 032C190C; Wed, 30 Apr 2014 18:58:42 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6A7E172B; Wed, 30 Apr 2014 18:58:41 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B3AE61B115; Wed, 30 Apr 2014 11:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398884320; bh=/rWPKXVWJGiRS9irQOIViK+mssmLKJTs7Yyal3/E/lw=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=Gfpfm0OLXMsBODa9NJEiz2BXZiPqNRRmsKo4xFfrTae/JqdvDE5CjJbqE4Z6jlaXT 66JCxsNjkTMD2NFXgej0I+qOBOM7VLVSX6AM0Vp/Lk2BvTqi1zD3pLapXOj86Qm7wM cEVhlQSttQg5WHWbwZd1iWiroT+xr6n+AFsAa9uY= Message-ID: <536147DE.5030703@delphij.net> Date: Wed, 30 Apr 2014 11:58:38 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Corey Smith , freebsd-security@freebsd.org, matthew@freebsd.org, d@delphij.net Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:58:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/30/14 11:51, Corey Smith wrote: >> It would be interesting to find out if we could teach net-snmpd >> to use alternative methods to access data it needs > > It is not necessary if you build net-mgmt/net-snmp with the > UNPRIVILEGED knob set. Will there be any lost functionality with that knob set? (I don't use net-snmp myself) If there is no lost functional, I think it's sensible to hard wire that option -- giving access to /dev/[k]mem makes me feel quite nervous, especially for network facing daemons... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYUfeAAoJEJW2GBstM+ns25oP/0zGN2rtZI16ilY/yE+vlbsm Is9j+DfbPKV99cffJHxTc6DCQjBTYpAEtr20LaWXBx3O4KpVuX+KZP5IMH0Rl1Et /2+o+MQHYhZ9j5osMofNZeqIesauSLmPhNzyyU0Q1F1yajonlHXD7oDNC88Hqyhj HRz+beEboz+B3tQEm+vNTIA88xQCuQOS32rjqGQ/RsmmY+vMS9x61OJAKA+bMtvq framYJvsZMdZQFzEpvb0VZvI/ZA5T7HtoXBdAJDsFtHn2E99iqcUgrpcDa1YtE5L 2VR+9SJgiKsLH09+L3DFB4hOqTir0X7EGdSZM5xiRCvVaReBcgESgHe9I4Un+xzC azbCzpSTAvM/u97DZdBnMHOCqeviHquwNgpgHy8H3u9Vz+I5nAQSNVFsp4SohgPk g6a4Bp4nvpx+H7V86+i+jjxvowtjV033oglAgNwjPRxpw25/vamA8dqbQT9zKW9Z fNx5DyEdIwq/aGHZSe4ybBTrZ3f6YZat7SUOfyA5zfICpte4sSf7+0puGLPha6VM RRWnnQtQojpmnBq3ycWk9pUFcyNN7RVDE9FFvD83vA2HCqV4iGkXeyr/Tk7fH81t Df4qzYIPXWF2Arm7nwvTFYmoj+GnStco8k+OqukNviPxO3lKQTVWAilvyY2/nfQK GOIXoW2YQLuViQur4pvP =ySJm -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 19:04:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50D21B5C for ; Wed, 30 Apr 2014 19:04:58 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 30DD41827 for ; Wed, 30 Apr 2014 19:04:58 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 5146D1B398; Wed, 30 Apr 2014 12:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398884697; bh=JSHsMaoRfZOPJaZsTHKVCPr2eENOUPTr+kkTn2Sm8zU=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=yCnxItHak6irUahoWv8u7CqkDTyVb0YeSpI7lZsxIT6YKCspqu/6zdB3UEkrJwbbh XnWuphXurrD5xHYxmSl9jRilC7wmJDrqnbq0BljXcy1tflfWy8LqO/1eifC8XCRlDC nTGborfnh1XdCsevSWZV5d2bMVl9zrWJrAstoZ/g= Message-ID: <53614958.40105@delphij.net> Date: Wed, 30 Apr 2014 12:04:56 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Lukasz , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl References: <201404300435.s3U4ZAga093727@freefall.freebsd.org> <5360F38B.3000205@chroot.pl> In-Reply-To: <5360F38B.3000205@chroot.pl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:04:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/30/14 05:58, Lukasz wrote: > Hi! > > Is there something missing in this SA? > > 2) > > "b) Execute the following commands as root: > > # cd /usr/src # patch < /path/to/patch > > Recompile the operating system using buildworld and installworld > as described in > ." Urgh I can't believe I made the same mistake twice. I have tweaked our template to prevent this from happening again, thanks for pointing this out. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYUlYAAoJEJW2GBstM+nsg0gP/1HT+6umvJKqFIbcBhEeVjvP l/pgeggVPtpPfigmMWSf6VjauOOm2TZOsejZXGlQdDHTkXft8wCSvCZgziLjOtrj YCZ9W3uEUcR+Co6JJNYgLOV9CSQlYcF5cBaInG+lY1/KwCE3dWjRgTCLi1LMCE8I LKXCz8Q9YGtiLGEPqsMSE2AqoZHpnkjHN3DwuShkgeGYAA4nodzKao3Mq9lN6QaO SDsfryH6Rx7SzdMJsG6UR+l7Vvp8Td1D25soM7dhuGDSS6bAOhhC7CDBJdtrtAnK dhM/sbtKOzT/2Lqo4W8tyD2+5BD6fW5PKqpASUHMHlxLHajpHxqp7VFBssdXuKF0 nGmfW4oGs4vDGwEsRd+uuDQFxo85jR+oR7FPl64qq2ioRTf417+jC+BW+IKifl1Y DvYpBF7ixcbQII1iC6fVqIBwzTPkyjMVCrGOKRh0keWa7Z4QSKNgJ1iqspIRI1Yd CFbw5pqcCDzdHwbEsXAyyJhTjEXNfa8GtY9GZnMe11Tdzc33AbDfmHodVQPrI2j6 r++pI7KrtGUwKQXV62DNPfxOkVIOHjKNS5OQ2bush0Cu7bZQD0H5O862sh2ojKum zx61rCUS03Y9hCd+VtycjMnptujEkGrLsKLcIo1jAhXSifVTNscwpz5DoYxPnIyD Y1yfp8Q9O2V2gXgw63YT =zOb8 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 19:06:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5E13CB7; Wed, 30 Apr 2014 19:06:30 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96CE91854; Wed, 30 Apr 2014 19:06:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3UJ6UIi017102; Wed, 30 Apr 2014 19:06:30 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3UJ6UCV017100; Wed, 30 Apr 2014 19:06:30 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 30 Apr 2014 19:06:30 GMT Message-Id: <201404301906.s3UJ6UCV017100@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl [REVISED] Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:06:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:09.openssl Security Advisory The FreeBSD Project Topic: OpenSSL use-after-free vulnerability Category: contrib Module: openssl Announced: 2014-04-30 Affects: FreeBSD 10.x. Corrected: 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: CVE-2010-5298 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 2014-04-30 Initial release. v1.1 2014-04-30 Added patch applying step in Solutions section. I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. OpenSSL context can be set to a mode called SSL_MODE_RELEASE_BUFFERS, which requests the library to release the memory it holds when a read or write buffer is no longer needed for the context. II. Problem Description The buffer may be released before the library have finished using it. It is possible that a different SSL connection in the same process would use the released buffer and write data into it. III. Impact An attacker may be able to inject data to a different connection that they should not be able to. IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, or not using SSL_MODE_RELEASE_BUFFERS and use the same process to handle multiple SSL connections, are not vulnerable. The FreeBSD base system service daemons and utilities do not use the SSL_MODE_RELEASE_BUFFERS mode. However, many third party software uses this mode to reduce their memory footprint and may therefore be affected by this issue. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:09/openssl.patch.asc # gpg --verify openssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r265122 releng/10.0/ r265124 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYUi5AAoJEO1n7NZdz2rnk/8QAMUvAUQzbd0PE8QYH2ZlnHuO fhY8xeIxXzK7/e4WOpXDmC68phxLcGQF4YRtX7Wu/yEchIk7cJPocx6kkht8CpCG t7BpgQOyWY7QRHkIg+hzcooWJFK8nS9miXrwI0vOgWNIbI+iNaSZwNcBsrqF45hI U1/Z6EWFqmEq+VJBtzpp6F7etYYn8OomBF0XFj13Dtr1UnuG+QqOF0c7FH4o0oiL +LpTPlgpubOR1wIx/7nR4j5VeXUwHK3Lrv9X5395YmLVca6pHzeG3pFjGuJJMf8E 9t4Y13EfnetO1AEX7Up86i2h28P8nTqmse+m60LAAwMuHpTRvzruQNvzBguv5Nb7 kVoZKbHb8Ji2rrUEQ//tEYcp57iry0ukvP3uzyvA8q17FeGvx/aJl9Wcc6s+Untd n2WbVvYLnGGNWWI35Yi5eo7TCKcj8z/s0Wgb0omWh7cz7YCjveoG/2x9BHwVGunf VxEmhXPW8HKSEVf/w/yEIAJIechpRv3q9y+Yh5vgMzVqwoP3nXESuQxpzm6Bx/2P 0ZV+IQNAGRXIBQWqjDqC0yZJ/8QNkp+NDRE8ZZHjxnJeQZCayCaEBmjQZcU9qRHP Y2eHu+AiDSi5j2hKyWwY59xlUJ+hBCejzSc0kGiuNq1GWIKltGZ48dnN+H4d4Z6C ZYF6H9F0ykvTxWFfVlFx =H1mN -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 18:51:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16822863; Wed, 30 Apr 2014 18:51:25 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 857FF16FD; Wed, 30 Apr 2014 18:51:24 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id z12so2156023wgg.22 for ; Wed, 30 Apr 2014 11:51:22 -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=pETRVUJ2uqig6GYSxGvWF19xjlb2KAbhTY6N+Z4pbsw=; b=j4cXbxmz5fSjT7TMeeQUZg6bZCFmficXj8+LLbnOF7/kPBRE+CDDHe7a/1B5f7sMMN xZZRsrT1lW+m8Tnl/yVeiDMAfW/z7ZRTZrFgM8UiHfcVM2ffY3RSZq+vgjLIqiw/uHI9 KRBzcqSS7gutVOFKzL8gKU+hbPuG44n8/2S/EddFv+ujPhTj8zxFSEEaT4+jw7EFQjop EE+mhgMBNBzZfwPMEDsgckL80+B98pbgr0PzhrBPd3NtxGqYLWsuxIZsrds3r0mLJ8vG d2insMn50BRrukvXMf2IgmXcu+FWL8EgR8jBYeI4zpVrHoVciHn4S5rCLFm+ixINasz/ N6Ng== MIME-Version: 1.0 X-Received: by 10.194.202.229 with SMTP id kl5mr199726wjc.86.1398883882733; Wed, 30 Apr 2014 11:51:22 -0700 (PDT) Received: by 10.194.179.70 with HTTP; Wed, 30 Apr 2014 11:51:22 -0700 (PDT) Date: Wed, 30 Apr 2014 14:51:22 -0400 Message-ID: Subject: RE: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs From: Corey Smith To: freebsd-security@freebsd.org, matthew@freebsd.org, d@delphij.net X-Mailman-Approved-At: Wed, 30 Apr 2014 19:18:32 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:51:25 -0000 > It would be interesting to find out if we could teach net-snmpd to use > alternative methods to access data it needs It is not necessary if you build net-mgmt/net-snmp with the UNPRIVILEGED knob set. -Corey Smith From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 19:25:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B34773F for ; Wed, 30 Apr 2014 19:25:54 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DBB91BC5 for ; Wed, 30 Apr 2014 19:25:53 +0000 (UTC) Received: from [192.168.0.100] ([87.139.233.65]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXmpv-1WKw4k1Nbj-00Wlvs; Wed, 30 Apr 2014 21:25:45 +0200 Message-ID: <53614E7C.2040703@gmx.de> Date: Wed, 30 Apr 2014 21:26:52 +0200 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl [REVISED] References: <201404301906.s3UJ6UCV017100@freefall.freebsd.org> In-Reply-To: <201404301906.s3UJ6UCV017100@freefall.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Z9wr7iALpRcjRJGT8HOa0Q4hkoaptbVwXfSvHm/GaunVY5n3ZWK MJKinFToeUNq6NKQI3g7AlxCFB0/lrh9PXDzqW7YFllsbBuNHAisjRRiOFQkSGRjsauT8xf eYhauzlk7umAAiGikc2/esr68/kca9c6U5jnRoA87e4dpKmddR6SO8/9VfHQr5/pvI7XeB5 yRm7d9SpC6ObQ7msnpg2w== Cc: Xin LI X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:25:54 -0000 Hi Xin LI, I've seen a strange behavior on 8.4, 9.2 and 10 systems. After fetching, installing the update + reboot a second freebsd-update will always pulls the following files /boot/GENERIC/linker.hints /boot/kernel/linker.hints -- Regards, olli From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 19:48:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76A66F47; Wed, 30 Apr 2014 19:48:09 +0000 (UTC) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BD6D1DB7; Wed, 30 Apr 2014 19:48:09 +0000 (UTC) Received: by mail-yh0-f53.google.com with SMTP id i57so2148193yha.12 for ; Wed, 30 Apr 2014 12:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=IzxsqeIllJgai3TzD1zw714tGaurYSCUXXGsfZb7v58=; b=QWNJuyNZDoIjK3XZOet4PrlpIsQNVHVUtaC/3zAAZAGFWLAQ+Tqislwz8G5kdgcZxK JXdj+Hm6jl5co15jnc2PwA4d+oIpGHQpbfBsUhDV+wj6b8QypBGci7RYgxmEyqDytXo4 T9+LWyQsrM3JKZVEWzHN7xrAnyC8O3Fho1O8ilftES7xylOUW1b6/ioOe1MLDjRk9qLc sUthQyen1r9qH6aaNimqeP8Ebs7Xvx7IlBtj90gRLGatWOjRklBj+6aMths4ynETMIrj jl0RTQTebZ4aJT0bhxWMsBgpPi0ZEzf3Htpz2Zdt/i/D7zp1vrWQW3I9rczx3ajBlD8A w/VA== X-Received: by 10.236.126.43 with SMTP id a31mr8826567yhi.154.1398887288079; Wed, 30 Apr 2014 12:48:08 -0700 (PDT) MIME-Version: 1.0 Sender: rafaelpossa@gmail.com Received: by 10.170.147.4 with HTTP; Wed, 30 Apr 2014 12:47:41 -0700 (PDT) In-Reply-To: <53614E7C.2040703@gmx.de> References: <201404301906.s3UJ6UCV017100@freefall.freebsd.org> <53614E7C.2040703@gmx.de> From: Rafael Possamai Date: Wed, 30 Apr 2014 14:47:41 -0500 X-Google-Sender-Auth: _J3fZhBFjVB0LLHbLGJPj_hQBAU Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl [REVISED] To: olli hauer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-security@freebsd.org, Xin LI X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:48:09 -0000 I have seen something similar, except different files (/boot/kernel/kernel). Would it be because I have compiled a custom kernel and no longer using GENERIC? I haven't figured this one out yet. Thank you, Rafael On Wed, Apr 30, 2014 at 2:26 PM, olli hauer wrote: > Hi Xin LI, > > I've seen a strange behavior on 8.4, 9.2 and 10 systems. > > After fetching, installing the update + reboot a second freebsd-update > will always pulls the following files > /boot/GENERIC/linker.hints > /boot/kernel/linker.hints > > -- > Regards, > olli > _______________________________________________ > 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 Wed Apr 30 19:48:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF4E4B0; Wed, 30 Apr 2014 19:48:25 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [IPv6:2001:41d0:8:3c67:1:1:0:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 848561DC5; Wed, 30 Apr 2014 19:48:25 +0000 (UTC) Received: from sulu.fritz.box (p3EE2F261.dip0.t-ipconnect.de [62.226.242.97]) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 3gJqys37kbz52R; Wed, 30 Apr 2014 21:48:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Michael Grimm In-Reply-To: <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> Date: Wed, 30 Apr 2014 21:48:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1510) Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:48:25 -0000 [CC'd to freebsd-ports] On 28.04.2014, at 00:50, Jamie Landeg-Jones = wrote: > Scot Hetzel wrote: > Here's a list of some that link against /lib/libcrypto.so.7 and/or > /lib/libssl.so.7 [...] > devel/android-tools-adb > net-p2p/transmission-cli > net-p2p/transmission-daemon > net/socat > net/svnup > ports-mgmt/pkg > security/john > security/scrypt > security/trousers > sysutils/tarsnap + www/nginx It took me some time to realize that nginx continued to be vulnerable = (heartbleed) even after: 1) creating upgraded poudriere jail (svn,stable10) 2) rebuilding all installed ports in that jail by poudriere 3) reinstalling all ports 4) rebuilding world and kernel (svn, stable10) 5) rebooting Well, I should have started with 4) instead. Now I know ;-)=20 Regards, Michael From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 19:21:26 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BA47596 for ; Wed, 30 Apr 2014 19:21:26 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 14BE41B11 for ; Wed, 30 Apr 2014 19:21:25 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s3UJL2Wh061994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 20:21:12 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s3UJL2Wh061994 Authentication-Results: smtp.infracaninophile.co.uk/s3UJL2Wh061994; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <53614D16.9060206@FreeBSD.org> Date: Wed, 30 Apr 2014 20:20:54 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: d@delphij.net, Corey Smith , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <536147DE.5030703@delphij.net> In-Reply-To: <536147DE.5030703@delphij.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U7AJBnfrU8sAF85njGGrrpQHmJeiXM0bR" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-Mailman-Approved-At: Wed, 30 Apr 2014 19:52:02 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:21:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U7AJBnfrU8sAF85njGGrrpQHmJeiXM0bR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 30/04/2014 19:58, Xin Li wrote: > On 04/30/14 11:51, Corey Smith wrote: >>> It would be interesting to find out if we could teach net-snmpd >>> to use alternative methods to access data it needs >=20 >> It is not necessary if you build net-mgmt/net-snmp with the >> UNPRIVILEGED knob set. >=20 > Will there be any lost functionality with that knob set? (I don't use > net-snmp myself) If there is no lost functional, I think it's > sensible to hard wire that option -- giving access to /dev/[k]mem > makes me feel quite nervous, especially for network facing daemons... Yeah. net-snmp is not something to expose to the internet in general. Private networks only is my rule. You can start snmpd with the '-r' flag which means it will at least run without needing access to /dev/mem or anything else privileged, but at the cost of reduced functionality. For instance the 'proc foo' test to check on the presence of a foo process doesn't work. Quite why that should need rootly privilege I do not know: it's effectively the same as grepping the output of 'ps -acx'. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --U7AJBnfrU8sAF85njGGrrpQHmJeiXM0bR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYU0eXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATKEYQAJCuf1vmuAyY5ffMhFx5zn9R pS0mAKwYGMMfWpHGdFIWTIw/fCbEGAGy3IcrAixS77K3i8p7ipWUXik7KAYDsxB3 pDaHG2mxpYDFawM5A82capwWB3+rPr0M9F29LbD3FxKmmk7/CYnmd+/iGQebFLHb 3AooqjuFSYe4THb4NVpKghMXHi1ERmb5eyGJ8IDcdxsh36TeOMK7tz/S1lTA1MS0 yCgLqFqqaNi1GzvUDzTSwsikDzIMgdyoJaGpT8n708LeqCJ1ZoWYE2r3689s+le1 duX8Oql8nDLKu5rvpW5LNJpEkURn94FUiXuruTiY3UOJ9smZ+QyQa43D6c5z01TO /wlhdJHAYrV9Z4y26dTWmJ6Hzkjaz4hD0EiD7m7RgtDJ0wDiiuK4DJ+TgZaJnJL5 BGUAW3AEwUO9ErcE8Z22Ieoi7EkIkwn4nH4WkvO8LKW6B4PDkD8bVzqQdQLh15ZA cRr5BjqD1ugbZ/n71ONY9yFpx4KpohdQASLjobzlX/ss9Mh1goTlxTyGblS6PThE jRfJfjodIM6DlaqYCzhZtka5J79WquLEp7PGHkGdSIbuef47pGhmH2IC0SNAh4HL vuyIk00d6bbEQY+UI//oIvjxhN+hJhLvEZ0Gv5EyH4L76Mgov3JsWq7dqktiYRPe 4hextjlBRPh1ynqKYNor =pCZE -----END PGP SIGNATURE----- --U7AJBnfrU8sAF85njGGrrpQHmJeiXM0bR-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 19:52:05 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1D5B371; Wed, 30 Apr 2014 19:52:05 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DC5E1FDA; Wed, 30 Apr 2014 19:52:05 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 75BF11BA89; Wed, 30 Apr 2014 12:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398887524; bh=FX0fs2Fwv3MtU2LAkpAh61oSz/igcJIl/TaGF4jdF98=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=Be8s6hD/a7huP8vpeJDGRHoOtLgxVgTD+w53OelsrvSPFYXFaey0V9Xs8B8V5nBRd sV2ACRFbx6r5V59OOD5qnNG/Y8akTu/X80kFZy9pCcVAjz1T1GUp5cqFkWfazs7I66 zfNcC0wd1IN2KWQ4AHU8dPRRs6T5hljR3FQzB+sQ= Message-ID: <53615462.10805@delphij.net> Date: Wed, 30 Apr 2014 12:52:02 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: olli hauer , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:09.openssl [REVISED] References: <201404301906.s3UJ6UCV017100@freefall.freebsd.org> <53614E7C.2040703@gmx.de> In-Reply-To: <53614E7C.2040703@gmx.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Xin LI , Colin Percival X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:52:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/30/14 12:26, olli hauer wrote: > Hi Xin LI, > > I've seen a strange behavior on 8.4, 9.2 and 10 systems. > > After fetching, installing the update + reboot a second > freebsd-update will always pulls the following files > /boot/GENERIC/linker.hints /boot/kernel/linker.hints Wow that's not normal. I can reproduce this on 9.2 but not 10.0 system (note that despite it claims to have patched the file, the sha256 checksum remains the same). Colin, do you have any suggestions? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYVRiAAoJEJW2GBstM+nslSIP+QFT6j2/qsaGJX8kC0QCzsIi 5YXkorbiV7pSEwEGXoS3gWeKwh9JaIT04VsXntENx26NJPHbWS3crOGPMOZ5/NXW kpXBB4LIS/6avloiOGDS/k0jk/I/eAIZaJuwtij/WoWoRrd9StpfxS83VHXra70P boQ843lwrTlnFMKwjn0cCg9R7QHjFWM00PCOgHUwVwPu4tSqm0yNpYpRVRRT0jkh pjEzOFPgve5LiV18P5Ey7FgkYiNKEXRQKOTqtW0W1/6ELDHorZNj06Fs/r/LKgEu v2nbJlV8gmdh44SItx2EFyaCFi3sczdfKcJzDVTNKn3C4z6S26tYPADJTEReaWAi 6uCFVKLgrPasJZNOvOyD4xhjQ5W4LGH6oRzGXpfguue9cfqFgw3YOrbVoueSLpZw Y6v6sTbzETicQNzdfUS1Dk4pAqGMqVMIE9tFNGCOQfzEseNp++sea/WwwfOnYy7d nvP6P7XN4w3cqPqYGyvgpL3ECLBJn2BOAxvC12tgrc32zUe7CEUVbu/sb58r41qF eKY65qW2F5EL/V7P6jfeGE9Dv3U46QC1YAgExj9AhtzUswGl1bJetJR+m7FD1Uo7 XUbsEFItvhLYeFRUggL3A10cTaFKLhrtmjNjeSb+u6ZXXcqWqZyUply9jEWjnhXU 13l3CDaks9YNPIMLJ2U8 =ILmh -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Apr 30 23:38:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 675D0404; Wed, 30 Apr 2014 23:38:57 +0000 (UTC) Received: from mario.brtsvcs.net (mario.brtsvcs.net [IPv6:2607:fc50:0:a400::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BD9C1585; Wed, 30 Apr 2014 23:38:56 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:880:bd0:21c:c0ff:fe7f:96ee]) by mario.brtsvcs.net (Postfix) with ESMTPSA id 53FD12C162E; Wed, 30 Apr 2014 16:38:48 -0700 (PDT) Received: from [IPv6:2601:7:2280:38b:5045:dd46:d3b:55b] (unknown [IPv6:2601:7:2280:38b:5045:dd46:d3b:55b]) by chombo.houseloki.net (Postfix) with ESMTPSA id 2BD68B2B; Wed, 30 Apr 2014 16:38:45 -0700 (PDT) Message-ID: <5361896C.7010703@bluerosetech.com> Date: Wed, 30 Apr 2014 16:38:20 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Grimm , freebsd-security@freebsd.org Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> In-Reply-To: <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:38:57 -0000 On 4/30/2014 12:48 PM, Michael Grimm wrote: > [CC'd to freebsd-ports] > > On 28.04.2014, at 00:50, Jamie Landeg-Jones wrote: >> Scot Hetzel wrote: > >> Here's a list of some that link against /lib/libcrypto.so.7 and/or >> /lib/libssl.so.7 > [...] >> devel/android-tools-adb >> net-p2p/transmission-cli >> net-p2p/transmission-daemon >> net/socat >> net/svnup >> ports-mgmt/pkg >> security/john >> security/scrypt >> security/trousers >> sysutils/tarsnap > > + www/nginx Nginx respects WITH_OPENSSL_PORT. From owner-freebsd-security@FreeBSD.ORG Thu May 1 07:54:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EE4B882 for ; Thu, 1 May 2014 07:54:48 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id F39091A5A for ; Thu, 1 May 2014 07:54:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2544:2162:1011:d2db]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 33D124AC2D; Thu, 1 May 2014 11:54:29 +0400 (MSK) Date: Thu, 1 May 2014 11:54:24 +0400 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <25986221.20140501115424@serebryakov.spb.ru> To: "Ronald F. Guilmette" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <32377.1398460907@server1.tristatelogic.com> References: <32377.1398460907@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 07:54:48 -0000 Hello, Ronald. You wrote 26 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2014 =D0=B3., 1:21:47: RFG> The (modified/quieted) code example under discussion is as follows: RFG> variable =3D value0; /* initialization */ RFG> if (condition) variable =3D value1; RFG> if (!condition) variable =3D value2; RFG> use (variable); RFG> Please note that variable *is* *always* set to some value (either valu= e1 RFG> or value2) after initialization. The "error condition" that you seem RFG> concerned about having explicitly flagged does not in fact exist in the RFG> example code snippet under discussion. I have only one question: which memory model do you have in mind when you do this statement? Please note, that now you could hardly find single-core/single-threaded C= PU (even current ARMs are multi-cored now) and only two non-functional languages with formally specified memory model I know is C++11 and Java. I belive, Ada should have well-defined memory model, but I know next to nothing about Ada. I could easily write code like shown above in Java, which left "variable" with value0 up to line with "use()" and it will be not a bug in JVM, but b= ug in code: everything depend on variables which are used in "condition" and "variable" itself. Yes, it is not possible (in Java!) when everything is arguments to method or local (on stack), but as soon I don't know YOUT memory model and that YOUR compiler and execution environment implements this mode PROPERLY, I could not be sure, that even "localness" of data helps. And please note, that different CPUs has very different memory model (even now, when Alpha is long-dead), and as C is very down-to-hardware language and C standard doesn't have any real memory-model described, so it is very hard to reason about this C code, if it i C. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-security@FreeBSD.ORG Thu May 1 10:03:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47474879; Thu, 1 May 2014 10:03:01 +0000 (UTC) Received: from c01.escapebox.net (c01.escapebox.net [87.230.55.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFD47172B; Thu, 1 May 2014 10:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=geminix.org; s=g01; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=KqYFwqowYwBMm8WhtbX/GCNznvHY2iz5jdBwjzm2wlI=; b=GFJfl2p25cBVGO1GervDyO53ay8moSFdcJZv4IVo6ogoCZ4wq2yXh+FtSJHaRxAhekkLS5MeLa2+AfMB2KGV87gpvvhORLd5TWFs+KbNFdwmEM7SfQdSzNKEn8jZ8RkRan3QT1rQLM2BuOjWN6pT9urzZpnwtKT1cFJyeyBzTXs=; Received: from user.n01.escapebox.net ([fd45:7d86:a5ba::3b] ident=mailnull) by repo.n01.escapebox.net with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WfnpR-000364-Kj; Thu, 01 May 2014 12:02:57 +0200 Message-ID: <53621BE0.4040704@geminix.org> Date: Thu, 01 May 2014 12:03:12 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> In-Reply-To: <5361896C.7010703@bluerosetech.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Received: from gemini by user.n01.escapebox.net with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WfnpR-00035z-Hs; Thu, 01 May 2014 12:02:57 +0200 Cc: "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 10:03:01 -0000 On 01.05.14 01:38, Darren Pilgrim wrote: > On 4/30/2014 12:48 PM, Michael Grimm wrote: >> [CC'd to freebsd-ports] >> >> On 28.04.2014, at 00:50, Jamie Landeg-Jones >> wrote: >>> Scot Hetzel wrote: >> >>> Here's a list of some that link against /lib/libcrypto.so.7 and/or >>> /lib/libssl.so.7 >> [...] >>> devel/android-tools-adb >>> net-p2p/transmission-cli >>> net-p2p/transmission-daemon >>> net/socat >>> net/svnup >>> ports-mgmt/pkg >>> security/john >>> security/scrypt >>> security/trousers >>> sysutils/tarsnap >> >> + www/nginx > > Nginx respects WITH_OPENSSL_PORT. I indeed wondered why this variable hadn't been mentioned so far. Guys, you do have "WITH_OPENSSL_PORT=yes" in your "/etc/make.conf", haven't you? Because otherwise the whole thread might be considered a false alert. The ports system does not link with the ports' OpenSSL of its own accord. Or at least not in a reliable/predictable manner. You have to explicitly tell it what you want. Best regards, Uwe -- Uwe Doering | EscapeBox - IT Consulting gemini@geminix.org | http://www.escapebox.net From owner-freebsd-security@FreeBSD.ORG Thu May 1 06:04:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 106031000 for ; Thu, 1 May 2014 06:04:25 +0000 (UTC) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "ca.infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FA210F3 for ; Thu, 1 May 2014 06:04:24 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.8/8.14.8) with ESMTP id s4164BKS069493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 1 May 2014 07:04:11 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.3 smtp.infracaninophile.co.uk s4164BKS069493 Authentication-Results: smtp.infracaninophile.co.uk/s4164BKS069493; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <5361E3D4.2050300@FreeBSD.org> Date: Thu, 01 May 2014 07:04:04 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> In-Reply-To: <5361896C.7010703@bluerosetech.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7WEuJwq3Uxo8NU4pG9TwSffHgc9iJm51x" X-Virus-Scanned: clamav-milter 0.98.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_SBL,URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lucid-nonsense.infracaninophile.co.uk X-Mailman-Approved-At: Thu, 01 May 2014 11:44:38 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 06:04:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7WEuJwq3Uxo8NU4pG9TwSffHgc9iJm51x Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/05/2014 00:38, Darren Pilgrim wrote: > On 4/30/2014 12:48 PM, Michael Grimm wrote: >> On 28.04.2014, at 00:50, Jamie Landeg-Jones >> wrote: >>> Scot Hetzel wrote: >>> Here's a list of some that link against /lib/libcrypto.so.7 and/or >>> /lib/libssl.so.7 >>> ports-mgmt/pkg pkg is a special case. It is required to have no dependencies beyond the base system in order that the pkg bootstrapping process can work. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --7WEuJwq3Uxo8NU4pG9TwSffHgc9iJm51x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTYePbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATLdQP/0s/RGy5GLJHV2RyxhZOv0cz n7HJh+u1QvMmfeWbtCRBvV1XRfOCuZalXVq4FxK0LzaQoG6yQhD4YeRCnks2G6AH J4njiQ19SZN4ZzWtDZR/3o9UpbL1TSXZtcwNNnSXPKS0DdWJ7BDMviNN3bUp4YDm i1PpxsMoRhdD6S+5R+7Fd/ydN9GSYIM27ekC+JhFinKOGtKAzNIjfvDfRX9Qlx1A VjWNEMxfUWfcIij0PrUmTz2jpzrvL8Ix/SMUAm+cwKQM8bTdLQSQhGmBchTGlmWV xPpFWMcTtggkosxMBaSwFvBrxeR4qV1LJrBCqH9Tny2BeEdj3Rjd+JMpdvIxHwUP U9zm6uFqBt+deb4ReiGcMSim9h/RDfLdO+iqV8TLrDB9ikiaCYhwv7spCBinSwe2 OvBxQmWjPWaYOqmIW+k8JCjwmjHgdRAglFsZpGwgLOevUJqmdTaiIapm+QPXhE4a rwcZ/J2ucEvttm5YzFTTzWrL1gbHS6GY/7T+k9D4+LYNPTMzQH7DOe0wKIcBoF1j 5s73ghxld2aStQKgkJLIreegrzvvFWtG770AOtsWNAUwcrDPRed7EYT3IlOZC8Fh YCB5FVLJRPlIE4KqVWBqUr+AwX4/0TWsePIhOSl78AG0P/9GGctx//2QEQPQJ6M6 N3TkvN12dxKvG8fEHGrd =u6jL -----END PGP SIGNATURE----- --7WEuJwq3Uxo8NU4pG9TwSffHgc9iJm51x-- From owner-freebsd-security@FreeBSD.ORG Thu May 1 12:30:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2144DD5 for ; Thu, 1 May 2014 12:30:04 +0000 (UTC) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9DB4A157C for ; Thu, 1 May 2014 12:30:04 +0000 (UTC) Received: from [192.168.0.249] (5751e248.skybroadband.com [87.81.226.72]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id s41CJxoI007856; Thu, 1 May 2014 13:19:59 +0100 (BST) (envelope-from rb@gid.co.uk) From: Bob Bishop Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Date: Thu, 1 May 2014 13:19:54 +0100 Message-Id: <9C9E416B-501C-49CD-A698-93CA7848CD1D@gid.co.uk> To: Kevin Day Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 12:30:05 -0000 Hi, > From: Kevin Day > To: freebsd-security@freebsd.org > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp >=20 > > Affects: All supported versions of FreeBSD. > > Corrected: 2014-04-30 04:04:20 UTC (stable/8, 8.4-STABLE) > > 2014-04-30 04:05:47 UTC (releng/8.4, 8.4-RELEASE-p9) > > 2014-04-30 04:05:47 UTC (releng/8.3, = 8.3-RELEASE-p16) > > 2014-04-30 04:04:20 UTC (stable/9, 9.2-STABLE) > > 2014-04-30 04:05:47 UTC (releng/9.2, 9.2-RELEASE-p5) > > 2014-04-30 04:05:47 UTC (releng/9.1, = 9.1-RELEASE-p12) > > 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > > 2014-04-30 04:04:42 UTC (releng/10.0, = 10.0-RELEASE-p2) >=20 > Does anyone know the lower bound for how far back this bug exists? Is = it only present in the above versions, or does it affect earlier = versions that aren?t listed? >=20 > (trying to come up with a deployment plan for some servers stuck on = 8.1 and 7.x due to vendors abandoning device drivers) Just looked at this, 8.1 and 7.x don't have the optimisation using the = stack so they are unaffected. -- Bob Bishop rb@gid.co.uk From owner-freebsd-security@FreeBSD.ORG Thu May 1 12:56:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0BED2C0; Thu, 1 May 2014 12:56:31 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [IPv6:2001:41d0:8:3c67:1:1:0:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A53501830; Thu, 1 May 2014 12:56:31 +0000 (UTC) Received: from sulu.fritz.box (p3EE2F4CB.dip0.t-ipconnect.de [62.226.244.203]) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 3gKGn03960zyl; Thu, 1 May 2014 14:56:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Michael Grimm In-Reply-To: <53621BE0.4040704@geminix.org> Date: Thu, 1 May 2014 14:56:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> To: "freebsd-security@freebsd.org" , "freebsd-ports@freebsd.org" X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 12:56:31 -0000 On 01.05.2014, at 12:03, Uwe Doering wrote: > On 01.05.14 01:38, Darren Pilgrim wrote: >> On 4/30/2014 12:48 PM, Michael Grimm wrote: >>> On 28.04.2014, at 00:50, Jamie Landeg-Jones = wrote: >>>> Here's a list of some that link against /lib/libcrypto.so.7 and/or >>>> /lib/libssl.so.7 >>> [...] >>>=20 >>> + www/nginx >>=20 >> Nginx respects WITH_OPENSSL_PORT. >=20 > I indeed wondered why this variable hadn't been mentioned so far. = Guys, > you do have "WITH_OPENSSL_PORT=3Dyes" in your "/etc/make.conf", = haven't you? No, I haven't had sofar, and shame on me, I have to admit that I didn' = know that knob before :-(=20 Thanks Darren for mentioning it, and regards, Michael From owner-freebsd-security@FreeBSD.ORG Thu May 1 14:19:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 255D8FBC for ; Thu, 1 May 2014 14:19:56 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id C0CAB10FD for ; Thu, 1 May 2014 14:19:55 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s41EJlnv087952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 May 2014 15:19:47 +0100 (BST) Date: Thu, 01 May 2014 15:19:47 +0100 From: Karl Pielorz To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Message-ID: <7A880FB5C3D1DA39692881FE@study64.tdx.co.uk> In-Reply-To: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 14:19:56 -0000 --On 30 April 2014 04:35:10 +0000 FreeBSD Security Advisories wrote: > II. Problem Description > > FreeBSD may add a reassemble queue entry on the stack into the segment > list when the reassembly queue reaches its limit. The memory from the > stack is undefined after the function returns. Subsequent iterations of > the reassembly function will attempt to access this entry. Hi, Does this require an established TCP session to be present? - i.e. If you have a host which provides no external TCP sessions (i.e. replies 'Connection Refused' / drops the initial SYN) would that still be potentially exploitable? What about boxes used as routers - that just forward the traffic (and again, offer no TCP services directly themselves)? -Karl From owner-freebsd-security@FreeBSD.ORG Thu May 1 14:34:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C87C7BC; Thu, 1 May 2014 14:34:05 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5B6D128A; Thu, 1 May 2014 14:34:03 +0000 (UTC) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s41EXxlM051016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 May 2014 07:34:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Paul Hoffman In-Reply-To: <53621BE0.4040704@geminix.org> Date: Thu, 1 May 2014 07:33:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> To: Uwe Doering X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Thu, 01 May 2014 15:24:02 +0000 Cc: freebsd-security@freebsd.org, "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 14:34:05 -0000 On May 1, 2014, at 3:03 AM, Uwe Doering wrote: > I indeed wondered why this variable hadn't been mentioned so far. = Guys, > you do have "WITH_OPENSSL_PORT=3Dyes" in your "/etc/make.conf", = haven't you? >=20 > Because otherwise the whole thread might be considered a false alert. > The ports system does not link with the ports' OpenSSL of its own > accord. Or at least not in a reliable/predictable manner. You have to > explicitly tell it what you want. Please consider whether it is appropriate to chide people for not = knowing about an *undocumented* feature of make.conf. I'll turn in a pr for it. --Paul HOffman= From owner-freebsd-security@FreeBSD.ORG Thu May 1 15:26:14 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12A72204; Thu, 1 May 2014 15:26:14 +0000 (UTC) Received: from c01.escapebox.net (c01.escapebox.net [87.230.55.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BAB7717E7; Thu, 1 May 2014 15:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=geminix.org; s=g01; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=OAymW7YQbOUdAAZ1cI/tdaQ6HCHP+CKJqzGUnN1EgDk=; b=xgC4ddLsAY6ElQ84h6r8pWk5pr5wj3hpt5NBu2O+nMTjqwALCgrVpUwSN2i0XHgUqVPjxIvtSnSLOuWcCayIcl1+tc55UnIEqzr7OL4kyfylL23MXsFX/7k714KHSJi9VxoRZKhVzJGJGVm0HjJ/smipZWXgI8vo/XVgrNmwRMg=; Received: from user.n01.escapebox.net ([fd45:7d86:a5ba::3b] ident=mailnull) by repo.n01.escapebox.net with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WfssE-0003lj-JN; Thu, 01 May 2014 17:26:10 +0200 Message-ID: <536267A0.9010403@geminix.org> Date: Thu, 01 May 2014 17:26:24 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> In-Reply-To: <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Received: from gemini by user.n01.escapebox.net with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WfssE-0003le-Fv; Thu, 01 May 2014 17:26:10 +0200 Cc: freebsd-security@freebsd.org, "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 15:26:14 -0000 On 01.05.14 16:33, Paul Hoffman wrote: > On May 1, 2014, at 3:03 AM, Uwe Doering wrote: > >> I indeed wondered why this variable hadn't been mentioned so far. Guys, >> you do have "WITH_OPENSSL_PORT=yes" in your "/etc/make.conf", haven't you? >> >> Because otherwise the whole thread might be considered a false alert. >> The ports system does not link with the ports' OpenSSL of its own >> accord. Or at least not in a reliable/predictable manner. You have to >> explicitly tell it what you want. > > Please consider whether it is appropriate to chide people for not knowing about an *undocumented* feature of make.conf. First of all, I certainly didn't intend to chide anyone, so I apologize if some of you got the impression. Having worked with FreeBSD and the ports system for years I was under the impression that this information would be readily available in the docs. But on further research it appears to me that this is indeed pretty well hidden in only some mailing list and forum articles, where I probably learned it from in the past. Having realized that, I now wonder how many people run half-broken systems because they didn't know about this and didn't notice the wrong and sometimes even mixed linking of the OpenSSL libs. > I'll turn in a pr for it. Good idea. I would think that this should be mentioned at least in "pkg-descr" of the "openssl" port, where it gets displayed by "portmaster" and perhaps other port management tools after each install. Best regards, Uwe -- Uwe Doering gemini@geminix.org From owner-freebsd-security@FreeBSD.ORG Thu May 1 16:11:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 337C010A; Thu, 1 May 2014 16:11:51 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F8341CC6; Thu, 1 May 2014 16:11:50 +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 s41GBh8s066498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2014 09:11:43 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s41GBghF066497; Thu, 1 May 2014 09:11:42 -0700 (PDT) (envelope-from jmg) Date: Thu, 1 May 2014 09:11:42 -0700 From: John-Mark Gurney To: Lev Serebryakov Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140501161142.GL43976@funkthat.com> Mail-Followup-To: Lev Serebryakov , "Ronald F. Guilmette" , "freebsd-security@freebsd.org security" References: <32377.1398460907@server1.tristatelogic.com> <25986221.20140501115424@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25986221.20140501115424@serebryakov.spb.ru> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 01 May 2014 09:11:43 -0700 (PDT) Cc: "freebsd-security@freebsd.org security" , "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:11:51 -0000 Lev Serebryakov wrote this message on Thu, May 01, 2014 at 11:54 +0400: > Hello, Ronald. > You wrote 26 ???????????? 2014 ??., 1:21:47: > > RFG> The (modified/quieted) code example under discussion is as follows: > RFG> variable = value0; /* initialization */ > RFG> if (condition) variable = value1; > RFG> if (!condition) variable = value2; > RFG> use (variable); > > RFG> Please note that variable *is* *always* set to some value (either value1 > RFG> or value2) after initialization. The "error condition" that you seem > RFG> concerned about having explicitly flagged does not in fact exist in the > RFG> example code snippet under discussion. > I have only one question: which memory model do you have in mind when you > do this statement? I assume he's talking about the abstract machine as defined in the C standard, like C99... which implies single threaded execution... > Please note, that now you could hardly find single-core/single-threaded CPU > (even current ARMs are multi-cored now) and only two non-functional > languages with formally specified memory model I know is C++11 and Java. > I belive, Ada should have well-defined memory model, but I know next to > nothing about Ada. > > I could easily write code like shown above in Java, which left "variable" > with value0 up to line with "use()" and it will be not a bug in JVM, but bug > in code: everything depend on variables which are used in "condition" and > "variable" itself. Yes, it is not possible (in Java!) when everything is > arguments to method or local (on stack), but as soon I don't know YOUT > memory model and that YOUR compiler and execution environment implements > this mode PROPERLY, I could not be sure, that even "localness" of data > helps. > > And please note, that different CPUs has very different memory model (even > now, when Alpha is long-dead), and as C is very down-to-hardware language > and C standard doesn't have any real memory-model described, so it is very > hard to reason about this C code, if it i C. You can properly reason about this code.. Per the C standard (5.1.2.3 para 2&3): Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,11) which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.) In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object). It is up to the compiler to ensure that the abstract machine is properly translated to the CPU and memory model of said CPU... So, as long as condition is an object that is not volatile (or accessed through volatile pointers), it's state cannot change, and there for is the equivalent to if/else, though the definition of condition was left out making this hard to decide, but considering the original discussion, we should make that assumption... -- 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 May 1 16:12:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBBA11F0; Thu, 1 May 2014 16:12:00 +0000 (UTC) Received: from c01.escapebox.net (c01.escapebox.net [87.230.55.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F16D1CD2; Thu, 1 May 2014 16:12:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=geminix.org; s=g01; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=fM0FfFfbx8BQl6JgfLP8/ZOqYKzcmlWGr+T836i/M+w=; b=oYZPtBjbT5UROW+6IWyR+OH0QdCt5Howb1lgjfq01hiwR0V/iUbfytEWtqCn40mB51whEOOgYCWKoHWQDHuhRr4o/GwTvkBD9B2vDugcXRwzyGGrIgPPjBHyB6jOCPKf+AoP2NkOiNeVZH6h5A4izfyQV15yXyhRElvDsqPrIBs=; Received: from user.n01.escapebox.net ([fd45:7d86:a5ba::3b] ident=mailnull) by repo.n01.escapebox.net with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WftaY-0003tR-5f; Thu, 01 May 2014 18:11:58 +0200 Message-ID: <5362725B.6010109@geminix.org> Date: Thu, 01 May 2014 18:12:11 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> <536267A0.9010403@geminix.org> In-Reply-To: <536267A0.9010403@geminix.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Received: from gemini by user.n01.escapebox.net with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WftaY-0003tL-2j; Thu, 01 May 2014 18:11:58 +0200 Cc: freebsd-security@freebsd.org, "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:12:01 -0000 On 01.05.14 17:26, Uwe Doering wrote: > On 01.05.14 16:33, Paul Hoffman wrote: >> On May 1, 2014, at 3:03 AM, Uwe Doering wrote: >> >>> I indeed wondered why this variable hadn't been mentioned so far. Guys, >>> you do have "WITH_OPENSSL_PORT=yes" in your "/etc/make.conf", haven't you? >>> >>> Because otherwise the whole thread might be considered a false alert. >>> The ports system does not link with the ports' OpenSSL of its own >>> accord. Or at least not in a reliable/predictable manner. You have to >>> explicitly tell it what you want. >> >> Please consider whether it is appropriate to chide people for not knowing about an *undocumented* feature of make.conf. > > First of all, I certainly didn't intend to chide anyone, so I apologize > if some of you got the impression. Having worked with FreeBSD and the > ports system for years I was under the impression that this information > would be readily available in the docs. > > But on further research it appears to me that this is indeed pretty well > hidden in only some mailing list and forum articles, where I probably > learned it from in the past. > [...] One additional data point: "WITH_OPENSSL_PORT" is mentioned in the FreeBSD Porter's Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html#idp67984816 But then, it cannot be expected that mere _users_ of the ports tree read the Porter's Handbook. And it is also not mentioned there that it is, to my knowledge, considered good practice to have that setting in "/etc/make.conf" in order to avoid any confusion about which port is linked with what version of OpenSSL. Best regards, Uwe -- Uwe Doering gemini@geminix.org From owner-freebsd-security@FreeBSD.ORG Thu May 1 16:12:06 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAEAC355; Thu, 1 May 2014 16:12:06 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFD7B1CDD; Thu, 1 May 2014 16:12:06 +0000 (UTC) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s41GC3up054113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 May 2014 09:12:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Paul Hoffman In-Reply-To: <536267A0.9010403@geminix.org> Date: Thu, 1 May 2014 09:12:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: <9D3DC025-7675-427C-8CBD-E128C5F47F2A@vpnc.org> References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> <536267A0.9010403@geminix.org> To: Uwe Doering X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Thu, 01 May 2014 16:29:23 +0000 Cc: freebsd-security@freebsd.org, "freebsd-ports@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 16:12:07 -0000 On May 1, 2014, at 8:26 AM, Uwe Doering wrote: > On 01.05.14 16:33, Paul Hoffman wrote: >> I'll turn in a pr for it. docs/189199 > Good idea. I would think that this should be mentioned at least in > "pkg-descr" of the "openssl" port, where it gets displayed by > "portmaster" and perhaps other port management tools after each install. ports/189208 From owner-freebsd-security@FreeBSD.ORG Thu May 1 18:42:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2B7F3CD for ; Thu, 1 May 2014 18:42:12 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C23A21DA9 for ; Thu, 1 May 2014 18:42:12 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id EE86523168; Thu, 1 May 2014 11:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398969732; bh=0HaSV9Y0pF59gR6T9XjV4lwiz68kTO9cBCnrNOtFFgQ=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=bmuooRgEC7vC9PbI/iDKenT2GMpxXPN3KCtXxBCKIwvL6munhn8PXGcr/X7zZTCMg Bvn6imD8DoFo5Yk9KQIIyYx9O1b0gWDl90UOMDsNB2GLpu4m4eDes+HNWK/d/WV1yZ XnUBCxNSCVuOgHDn57duzzopXZ4EeFj151ZIQnBE= Message-ID: <53629582.9010605@delphij.net> Date: Thu, 01 May 2014 11:42:10 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Karl Pielorz , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> <7A880FB5C3D1DA39692881FE@study64.tdx.co.uk> In-Reply-To: <7A880FB5C3D1DA39692881FE@study64.tdx.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:42:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/01/14 07:19, Karl Pielorz wrote: > > > --On 30 April 2014 04:35:10 +0000 FreeBSD Security Advisories > wrote: > >> II. Problem Description >> >> FreeBSD may add a reassemble queue entry on the stack into the >> segment list when the reassembly queue reaches its limit. The >> memory from the stack is undefined after the function returns. >> Subsequent iterations of the reassembly function will attempt to >> access this entry. > > Hi, > > Does this require an established TCP session to be present? - i.e. > If you have a host which provides no external TCP sessions (i.e. > replies 'Connection Refused' / drops the initial SYN) would that > still be potentially exploitable? No. An established TCP session is required. > What about boxes used as routers - that just forward the traffic > (and again, offer no TCP services directly themselves)? Routers themselves are not affected assuming that they merely forwards the traffic. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYpWCAAoJEJW2GBstM+nsSMYQAJqAv/LFJx8dJ7KEAoVWS2k2 MGt4pPE4yB49C2YWOdsq4qFAl77aAsOeLiO5aKrceqVpe4UOQjXjH3t7yPCTIVh7 CH28ujJgVNYsxcxaaB4puHPEzmtjzovjHbpH2WcNky7+ICjL/cjHWWRdTQ4h80i9 c4vRJOQGkkbRkLBtGyRFLa1NQ+KNYyANWo9bH60RUqm+sBr1VJFGeuxr16CDrPSp 9doTPjwf8NvOtX/BQaWJWFMoGiaVMrRvk6Cx8S4ScBdfiD/v/i/vHYNuVfy85Mbb TJA1ozRk6kI3iHf9Spx5GC4FX1yjzU8m4BFW8n/wqVG+AaeGO4VFFrdo7g1iKqzY bKWWIfBgRT9GlqJoY2DUvHRWKYugJnAWCAgreqJuYPCwo2H3SobwR4Pg9KQcCcUk aeEdLGgUiorxL3uChepXlQ01NgV4s66Czrmiu/8Bw+s8MQzjCNoonxW6+XQXE2g6 fnvPnV4l6RFLzxNwsoIzf/sHYHqtNRq5IAEX3C5BbJ7uDsbeJYTdI5eh1jwIUlCp 8tvFdlbgZOoiPHmIEa4ltorS7fR5rSFLCHekyTFddFuIbosarmZ3psf3tBr35EGE T3R4VYImwz1+Ae/80DsY0XlIMsPKdb4HQKVoGYq55ZOwk+r0ll9EQe9dsO1ZeY+f EcNdqzkX/YVrK7vgxD7h =WHGC -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu May 1 18:51:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C341A655 for ; Thu, 1 May 2014 18:51:44 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6A60E1FF1 for ; Thu, 1 May 2014 18:51:43 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s41Ipbeo011730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2014 19:51:37 +0100 (BST) Date: Thu, 01 May 2014 19:51:37 +0100 From: Karl Pielorz To: d@delphij.net, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Message-ID: <5E06BC0A5CFB26EDF20A7FC5@study64.tdx.co.uk> In-Reply-To: <53629582.9010605@delphij.net> References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> <7A880FB5C3D1DA39692881FE@study64.tdx.co.uk> <53629582.9010605@delphij.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:51:44 -0000 --On 1 May 2014 11:42:10 -0700 Xin Li wrote: >> Does this require an established TCP session to be present? - i.e. >> If you have a host which provides no external TCP sessions (i.e. >> replies 'Connection Refused' / drops the initial SYN) would that >> still be potentially exploitable? > > No. An established TCP session is required. > >> What about boxes used as routers - that just forward the traffic >> (and again, offer no TCP services directly themselves)? > > Routers themselves are not affected assuming that they merely forwards > the traffic. That's great - thanks for clarifying... We have a number of boxes that you can't (from the Internet) get a TCP session to, whilst they will still have to be patched [to protect them from our 'admin' networks] - we can use that mitigation to schedule a better patch install / reboot schedule, Regards, -Karl From owner-freebsd-security@FreeBSD.ORG Thu May 1 19:04:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8263974 for ; Thu, 1 May 2014 19:04:16 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A60261137 for ; Thu, 1 May 2014 19:04:16 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id D83E62343B; Thu, 1 May 2014 12:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1398971056; bh=0fOWvdTevDmRNPR5T6Y+5r45zqqfY+v8X7jkjBPiYU4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=P6PM+UyCUdtWclSz3KB3sTXXb3teuO+fHKELU/Qy1F28z4p7wEhtRtADopd5CKrB7 cnhumcBR26TX/f2a0SvnprEWPesXmjVrLSCFLwa2UrZ5a3BLYKX6c1Fhsyx7Ph/n6Z hMgW4RhWMIuudOy8v85ZFgkL3ujDghmH+KF1aXNc= Message-ID: <53629AAF.8050802@delphij.net> Date: Thu, 01 May 2014 12:04:15 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Bob Bishop , Kevin Day Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <9C9E416B-501C-49CD-A698-93CA7848CD1D@gid.co.uk> In-Reply-To: <9C9E416B-501C-49CD-A698-93CA7848CD1D@gid.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:04:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/01/14 05:19, Bob Bishop wrote: > Hi, > >> From: Kevin Day To: >> freebsd-security@freebsd.org Subject: Re: FreeBSD Security >> Advisory FreeBSD-SA-14:08.tcp >> >>> Affects: All supported versions of FreeBSD. Corrected: >>> 2014-04-30 04:04:20 UTC (stable/8, 8.4-STABLE) 2014-04-30 >>> 04:05:47 UTC (releng/8.4, 8.4-RELEASE-p9) 2014-04-30 04:05:47 >>> UTC (releng/8.3, 8.3-RELEASE-p16) 2014-04-30 04:04:20 UTC >>> (stable/9, 9.2-STABLE) 2014-04-30 04:05:47 UTC (releng/9.2, >>> 9.2-RELEASE-p5) 2014-04-30 04:05:47 UTC (releng/9.1, >>> 9.1-RELEASE-p12) 2014-04-30 04:03:05 UTC (stable/10, >>> 10.0-STABLE) 2014-04-30 04:04:42 UTC (releng/10.0, >>> 10.0-RELEASE-p2) >> >> Does anyone know the lower bound for how far back this bug >> exists? Is it only present in the above versions, or does it >> affect earlier versions that aren?t listed? >> >> (trying to come up with a deployment plan for some servers stuck >> on 8.1 and 7.x due to vendors abandoning device drivers) > > Just looked at this, 8.1 and 7.x don't have the optimisation using > the stack so they are unaffected. Yes. The affected code was introduced in r226113 (Oct 7, 2011). Note that the original change is not an "optimization" but a fix to prevent a denial of service situation. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTYpqvAAoJEJW2GBstM+nsrtAP/jcbSTn8JhZNHz2dcDACS9wL 5zX3num5bdl9DtQQz2Ulw6KTteSvgxNX2p6FlM97F/2j7SeiBVGPviXDqaA3fjVq 8yS/VrLeJrH0tllAYGv//d0Em72NH5e219j5ov2pgivB3IdQEsNWY9A6uECBqYtY PlUsnX7RJDDTeO+n33y2hZdeD8+YRbfrebD0hTDURcViZB6XF7BEXWWPGXF8spBM 38Dk/OisDaxctm0ZQ03WoKTeCD0vyQCFbFk7ZHlkxa4Q4125PHWwsEstoiRtqShr YQEM/38ZmYp2baAp4lm3qix2mkudN+LsU15jTNvvAug4bVaLs6V6yjMhFllQdCQA rdp21t0eXXJXH6KwzCXP31yw6PyjH9aES71HfgMfwZ9P9kYyqzp29PvFkijg7mw6 LX4H15XO7Y5cEkwIPoIGJNymttBJPwIlQ1M2tT95GT6II5Z3bjIZ6tQjMJQlVFP4 ZKa0T48oqlCR4AsCzXCpPQpoBw628YYZGhq1Akh9B35WUlXD+b1ezqd4GYmdgnDM 6KEMfz1oaCb7mKtMHqzY2MTXuDCC9yTVUwsk676TICi3OD+r9h990BKxIPRocB8h zpOoG2QuesStY+L/pVzOAaWN05wlS/zl7LDLpt5MDCR5DRnwS89lGcJfbEyFJM/z nmIDyekGCTTPQ16zgGMW =gilP -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu May 1 19:38:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E65D2C2 for ; Thu, 1 May 2014 19:38:42 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6F70E1480 for ; Thu, 1 May 2014 19:38:41 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id CDCDA3AD93 for ; Thu, 1 May 2014 12:38:29 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp In-Reply-To: <53629582.9010605@delphij.net> Date: Thu, 01 May 2014 12:38:29 -0700 Message-ID: <96385.1398973109@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:38:42 -0000 In message <53629582.9010605@delphij.net>, Xin Li wrote: >On 05/01/14 07:19, Karl Pielorz wrote: >> >> >> --On 30 April 2014 04:35:10 +0000 FreeBSD Security Advisories >> wrote: >> >>> II. Problem Description >>> >>> FreeBSD may add a reassemble queue entry on the stack into the >>> segment list when the reassembly queue reaches its limit. The >>> memory from the stack is undefined after the function returns. >>> Subsequent iterations of the reassembly function will attempt to >>> access this entry. >> >> Hi, >> >> Does this require an established TCP session to be present? - i.e. >> If you have a host which provides no external TCP sessions (i.e. >> replies 'Connection Refused' / drops the initial SYN) would that >> still be potentially exploitable? > >No. An established TCP session is required. I also have a question.... If one manages a system where (a) all local user accounts are completely and 100% trustworthy and where (b) one has in place ipfw rules which reject all incoming packet *fragments* on all outward-facing interfaces, then is this security problem (relating to the reassembly queue) an issue at all for said system? Or is it rather a non-event in such contexts? Regards, rfg From owner-freebsd-security@FreeBSD.ORG Thu May 1 20:24:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CBFFB35; Thu, 1 May 2014 20:24:39 +0000 (UTC) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [87.98.149.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 20B27187F; Thu, 1 May 2014 20:24:38 +0000 (UTC) Received: from sulu.fritz.box (p3EE2F4CB.dip0.t-ipconnect.de [62.226.244.203]) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 3gKSkB54QLz39g; Thu, 1 May 2014 22:24:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports From: Michael Grimm In-Reply-To: <5362725B.6010109@geminix.org> Date: Thu, 1 May 2014 22:24:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> <536267A0.9010403@geminix.org> <5362725B.6010109@geminix.org> To: "freebsd-security@freebsd.org" , "freebsd-ports@freebsd.org" X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:24:39 -0000 On 01.05.2014, at 18:12, Uwe Doering wrote: > One additional data point: "WITH_OPENSSL_PORT" is mentioned in the > FreeBSD Porter's Handbook: >=20 > = http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile= -options.html#idp67984816 If I would have searched for "knobs" in that document = (http://svnweb.freebsd.org/ports/head/KNOBS?view=3Dmarkup), recently, I = would have ended with: | Unknown location: /head/KNOBS And, I didn't know what "knobs" were until a year ago after migrating = from portmaster to poudriere, although running FBSD beginning with 6.2. = But don't get me wrong, I do not complain at all, its been my fault, = period. > But then, it cannot be expected that mere _users_ of the ports tree = read > the Porter's Handbook. True. > And it is also not mentioned there that it is, to > my knowledge, considered good practice to have that setting in > "/etc/make.conf" in order to avoid any confusion about which port is > linked with what version of OpenSSL. Here's my question: Which knobs are considered good practice? Is it = experience, is it gut feeling, religion, ...? I would love to see a = documentation covering the pro and cons about every "knob" ... I do not = complain, I know, that is hard work and hard to accomplish. But any links to documents -besides the ones already mentioned- are = highly appreciated. E.g: excuse my ignorance, but should I stay with ... | www-jail> ldd `which nginx` | /usr/local/sbin/nginx: | libcrypt.so.5 =3D> /lib/libcrypt.so.5 (0x8008aa000) ..., or would there be an alternative in ports? libgcrypt? or? (All my = relevant services are run being compiled from ports, and within jails.) Thanks, sorry for eventually dumb questions, and regards, Michael= From owner-freebsd-security@FreeBSD.ORG Fri May 2 06:24:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 341F7505; Fri, 2 May 2014 06:24:28 +0000 (UTC) Received: from c01.escapebox.net (c01.escapebox.net [87.230.55.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA93E1E6E; Fri, 2 May 2014 06:24:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=geminix.org; s=g01; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ku+FFgivBWLnaH7fMnA41/v54ZgIXRdlekDIJDJSJvQ=; b=xukpshZBAcG6eRzk9MUr01iBuqgyBcM3YYAv/TgV1jqbaD6i3nrZfk7BtjV9ywvc+m2YlgBaNlXcOv8JScW24pij7lYvyuwgSo9hbmqIEUNrhVDfAGB49JwsQBUuDZRhAxd1PjmT83Ef3ShZpI2xqedJBOUAt5lUygqbNDI5E6Y=; Received: from user.n01.escapebox.net ([fd45:7d86:a5ba::3b] ident=mailnull) by repo.n01.escapebox.net with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wg6tP-0005yW-CF; Fri, 02 May 2014 08:24:19 +0200 Message-ID: <53633A26.3010701@geminix.org> Date: Fri, 02 May 2014 08:24:38 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-security@freebsd.org" , "freebsd-ports@freebsd.org" Subject: Re: ports requiring OpenSSL not honouring OpenSSL from ports References: <201404271508.s3RF8sMA014085@catnip.dyslexicfish.net> <201404272250.s3RMo2NZ095771@catnip.dyslexicfish.net> <445CDD31-5A11-4F5E-92DE-CB11A10E9BDE@odo.in-berlin.de> <5361896C.7010703@bluerosetech.com> <53621BE0.4040704@geminix.org> <15864901-C372-43A8-A6E6-BF0AF73F2EC6@vpnc.org> <536267A0.9010403@geminix.org> <5362725B.6010109@geminix.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Received: from gemini by user.n01.escapebox.net with esmtpa (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wg6tP-0005yR-8N; Fri, 02 May 2014 08:24:19 +0200 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 06:24:28 -0000 On 01.05.14 22:24, Michael Grimm wrote: > On 01.05.2014, at 18:12, Uwe Doering wrote: > [...] >> And it is also not mentioned there that it is, to >> my knowledge, considered good practice to have that setting in >> "/etc/make.conf" in order to avoid any confusion about which port is >> linked with what version of OpenSSL. > > Here's my question: Which knobs are considered good practice? Is it experience, is it gut feeling, religion, ...? I would love to see a documentation covering the pro and cons about every "knob" ... I do not complain, I know, that is hard work and hard to accomplish. > > But any links to documents -besides the ones already mentioned- are highly appreciated. Well, links to documents I cannot provide, but for years I at least have only these settings in "/etc/make.conf": KERNCONF=ESCAPEBOX WITH_OPENSSL_PORT=yes NO_WARNING_PKG_INSTALL_EOL=yes Or rather, the last line I added only recently because I haven't switched to the "pkg" port, yet. And the first line is only relevant if you compile your own modified kernel, like I do. There can be other things in it like compiler switches, but I'm rather conservative in this regard and try to keep defaults wherever I can, because these mainstream settings are usually the best tested ones. I need my servers to just run and do their job. In fact, I do not have the time for surprises due to unnecessary experiments. > E.g: excuse my ignorance, but should I stay with ... > > | www-jail> ldd `which nginx` > | /usr/local/sbin/nginx: > | libcrypt.so.5 => /lib/libcrypt.so.5 (0x8008aa000) > > ..., or would there be an alternative in ports? libgcrypt? or? (All my relevant services are run being compiled from ports, and within jails.) Don't mix up "libcrypt" with "libcrypto". Only the latter has to do with OpenSSL. If you install OpenSSL from ports you actually have two sets of similarly named libs. One in "/lib", the other in "/usr/local/lib". In my case (FreeBSD 8.4): /lib/libcrypto.so.6 /usr/local/lib/libcrypto.so.8 And while I don't have Nginx installed, here is the relevant "ldd" line for Apache's "mod_ssl": libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x800d66000) I would think that if you haven't had the "WITH_OPENSSL_PORT" directive in "/etc/make.conf" so far it would be best to make sure that you have the latest version of OpenSSL from ports installed and then reinstall all packages that depend on OpenSSL. "portmaster", for instance, has the "-r" option to do this automatically in one go. Best regards, Uwe -- Uwe Doering | EscapeBox - IT Consulting gemini@geminix.org | http://www.escapebox.net From owner-freebsd-security@FreeBSD.ORG Fri May 2 08:09:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A032B9F for ; Fri, 2 May 2014 08:09:32 +0000 (UTC) Received: from mail1.canodus2.canodus.be (mail1.canodus2.canodus.be [83.149.89.9]) by mx1.freebsd.org (Postfix) with ESMTP id A7B6117A6 for ; Fri, 2 May 2014 08:09:31 +0000 (UTC) Received: by mail1.canodus2.canodus.be (Postfix, from userid 65534) id 90B0E32AD87; Fri, 2 May 2014 10:09:22 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail1.canodus2.canodus.be X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from [192.168.1.102] (94-225-247-220.access.telenet.be [94.225.247.220]) by mail1.canodus2.canodus.be (Postfix) with ESMTPSA id 4E66132AC66; Fri, 2 May 2014 10:09:22 +0200 (CEST) Message-ID: <1399018162.3822.1.camel@debian.wout-t440s> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs From: Wout =?ISO-8859-1?Q?Decr=E9?= To: d@delphij.net Date: Fri, 02 May 2014 10:09:22 +0200 In-Reply-To: <536144E8.4020502@delphij.net> References: <201404300435.s3U4ZAfe093748@freefall.freebsd.org> <1398849409.4521.12.camel@debian.wout-t440s> <536144E8.4020502@delphij.net> Organization: Canodus Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 08:09:32 -0000 On Wed, 2014-04-30 at 11:46 -0700, Xin Li wrote: > On 04/30/14 02:16, Wout DecrĆ© wrote: > > On Wed, 2014-04-30 at 04:35 +0000, FreeBSD Security Advisories > > wrote: > >> ============================================================================= > >> > >> > FreeBSD-SA-14:07.devfs Security > Advisory > >> The FreeBSD Project > >> > >> Topic: devfs rules not applied by default for jails > >> > >> Category: core Module: etc_rc.d Announced: > >> 2014-04-30 Affects: FreeBSD 10.0 Corrected: > >> 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) 2014-04-30 > >> 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) CVE Name: > >> CVE-2014-3001 > >> > >> For general information regarding FreeBSD Security Advisories, > >> including descriptions of the fields above, security branches, > >> and the following sections, please visit > >> . > >> > >> I. Background > >> > >> The device file system, or devfs(5), provides access to kernel's > >> device namespace in the global file system namespace. > >> > >> The devfs(5) rule subsystem provides a way for the administrator > >> of a system to control the attributes of DEVFS nodes. Each DEVFS > >> mount-point has a ``ruleset'', or a list of rules, associated > >> with it, allowing the administrator to change the properties, > >> including the visibility, of certain nodes. > >> > >> II. Problem Description > >> > >> The default devfs rulesets are not loaded on boot, even when > >> jails are used. Device nodes will be created in the jail with > >> their normal default access permissions, while most of them > >> should be hidden and inaccessible. > >> > >> III. Impact > >> > >> Jailed processes can get access to restricted resources on the > >> host system. For jailed processes running with superuser > >> privileges this implies access to all devices on the system. > >> This level of access could lead to information leakage and > >> privilege escalation. > >> > >> IV. Workaround > >> > >> Systems that do not run jails are not affected. > >> > >> The system administrator can do the following to load the default > >> ruleset: > >> > >> /etc/rc.d/devfs onestart > >> > >> Then apply the default ruleset for jails on a devfs mount using: > >> > >> devfs -m ${devfs_mountpoint} rule -s 4 applyset > >> > >> Or, alternatively, the following command will apply the ruleset > >> over all devfs mountpoints except the host one: > >> > >> mount -t devfs | grep -v '^devfs on /dev ' | awk '{print $3;}' | > >> \ xargs -n 1 -J % devfs -m % rule -s 4 applyset > >> > >> After this, the system administrator should add the following > >> configuration to /etc/rc.conf to make it permanent, so the above > >> operations do not have to be done each time the host system > >> reboots. > >> > >> devfs_load_rulesets="YES" > > > > I have always used the following rc.conf options to start jails: > > > > jail_xxx_devfs_enable="YES" > > jail_xxx_devfs_ruleset="devfsrules_jail" > > > > If jail_xxx_devfs_enable is set to NO, would there be a problem? I > > thought you always had to set jail_xxx_devfs_ruleset when enabling > > devfs on jails. > > > > I think this has the same effect as the workaround above? > > Assuming the jail have no access to the device file system at all, you > would not be affected by the problem. > > Setting jail_*_devfs_ruleset by itself is not sufficient because a > recent change (only in 10.x) have removed the loading of default > rules, making setting the rule set no-op. > > No, you don't have to set per-jail ruleset explicitly, the default is > devfsrules_jail unless overridden. > > Cheers, Ok, thanks for clarifying that! Cheers From owner-freebsd-security@FreeBSD.ORG Fri May 2 09:50:14 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE3D7B06 for ; Fri, 2 May 2014 09:50:14 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 927A9126A for ; Fri, 2 May 2014 09:50:14 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D3C8D61B5; Fri, 2 May 2014 09:50:13 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 60EF231A33; Fri, 2 May 2014 11:50:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> <53610127.5000603@sentex.net> Date: Fri, 02 May 2014 11:50:16 +0200 In-Reply-To: <53610127.5000603@sentex.net> (Mike Tancsa's message of "Wed, 30 Apr 2014 09:56:55 -0400") Message-ID: <86y4ykik6f.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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 09:50:14 -0000 Mike Tancsa writes: > Is [scrub in all] the only pf option that will work, or is scrub > fragment reassemble sufficient ? "fragment reassemble" is implicit, but if you leave out "in" it will also scrub outgoing traffic, which is wasteful. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri May 2 10:02:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9145EC0; Fri, 2 May 2014 10:02:38 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3994B1382; Fri, 2 May 2014 10:02:37 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 06FE4623B; Fri, 2 May 2014 10:02:37 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 9197431A48; Fri, 2 May 2014 12:02:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthew Seaman Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <536147DE.5030703@delphij.net> <53614D16.9060206@FreeBSD.org> Date: Fri, 02 May 2014 12:02:39 +0200 In-Reply-To: <53614D16.9060206@FreeBSD.org> (Matthew Seaman's message of "Wed, 30 Apr 2014 20:20:54 +0100") Message-ID: <86tx98ijls.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: Corey Smith , freebsd-security@freebsd.org, d@delphij.net X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 10:02:38 -0000 Matthew Seaman writes: > You can start snmpd with the '-r' flag which means it will at least run > without needing access to /dev/mem or anything else privileged, but at > the cost of reduced functionality. For instance the 'proc foo' test to > check on the presence of a foo process doesn't work. Quite why that > should need rootly privilege I do not know: it's effectively the same as > grepping the output of 'ps -acx'. It probably uses libkvm instead of the newer libprocstat, which does not require access to /dev/mem. The only reason you'd ever want to use libkvm is if you want to be able to operate on kernel dumps. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri May 2 11:58:19 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E04EB3B; Fri, 2 May 2014 11:58:19 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C1EE1DD9; Fri, 2 May 2014 11:58:19 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 8190A1534D1; Fri, 2 May 2014 13:58:14 +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 2VM8g1uuAbki; Fri, 2 May 2014 13:58:12 +0200 (CEST) Received: from [192.168.101.130] (vpn.ecoracks.nl [31.223.170.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 9802C153434; Fri, 2 May 2014 13:58:12 +0200 (CEST) Message-ID: <53638858.2010109@digiware.nl> Date: Fri, 02 May 2014 13:58:16 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Matthew Seaman Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:07.devfs References: <536147DE.5030703@delphij.net> <53614D16.9060206@FreeBSD.org> <86tx98ijls.fsf@nine.des.no> In-Reply-To: <86tx98ijls.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Corey Smith , freebsd-security@freebsd.org, d@delphij.net X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 11:58:19 -0000 On 2-5-2014 12:02, Dag-Erling SmĆørgrav wrote: > Matthew Seaman writes: >> You can start snmpd with the '-r' flag which means it will at least run >> without needing access to /dev/mem or anything else privileged, but at >> the cost of reduced functionality. For instance the 'proc foo' test to >> check on the presence of a foo process doesn't work. Quite why that >> should need rootly privilege I do not know: it's effectively the same as >> grepping the output of 'ps -acx'. > > It probably uses libkvm instead of the newer libprocstat, which does not > require access to /dev/mem. The only reason you'd ever want to use > libkvm is if you want to be able to operate on kernel dumps. Opening and ripping all kvm out net-snmp is going to be a nice challenge... I've fixed things a few times in the past, but the code is loaded with #ifdef stuff because it needs to cater to all flavors of OSes in wants to be available on. But even then, reducing its privileges after starting will also hamper any perl-plugin that requires anything more than just the basic rights. So you'd be running into access problems in other places as well. Sometimes you can fix those with either changed access rights or sudo. But I would not be surprised if not everything is going to be smooth sailing.... --WjW From owner-freebsd-security@FreeBSD.ORG Fri May 2 15:16:52 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D69ADCC0 for ; Fri, 2 May 2014 15:16:52 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id B07C61373 for ; Fri, 2 May 2014 15:16:52 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id B927733C49; Fri, 2 May 2014 11:16:51 -0400 (EDT) From: Lowell Gilbert To: "Ronald F. Guilmette" Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <96385.1398973109@server1.tristatelogic.com> Date: Fri, 02 May 2014 11:16:51 -0400 In-Reply-To: <96385.1398973109@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Thu, 01 May 2014 12:38:29 -0700") Message-ID: <44d2fwcisc.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 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: Fri, 02 May 2014 15:16:52 -0000 "Ronald F. Guilmette" writes: > I also have a question.... > > If one manages a system where (a) all local user accounts are completely > and 100% trustworthy and where (b) one has in place ipfw rules which reject > all incoming packet *fragments* on all outward-facing interfaces, then is > this security problem (relating to the reassembly queue) an issue at all > for said system? Or is it rather a non-event in such contexts? That should keep you safe, but it will break some legitimate connections, not to mention MTU discovery. From owner-freebsd-security@FreeBSD.ORG Fri May 2 16:03:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BDD779C for ; Fri, 2 May 2014 16:03:15 +0000 (UTC) Received: from gw01-1.biotronik.org (gw01-1.biotronik.org [91.204.10.44]) (using SSLv3 with cipher RC4-SHA (128/128 bits)) (Client CN "gw01-1.biotronik.org", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B4DE1AC9 for ; Fri, 2 May 2014 16:03:14 +0000 (UTC) MIME-Version: 1.0 Subject: =?ISO-8859-1?Q?AUTO=3A_Walter_Phippeny_is_out_of_the_office_=28R=FCckkehr?= =?ISO-8859-1?Q?_am_06=2E05=2E2014=29?= From: "Walter Phippeny" To: freebsd-security@freebsd.org Message-ID: Date: Fri, 2 May 2014 18:03:04 +0200 Auto-Submitted: auto-generated X-Disclaimed: 37683 X-MIMETrack: CD-MIME by Router on GW01-1/SRV/MSC(Release 9.0.1 HF280|March 03, 2014) at 02.05.2014 18:03:04, CD-MIME complete at 02.05.2014 18:03:04, Itemize by Router on GW01-1/SRV/MSC(Release 9.0.1 HF280|March 03, 2014) at 02.05.2014 18:03:04 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:03:15 -0000 Ich kehre zur=FCck am 06.05.2014. Ich bin in Urlaub. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp" gesendet am 02.05.2014 17:16:51. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w=E4hrend diese Person abwesend ist. This e-mail and the information it contains including attachments are confi= dential and meant only for use by the intended recipient(s); disclosure or = copying is strictly prohibited. If you are not addressed, but in the posses= sion of this e-mail, please notify the sender immediately. From owner-freebsd-security@FreeBSD.ORG Fri May 2 16:58:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B78EE6E5 for ; Fri, 2 May 2014 16:58:27 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9081C1294 for ; Fri, 2 May 2014 16:58:27 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 255422330C; Fri, 2 May 2014 09:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1399049905; bh=MMApK6BjEpZ6E5k8RdviXaXGPn2DYWrfnvCEzBm913U=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=mJGpEZJY9wASPTcz+UEWdNz/Qgtn3JmawCEU39EW54VlaWpsJtLAwgjJ0p+L5nlVw S0gpzOLAJ9XUG7RVwZKIrf4JPRwwdrgvwU82ST0LvCj9D3vpdQ54lg1CPK21ghsap8 Ys4+668Gea1BFCvMwP/bE1LGtAM5N9zTBhSCMt00= Message-ID: <5363CEAE.3040805@delphij.net> Date: Fri, 02 May 2014 09:58:22 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <96385.1398973109@server1.tristatelogic.com> In-Reply-To: <96385.1398973109@server1.tristatelogic.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:58:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/01/14 12:38, Ronald F. Guilmette wrote: > I also have a question.... > > If one manages a system where (a) all local user accounts are > completely and 100% trustworthy and where (b) one has in place ipfw > rules which reject all incoming packet *fragments* on all > outward-facing interfaces, then is this security problem (relating > to the reassembly queue) an issue at all for said system? Or is it > rather a non-event in such contexts? (a) doesn't matter, systems with only root user can be affected if they provide TCP service. (b) I'm not 100% sure on ipfw details (haven't used it for ~10 years now) but IP fragmentation itself have nothing to do with this issue since it's a different layer. Assuming you can't do TCP reassemble with ipfw, it's still a problem. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTY86uAAoJEJW2GBstM+nsz9QQAI33s2CPVNuk1sWZ+OTdmIK9 2lDgJcVCRkDgX0MXph1CPO0NGkrXs8M7Ct3UtP91gagkkwiEZ6zO7jWK81GrEaNC zBbYUyazWUx37mPUzLHf06a0NnvLFKLkJZZMrXfxYlX/BwFArAzsXY0i+JiGzKe3 Yd686PE2k4HU2RdGzm6H0T4eN5TJgNVb0AD4LIsvFfRcNUlqB0E+wrUrMeX6mmbi 3D1RnSjmD4SV5kFsvgiE3DVpTujwcfyYOQeJyEA7GTaBx/ZNHUI1GOCkCJ34SKzW 5qHwOKwFBPTmiFCmFxALrGv9cHM4M5iykvAqdbAM3tuPyQIUBVRLBCH/BtjzIj6n tV6a7kHVNYamY8HDL3B9BLb/9EtVVNJxPLWWnOwpnhTrxBj79oxe+DCXZPCpYiy6 Od9ljRgS2GozsA0poUo3GNO7zr+mkegLVvg++GuZN2tIsOqWHhKDNQrzOxc27TP0 OHfQXkU6k34SgcVyfjSRKXUdt6ZCJ66FCZHZA7NpxDk2gyuFrYUiFXEJh90qs9QD AUpXXEznNnId+OMEnwiCb5t+4o7TvMsra0XaZfS9+Q87U0owKUT0jOBt054QYtsn IkyiyyjjB1xWtxgICuuBwK9B7D75D4if6z68pkHUsd5jptO84S7auXF1qTYlonPC LG+xvLDPTbXErzcpK+om =zQbC -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri May 2 16:40:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B9BC3E1 for ; Fri, 2 May 2014 16:40:33 +0000 (UTC) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 467C71104 for ; Fri, 2 May 2014 16:40:32 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 409F5B0381DE; Fri, 2 May 2014 12:16:08 -0400 (EDT) Received: from IAD-WPRD-XCHB01.corp.verio.net ([198.87.7.137]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 May 2014 12:16:07 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Date: Fri, 2 May 2014 12:16:06 -0400 Message-ID: In-Reply-To: <96385.1398973109@server1.tristatelogic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp thread-index: Ac9ldPiuqSq0J/4lRNij7KucAt/Y5QArJs8Q References: <53629582.9010605@delphij.net> <96385.1398973109@server1.tristatelogic.com> From: "David DeSimone" To: "Ronald F. Guilmette" X-OriginalArrivalTime: 02 May 2014 16:16:07.0878 (UTC) FILETIME=[D31B7660:01CF6621] X-Mailman-Approved-At: Fri, 02 May 2014 17:37:29 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:40:33 -0000 Are you perhaps confusing IP Fragment Reassembly with the similar but = unrelated TCP Segment Reassembly? My understanding is that TCP stacks normally try very hard not to = generate IP fragments in a TCP stream. It appears that this bug report relates only to TCP Reassembly, and has = nothing to do with IP Fragments. But perhaps I am misreading it? -----Original Message----- From: owner-freebsd-security@freebsd.org = [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Ronald F. = Guilmette Sent: Thursday, May 01, 2014 2:38 PM To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp In message <53629582.9010605@delphij.net>, Xin Li = wrote: >On 05/01/14 07:19, Karl Pielorz wrote: >>=20 >>=20 >> --On 30 April 2014 04:35:10 +0000 FreeBSD Security Advisories=20 >> wrote: >>=20 >>> II. Problem Description >>>=20 >>> FreeBSD may add a reassemble queue entry on the stack into the >>> segment list when the reassembly queue reaches its limit. The >>> memory from the stack is undefined after the function returns. >>> Subsequent iterations of the reassembly function will attempt to >>> access this entry. >>=20 >> Hi, >>=20 >> Does this require an established TCP session to be present? - i.e. >> If you have a host which provides no external TCP sessions (i.e. >> replies 'Connection Refused' / drops the initial SYN) would that >> still be potentially exploitable? > >No. An established TCP session is required. I also have a question.... If one manages a system where (a) all local user accounts are completely and 100% trustworthy and where (b) one has in place ipfw rules which = reject all incoming packet *fragments* on all outward-facing interfaces, then = is this security problem (relating to the reassembly queue) an issue at all for said system? Or is it rather a non-event in such contexts? Regards, rfg _______________________________________________ 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" This email message is intended for the use of the person to whom it has = been sent, and may contain information that is confidential or legally = protected. If you are not the intended recipient or have received this = message in error, you are not authorized to copy, distribute, or = otherwise use this message or its attachments. Please notify the sender = immediately by return e-mail and permanently delete this message and any = attachments. Verio Inc. makes no warranty that this email is error or = virus free. Thank you. From owner-freebsd-security@FreeBSD.ORG Fri May 2 19:42:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F348A453 for ; Fri, 2 May 2014 19:42:29 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id D4E101374 for ; Fri, 2 May 2014 19:42:29 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id B80E43B014 for ; Fri, 2 May 2014 12:42:23 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp In-Reply-To: Date: Fri, 02 May 2014 12:42:23 -0700 Message-ID: <3867.1399059743@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 19:42:30 -0000 In message , "David DeSimone" wrote: >Are you perhaps confusing IP Fragment Reassembly with the similar but >unrelated TCP Segment Reassembly? That's entirely possible. I have near zero experience with or understanding of either of these types of packet fragmentation. >My understanding is that TCP stacks normally try very hard not to >generate IP fragments in a TCP stream. > >It appears that this bug report relates only to TCP Reassembly, and has >nothing to do with IP Fragments. But perhaps I am misreading it? OK, so how would one block all incoming *TCP* fragments... you know... in order to render this specific security issue a non-issue? (I personally am already blocking inbound IP fragments viw ipfw.) From owner-freebsd-security@FreeBSD.ORG Fri May 2 20:05:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 882CEAF2 for ; Fri, 2 May 2014 20:05:05 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E9D415C6 for ; Fri, 2 May 2014 20:05:05 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id BEEA3233C6; Fri, 2 May 2014 13:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1399061104; bh=LcmV76U1hgm6uJdYIdRiNCgB4+O1pVdqCC0U4JSw8xw=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=0MkVpKpI9lGCbGfkMYhT6JCooyrZkf5gdMGKzLavXyqfrwIi+F7cnD+1NkDIAk8aL Vrk/bOTyS+LoaJ+x2LNNVnHRmtoAm7r7PAxSQb7hreHKEU2mdKeV9gVkIG6tfuqKgH SZ7l1mZDSxFPWmgR3zBvnrlvDd8TTWthJeJHK8AA= Message-ID: <5363FA70.9040100@delphij.net> Date: Fri, 02 May 2014 13:05:04 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <3867.1399059743@server1.tristatelogic.com> In-Reply-To: <3867.1399059743@server1.tristatelogic.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 20:05:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/02/14 12:42, Ronald F. Guilmette wrote: > OK, so how would one block all incoming *TCP* fragments... you > know... There is no such TCP fragments thing. > in order to render this specific security issue a non-issue? (I > personally am already blocking inbound IP fragments viw ipfw.) Looking at ipfw manual it doesn't seem to have the capability to do TCP reassembling (or so-called traffic normalization), which as far as I know, is a pf-only feature on FreeBSD. If your server is behind a pf-based firewall or some other firewall that can do TCP reassemble, you can do that as well. Please note that TCP reassemble requires more memory and CPU power and do not necessarily reduce the traffic hitting your server behind firewall, so it's a workaround and may be not a good idea for longer term usage. Blocking inbound IP fragments is generally a good safety measure, but keep in mind that doing so could break certain applications that do require it (e.g. don't be surprised if some user behind several layers of firewalls see blank pages from your website) and that needs to be taken into consideration. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTY/pwAAoJEJW2GBstM+nsviwP/3COZbbO5e6dAYWW21bFJp3P 0C2UkroHf1rK1hZHM1lJAGoXOzbzYNKzCWePxOiQD8YpaARU7Q1B7cjlamZQK7Tn 10e3I4++PaIlYQ2Z9CF0GEhdJx96NKiIW0jWB0RdPIHnwA0pQB/YeiAK4tsVuQJM 7pjkNfPGDSsOqDajWxUqTyChsUWgekonpaigRyyk6TJqgRWj/yxT/jggXFqr6InO uzFxnWfgUPYV+mjnBoafmgz8I9JAX90LQb+HnSaf5oWl5MzWR4wT8JYgwyizkXKW MuBd6f1hd7KNOtAdZzh41cXCPUUuPmwkDFlvfDdfPnR1RU3p9UQ7zS/SmgHRBIre n78BDihMDrfA183t1T1ABqT8s8Qgj17YK389yk6+WVFSfKzNwWYWSFHBaA+ZgBsX 5s4Cw/1fWZ1/xK7t6uYrX4FyF2QgcWi61iUJHqIDbcDViDda+PC8p9HWwRG4mih+ WwLw5kvbx+XkuoNAyxGtPUy7HZlkSys926XtEbl8n7Z3miF9Ns3JpA6o5sz9zc9M TzUEJkmgsy6yEFolDIHHTnVjmuSK9SYZv8KFIdHkL0DDvP5lPFovdNSas2TtjDHP LlNBIBZL2h1AF4rWx1ne4OZtbdn5vuaUdCRqlroppRpi8Q4ps/o414aeGs8cJTfc PWT4I9mAPFD+xnN1lI1C =IUgz -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sat May 3 03:54:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 161FBCA7 for ; Sat, 3 May 2014 03:54:10 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 811491C94 for ; Sat, 3 May 2014 03:54:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s433rijW089910; Sat, 3 May 2014 13:53:44 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 May 2014 13:53:44 +1000 (EST) From: Ian Smith To: d@delphij.net Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp In-Reply-To: <5363FA70.9040100@delphij.net> Message-ID: <20140503133437.R11699@sola.nimnet.asn.au> References: <3867.1399059743@server1.tristatelogic.com> <5363FA70.9040100@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-security@freebsd.org, "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 03:54:10 -0000 On Fri, 2 May 2014 13:05:04 -0700, Xin Li wrote: > On 05/02/14 12:42, Ronald F. Guilmette wrote: > > OK, so how would one block all incoming *TCP* fragments... you > > know... > > There is no such TCP fragments thing. > > > in order to render this specific security issue a non-issue? (I > > personally am already blocking inbound IP fragments viw ipfw.) > > Looking at ipfw manual it doesn't seem to have the capability to do > TCP reassembling (or so-called traffic normalization), which as far as > I know, is a pf-only feature on FreeBSD. If your server is behind a > pf-based firewall or some other firewall that can do TCP reassemble, > you can do that as well. man ipfw /reass Or is that something else? I haven't used this myself. > Please note that TCP reassemble requires more memory and CPU power and > do not necessarily reduce the traffic hitting your server behind > firewall, so it's a workaround and may be not a good idea for longer > term usage. > > Blocking inbound IP fragments is generally a good safety measure, but > keep in mind that doing so could break certain applications that do > require it (e.g. don't be surprised if some user behind several layers > of firewalls see blank pages from your website) and that needs to be > taken into consideration. I've always allowed frags, as per the example rulesets in rc.firewall. I only recall seeing them on DNS responses from zen.spamhaus.org, where I see plenty of these after a resetlog before the logging limit kicks in. I doubt I'd be getting rid of ~90% of incoming spam without; eg: Apr 17 19:52:29 sola kernel: ipfw: 20200 Accept UDP myISP mybox in via ng0 (frag 18125:853@1480) Apr 17 19:52:29 sola kernel: ipfw: 20200 Accept UDP myISP mybox in via ng0 (frag 18126:903@1480) Apr 17 19:52:29 sola kernel: ipfw: 20200 Accept UDP myISP mybox in via ng0 (frag 18128:1043@1480) Apr 17 19:52:29 sola kernel: ipfw: 20200 Accept UDP myISP mybox in via ng0 (frag 18129:147@1480) cheers, Ian From owner-freebsd-security@FreeBSD.ORG Sat May 3 05:30:46 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA1E49DD for ; Sat, 3 May 2014 05:30:46 +0000 (UTC) Received: from luigi.brtsvcs.net (luigi.brtsvcs.net [IPv6:2607:fc50:1000:1f00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A89D715F5 for ; Sat, 3 May 2014 05:30:46 +0000 (UTC) Received: from chombo.houseloki.net (unknown [IPv6:2601:7:880:bd0:21c:c0ff:fe7f:96ee]) by luigi.brtsvcs.net (Postfix) with ESMTPSA id 6E62C2D4F9F; Fri, 2 May 2014 22:30:44 -0700 (PDT) Received: from [IPv6:2601:7:2280:38b:30b3:c5a8:9939:130a] (unknown [IPv6:2601:7:2280:38b:30b3:c5a8:9939:130a]) by chombo.houseloki.net (Postfix) with ESMTPSA id 738A0D2C; Fri, 2 May 2014 22:30:41 -0700 (PDT) Message-ID: <53647EE2.2010305@bluerosetech.com> Date: Fri, 02 May 2014 22:30:10 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: d@delphij.net, "Ronald F. Guilmette" , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp References: <3867.1399059743@server1.tristatelogic.com> <5363FA70.9040100@delphij.net> In-Reply-To: <5363FA70.9040100@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 05:30:46 -0000 On 5/2/2014 1:05 PM, Xin Li wrote: > Blocking inbound IP fragments is generally a good safety measure, but > keep in mind that doing so could break certain applications that do > require it (e.g. don't be surprised if some user behind several layers > of firewalls see blank pages from your website) and that needs to be > taken into consideration. They won't even get to the site in the first place. With EDNS, a very large DNS response over UDP is possible. On the wire, it's a single large UDP packet fragmented at the IP level. If you block fragments, you'll only get the first part of the UDP packet. Using a validating resolver pretty much guarantees you'll see such UDP packets regularly. From owner-freebsd-security@FreeBSD.ORG Sat May 3 05:25:43 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D561D99D for ; Sat, 3 May 2014 05:25:43 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9AB156D for ; Sat, 3 May 2014 05:25:43 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s435Pe38026964; Sat, 3 May 2014 01:25:40 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s435Pe6g026961; Sat, 3 May 2014 01:25:40 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21348.32212.390793.959943@hergotha.csail.mit.edu> Date: Sat, 3 May 2014 01:25:40 -0400 From: Garrett Wollman To: Ian Smith Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp In-Reply-To: <20140503133437.R11699@sola.nimnet.asn.au> References: <3867.1399059743@server1.tristatelogic.com> <5363FA70.9040100@delphij.net> <20140503133437.R11699@sola.nimnet.asn.au> 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]); Sat, 03 May 2014 01:25:40 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sat, 03 May 2014 12:25:48 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 05:25:43 -0000 < said: > I've always allowed frags, as per the example rulesets in rc.firewall. > I only recall seeing them on DNS responses from zen.spamhaus.org, where > I see plenty of these after a resetlog before the logging limit kicks > in. I doubt I'd be getting rid of ~90% of incoming spam without; eg: Blocking inbound fragments will definitely screw you when you try to use DNSsec. -GAWollman From owner-freebsd-security@FreeBSD.ORG Sat May 3 14:54:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45DF4E74 for ; Sat, 3 May 2014 14:54:07 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BA9A51480 for ; Sat, 3 May 2014 14:54:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s43Ers5H012104; Sun, 4 May 2014 00:53:54 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 4 May 2014 00:53:54 +1000 (EST) From: Ian Smith To: Garrett Wollman Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp In-Reply-To: <21348.32212.390793.959943@hergotha.csail.mit.edu> Message-ID: <20140504003835.J11699@sola.nimnet.asn.au> References: <3867.1399059743@server1.tristatelogic.com> <5363FA70.9040100@delphij.net> <20140503133437.R11699@sola.nimnet.asn.au> <21348.32212.390793.959943@hergotha.csail.mit.edu> 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.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 14:54:07 -0000 On Sat, 3 May 2014 01:25:40 -0400, Garrett Wollman wrote: > < said: > > > I've always allowed frags, as per the example rulesets in rc.firewall. > > I only recall seeing them on DNS responses from zen.spamhaus.org, where > > I see plenty of these after a resetlog before the logging limit kicks > > in. I doubt I'd be getting rid of ~90% of incoming spam without; eg: > > Blocking inbound fragments will definitely screw you when you try to > use DNSsec. Thanks to you and Darren; more grist for mending the Handbook ipfw page, likely why some people have been perhaps ill-advisedly dropping frags. cheers, Ian From owner-freebsd-security@FreeBSD.ORG Sat May 3 16:35:23 2014 Return-Path: Delivered-To: FreeBSD-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0DB24FF; Sat, 3 May 2014 16:35:23 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AABB11C20; Sat, 3 May 2014 16:35:23 +0000 (UTC) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s43GZKiK037382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 May 2014 09:35:21 -0700 (MST) (envelope-from phoffman@proper.com) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Fwd: ports/189208: Add a mention of WITH_OPENSSL_PORT to the pkg-descr of security/openssl From: Paul Hoffman Date: Sat, 3 May 2014 09:35:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18F230B0-65F4-4DAE-A771-52AAE7B00573@proper.com> References: <201405031619.s43GJbXQ095254@freefall.freebsd.org> To: FreeBSD-security@FreeBSD.org, freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.1874) Cc: dinoex@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 16:35:23 -0000 Note that the description below does *not* match what people were saying = last week about how things work. My reading of the earlier thread was = that, unless you had WITH_OPENSSL_PORT=3Dyes in /etc/make.conf, a port = needing OpenSSL would make with OpenSSL from the base. I am not a porter and wouldn't know where to look in the code, so I = can't figure out which is right. But it is clear that this is worth = clarifying both in the openssl pkg-descr *and* in the make.conf man = page. --Paul Hoffman Begin forwarded message: > From: dinoex@FreeBSD.org > Subject: Re: ports/189208: Add a mention of WITH_OPENSSL_PORT to the = pkg-descr of security/openssl > Date: May 3, 2014 at 9:19:37 AM PDT > To: phoffman@proper.com, dinoex@FreeBSD.org, dinoex@FreeBSD.org >=20 > Synopsis: Add a mention of WITH_OPENSSL_PORT to the pkg-descr of = security/openssl >=20 > State-Changed-From-To: open->feedback > State-Changed-By: dinoex > State-Changed-When: Sat May 3 18:16:54 CEST 2014 > State-Changed-Why:=20 >=20 > The description is not correct. >=20 > WITH_OPENSSL_PORT=3Dyes >=20 > Will force a port with USE_SSL to install the openssl port first. >=20 > once the openssl port is installed, > all ports with USE_SSL with link to the openssl port, > regardless of WITH_OPENSSL_PORT. >=20 >=20 >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D189208 >=20 From owner-freebsd-security@FreeBSD.ORG Sat May 3 17:55:40 2014 Return-Path: Delivered-To: FreeBSD-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED4EC5A2; Sat, 3 May 2014 17:55:40 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A91EF1454; Sat, 3 May 2014 17:55:37 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id h18so3075860igc.0 for ; Sat, 03 May 2014 10:55:37 -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:content-transfer-encoding; bh=c96kEjFP6r1TSsmPpX6tWO/lPW6+MBgwwqorM9uu8CA=; b=b67O0V135ySJcytBnt+ee0MoHrL8L/dw8FsX2Uv+8sMQau4yVMNURDVzWE9EJpDPtd 4jCyK8j8Gz2X3zQFThaxk/dTfMB8jSVDnd5gFfetxqBHW/3bjpx7Yase1prMfT9+Lh6W QftVohvHfp9CVf3kq1Au9H2GEEkdDcY5uVGHKRQvJML+90Ysen36XRKz38uf8Pub3lHC 0x6cnD5/EzZMW9nG0HW0puZpomBR6I9YSQAa4VeHw1EDjsqfux8InGUkC309fXJFLNWe zE+wDJTz2p/rbigrl44ZkbmTS7dqffanF+5g/Mk54LtBBJHMW0d51N6x37mPNH8847Sn 0yIQ== MIME-Version: 1.0 X-Received: by 10.50.112.167 with SMTP id ir7mr13113877igb.27.1399139736989; Sat, 03 May 2014 10:55:36 -0700 (PDT) Received: by 10.50.7.74 with HTTP; Sat, 3 May 2014 10:55:36 -0700 (PDT) In-Reply-To: <18F230B0-65F4-4DAE-A771-52AAE7B00573@proper.com> References: <201405031619.s43GJbXQ095254@freefall.freebsd.org> <18F230B0-65F4-4DAE-A771-52AAE7B00573@proper.com> Date: Sat, 3 May 2014 12:55:36 -0500 Message-ID: Subject: Re: ports/189208: Add a mention of WITH_OPENSSL_PORT to the pkg-descr of security/openssl From: Scot Hetzel To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dinoex@freebsd.org, FreeBSD Security , FreeBSD Ports X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 17:55:41 -0000 On Sat, May 3, 2014 at 11:35 AM, Paul Hoffman wrote: > Note that the description below does *not* match what people were saying = last week about how things work. My reading of the earlier thread was that,= unless you had WITH_OPENSSL_PORT=3Dyes in /etc/make.conf, a port needing O= penSSL would make with OpenSSL from the base. > > I am not a porter and wouldn't know where to look in the code, so I can't= figure out which is right. But it is clear that this is worth clarifying b= oth in the openssl pkg-descr *and* in the make.conf man page. > bsd.openssl.mk has the falling checks: if WITH_OPENSSL_BASE is set, then use the base system's OpenSSL. if WITH_OPENSSL_BASE or WITH_OPENSSL_PORT are not set, check if ${LOCALBASE}/lib/libcrypto.so is installed, if it is then use the OpenSSL port, otherwise use the base system's OpenSSL. if WITH_OPENSSL_PORT is set, then use the OpenSSL port So, if you install the OpenSSL port first, then ports that require OpenSSL should be built against the OpenSSL Port. --=20 DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-security@FreeBSD.ORG Sat May 3 20:54:22 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EECA610 for ; Sat, 3 May 2014 20:54:22 +0000 (UTC) Received: from fire.magemana.nl (magemana.nl [IPv6:2a01:7c8:aaae:25e::1]) by mx1.freebsd.org (Postfix) with ESMTP id 295F0150F for ; Sat, 3 May 2014 20:54:22 +0000 (UTC) Received: by fire.magemana.nl (Postfix, from userid 1003) id 107D04AB581; Sat, 3 May 2014 22:54:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by fire.magemana.nl (Postfix) with ESMTP id 0D0664AB4F4 for ; Sat, 3 May 2014 22:54:20 +0200 (CEST) Date: Sat, 3 May 2014 22:54:20 +0200 (CEST) From: Melvyn Sopacua To: freebsd-security@FreeBSD.org Subject: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Sat, 03 May 2014 21:46:36 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 20:54:22 -0000 Hello, reading the forums, guided to PFsense forums and this: http://fxr.watson.org/fxr/source/netpfil/pf/pf_norm.c?v=FREEBSD10#L1889 Could someone confirm or deny that TCP fragment reassembly is actually implemented? -- Melvyn Sopacua From owner-freebsd-security@FreeBSD.ORG Sun May 4 06:18:12 2014 Return-Path: Delivered-To: FreeBSD-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA4ED61E for ; Sun, 4 May 2014 06:18:12 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 440441317 for ; Sun, 4 May 2014 06:18:11 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s446I9ah042094; Sun, 4 May 2014 02:18:09 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s446I8mO042091; Sun, 4 May 2014 02:18:08 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21349.56224.889050.674760@hergotha.csail.mit.edu> Date: Sun, 4 May 2014 02:18:08 -0400 From: Garrett Wollman To: Scot Hetzel Subject: Re: ports/189208: Add a mention of WITH_OPENSSL_PORT to the pkg-descr of security/openssl In-Reply-To: References: <201405031619.s43GJbXQ095254@freefall.freebsd.org> <18F230B0-65F4-4DAE-A771-52AAE7B00573@proper.com> 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]); Sun, 04 May 2014 02:18:09 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-Mailman-Approved-At: Sun, 04 May 2014 11:26:06 +0000 Cc: FreeBSD Security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 06:18:12 -0000 < said: > bsd.openssl.mk has the falling checks: > if WITH_OPENSSL_BASE is set, then use the base system's OpenSSL. > if WITH_OPENSSL_BASE or WITH_OPENSSL_PORT are not set, check if > ${LOCALBASE}/lib/libcrypto.so is installed, if it is then use the > OpenSSL port, otherwise use the base system's OpenSSL. > if WITH_OPENSSL_PORT is set, then use the OpenSSL port > So, if you install the OpenSSL port first, then ports that require > OpenSSL should be built against the OpenSSL Port. Doesn't work for package builds: the OpenSSL package will not be installed prior to building the port unless the port depends on it. On the other hand, it's probably necessary for non-poudriere builds, because if your build environment *does* have the OpenSSL port installed, chances are high that anything you build will end up linking against it unless it's installed with a nonstandard PREFIX. -GAWollman From owner-freebsd-security@FreeBSD.ORG Mon May 5 08:58:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2A5E937 for ; Mon, 5 May 2014 08:58:09 +0000 (UTC) Received: from mail.tyknet.dk (mail.tyknet.dk [144.76.253.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FA9C1129 for ; Mon, 5 May 2014 08:58:08 +0000 (UTC) Received: from [IPv6:2a01:3a0:a:15::5] (unknown [IPv6:2a01:3a0:a:15::5]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 6C68121570E for ; Mon, 5 May 2014 08:57:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 mail.tyknet.dk 6C68121570E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1399280279; bh=k9oOy7PYT4vxm6t/dx8MEIb94qOaKkKG8R4qmzn4Kec=; h=Date:From:To:Subject; b=Zw7frJRy5M1HJvTeZLcx2S8430FnaO/rdaxOyATywp/R05ApHTHwNZct2756CvXeS //3qnV2omRXPBzfS3D4w8Nwqu4z5VM4JAWciMPlaiIjfYZOmgIoJEM6qBP1oQMeZdy fOXgOdi2eKr5LkmNkY79hJULgNun84jz8SwuXVw6uT2cZOxslic23EqHYStMSIMURr 8ABuvjedvaWBKCs9sr7ImOFvbdDwRkVnv/4NghHXaJPYGBuxSZuSbcLqMBCJLS2q5F Z31KSmlHev/5ohUyV9jGeEN8kSG6PfPph7rmYF83apZylQuC16UmtNcLUxdgfN2uNX G4NXhy/7A0VLA== Message-ID: <53675296.7060908@gibfest.dk> Date: Mon, 05 May 2014 10:57:58 +0200 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 08:58:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I've been following the thread on FreeBSD-SA-14:08.tcp [1] and I am concerned that people seem to have entirely misunderstood the issue entirely - or perhaps it is me :) I'll take the liberty of pasting the first two sections of the advisory [2] here, please read them well: - ---------------------------------------------------------------- I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. When network packets making up a TCP stream (``TCP segments'') are received out-of-sequence, they are maintained in a reassembly queue by the destination system until they can be re-ordered and re-assembled. II. Problem Description FreeBSD may add a reassemble queue entry on the stack into the segment list when the reassembly queue reaches its limit. The memory from the stack is undefined after the function returns. Subsequent iterations of the reassembly function will attempt to access this entry. - ---------------------------------------------------------------- Now, the talk on this list has been centered around TCP *fragments*, that is, a given TCP packet that was too big for the MTU somewhere along it's path, which has been split into several packets by a router. But the advisory never mentioned TCP fragments - the issue is about the queue in which *out of order TCP segments* are kept until they can be reassembled. This has nothing to do with TCP fragments, and blocking TCP fragments will do nothing to prevent this issue. The reason that pf's excellent "scrub" option fixes this is that it *reorders* out-of-sequence TCP packets before passing them on. If pf receives TCP packets 1, 3 and 2 in that order, it reorders them before passing them on. This means that FreeBSD doesn't have to do it, which works around the issue. To sum up: The only way to fix this issue without patching FreeBSD is to make sure out-of-order TCP segments never reach the box. Blocking TCP *fragments* will accomplish nothing except perhaps break DNSSEC and other things. Please speak up if you believe anything I wrote is incorrect, Best regards, Thomas Steen Rasmussen [1] http://lists.freebsd.org/pipermail/freebsd-security/2014-May/007683.html [2] http://www.freebsd.org/security/advisories/FreeBSD-SA-14:08.tcp.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTZ1KWAAoJEHcv938JcvpY1EsQAIBdRIDxjYbcAj/ZELqMWWBy hyt6Frpkelbc/QI5XY+bZrYaYXaDFmC3E2vGjWHvH0F8pSr/UeE9JASlaqxRAtT+ wQQLTLyqt5iDBy0dc+qqiBrwOU+rfQgruQz0arm5N8sIcwbRttP/NnW4rJGyIDzh OSiuGgqLrL/5ukRXJ0JhlFVZYOIODuheeweCq36+HJXDBewF5dAtxZOhruI3/V0p vh3fMj32Ncpjy03k1NaffSJvkQBYKlTKuOoMdhnpCxsLn5VXiES0tC+vOocivNwC KtNHouevimIo9y31qswEsDnuo79H38I6lcZNUS+NuBZU2+5iTTwclwDV+/3rbZcy Y06IAKfXe66q3H5kXDpUBc2/t+sIzs0Wooot50Nnf0dYZLcDTNE3O3rcsoYocmmR vBA+Il/LMFmBze/6pBabYtcam/LBiQxdVaocuSWybLRvSnYDpEtdqNPY9ycx+6S1 h8d8xl3i6AKAMmsdI5WMea+pFojEyMmpB6Zx5gDytKKycTgvYZau00h5plZSgSN5 uuK0uoboMjrnf4zM9IwEhqZSsdwd2JdRgesCyl/DkpygCQBgWKSZG9aKkgj4st2p mtoQmfTL8iNDVO+VD4UZ7lo4/beNKkPskBKMwN2tpmugdYLpzejf8bmFbDZl1Z8L INttv7qy1Dc27GYTUUEJ =YP2X -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon May 5 10:22:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95C27C29 for ; Mon, 5 May 2014 10:22:54 +0000 (UTC) Received: from ruxcon.org.au (ruxcon.org.au [106.186.24.76]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59152190F for ; Mon, 5 May 2014 10:22:54 +0000 (UTC) Received: by ruxcon.org.au (Postfix, from userid 111) id 2934DE98B; Mon, 5 May 2014 20:17:05 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on localhost X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, SORTED_RECIPS autolearn=disabled version=3.3.2 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ruxcon.org.au (Postfix) with ESMTP id C38BEE868 for ; Mon, 5 May 2014 20:17:03 +1000 (EST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: announce@slug.org.au Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: ausnog@lists.ausnog.net Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: bugtraq@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: dataloss@attrition.org Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: fedora-security-list@redhat.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: firewall-wizards@listserv.icsalabs.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-ids@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-linux@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-ms@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-sun@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-virus@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: forensics@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: framework@spool.metasploit.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: freebsd-security@freebsd.org Message-Id: <20140505101703.C38BEE868@ruxcon.org.au> Date: Mon, 5 May 2014 20:17:03 +1000 (EST) X-Mailman-Approved-At: Mon, 05 May 2014 11:18:50 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 10:22:54 -0000 Ruxcon 2014 Call For Presentations Melbourne, Australia, October 11th-12th http://www.ruxcon.org.au The Ruxcon team is pleased to announce the Call For Presentations for Ruxcon 2014. This year the conference will take place over the weekend of the 11th and 12th of October at the CQ Function Centre, Melbourne, Australia. .[x]. About Ruxcon .[x]. Ruxcon brings together the individual talents of the best and brightest security folk in the region, through live presentations, activities, and demonstrations. The con is held over two days in a relaxed atmosphere, allowing delegates to enjoy themselves whilst networking within the community and expanding their knowledge. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community. .[x]. Important Dates .[x]. May 1st - Call For Presentations Open September 30th - Call For Presentations Close October 6-7 - Ruxcon/Breakpoint Training October 8-9 - Breakpoint Conference October 11-12 - Ruxcon Conference .[x]. Topic Scope .[x]. o Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) .[x]. Submission Guidelines .[x]. In order for us to process your submission we require the following information: 1. Presentation title 2. Detailed summary of your presentation material 3. Name/Nickname 4. Mobile phone number 5. Brief personal biography 6. Description of any demonstrations involved in the presentation 7. Information on where the presentation material has or will be presented before Ruxcon * As a general guideline, Ruxcon presentations are between 45 and 60 minutes, including question time. If you have any enquiries about submissions, or would like to make a submission, please send an email to presentations@ruxcon.org.au .[x]. Contact .[x]. o Email: submissions@ruxcon.org.au o Twitter: @ruxcon From owner-freebsd-security@FreeBSD.ORG Mon May 5 20:48:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACDD996A for ; Mon, 5 May 2014 20:48:49 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 8730062F for ; Mon, 5 May 2014 20:48:49 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id A83E53AE82 for ; Mon, 5 May 2014 13:48:39 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-security@freebsd.org Subject: Re: Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers Ruxcon 2014 Call For Papers In-Reply-To: <20140505101703.C38BEE868@ruxcon.org.au> Date: Mon, 05 May 2014 13:48:39 -0700 Message-ID: <57199.1399322919@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:48:49 -0000 In message <20140505101703.C38BEE868@ruxcon.org.au>, cfp@ruxcon.org.au wrote: >Ruxcon 2014 Call For Presentations >Melbourne, Australia, October 11th-12th >http://www.ruxcon.org.au >... I think I'll submit a paper on the proper use of e-mail headers... :-) Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: announce@slug.org.au Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: ausnog@lists.ausnog.net Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: bugtraq@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: dataloss@attrition.org Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: fedora-security-list@redhat.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: firewall-wizards@listserv.icsalabs.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-ids@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-linux@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-ms@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-sun@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: focus-virus@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: forensics@securityfocus.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: framework@spool.metasploit.com Subject: Ruxcon 2014 Call For Papers From: cfp@ruxcon.org.au To: freebsd-security@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed May 7 21:04:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 507F7548 for ; Wed, 7 May 2014 21:04:23 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26627E2E for ; Wed, 7 May 2014 21:04:23 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id w10so1531530pde.33 for ; Wed, 07 May 2014 14:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=H4X3/X09NhB128r1L3WuLWxVo45ixzHvH2hxt84HTFg=; b=DUsk9vr/4fX7stYDUzzrnN4rhzV5bIjaljet/DdIscDEWelndfYKKVjzMGmRG2ZgvF 3sQNkQStbWFlIKGTlZAwC+cUH351NOzENwQx4c4fwzFK5Aw/7GGVeI4kK4n0LaEJupFc wbMiBRbtfWQW2umG8kx0s/mDi/Jet9zHVa+G/y1N+AVMW8FIKirdydO59LjjlLwpiiCi HrppyAqVBMClzfXHq60Bp98oYLEZqv8k16CDuENUKOqN++1eTLZQC7ZanNvkCWgYxtar Qc5505DAnyIDw5HrDpNx0VVH3Otdo+aN1NwU//8Ys5DzMwZOaSPZZZgyYFiIif1GFg+6 N6Ig== MIME-Version: 1.0 X-Received: by 10.66.240.197 with SMTP id wc5mr21919220pac.78.1399496662281; Wed, 07 May 2014 14:04:22 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.73.34 with HTTP; Wed, 7 May 2014 14:04:22 -0700 (PDT) Received: by 10.66.73.34 with HTTP; Wed, 7 May 2014 14:04:22 -0700 (PDT) In-Reply-To: <201405072013.s47KD7VT072142@freefall.freebsd.org> References: <201405072013.s47KD7VT072142@freefall.freebsd.org> Date: Wed, 7 May 2014 14:04:22 -0700 X-Google-Sender-Auth: 9__0h7mJ3cscJ9E0FzR3_yNwUwc Message-ID: Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 8.3 EoL From: Kevin Oberman To: freebsd-security@freebsd.org X-Mailman-Approved-At: Wed, 07 May 2014 21:30:31 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 21:04:23 -0000 Just a note that the last sentence of the first paragraph is out of conext. It's too late to update before April 30, 2014. Not worth correcting, but worth not repeating next time a release passes EOL. On May 7, 2014 1:13 PM, "Xin Li" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Everyone, > > As previously announced on January 31, 2014, FreeBSD 8.3 has reached its > End of Life on April 30, 2014, and will no longer be supported by the > FreeBSD Security Team. Users of FreeBSD 8.3 are strongly encouraged to > upgrade to one of the newer releases before the that date. > > The current supported branches and expected EoL dates are: > > +-----------------------------------------------------------------------+ > | Branch | Release | Type | Release date | Estimated EoL | > |-----------+------------+--------+------------------+------------------| > |stable/8 |n/a |n/a |n/a |June 30, 2015 | > |-----------+------------+--------+------------------+------------------| > |releng/8.4 |8.4-RELEASE |Extended|June 9, 2013 |June 30, 2015 | > |-----------+------------+--------+------------------+------------------| > |stable/9 |n/a |n/a |n/a |last release + 2y | > |-----------+------------+--------+------------------+------------------| > |releng/9.1 |9.1-RELEASE |Extended|December 30, 2012 |December 31, 2014 | > |-----------+------------+--------+------------------+------------------| > |releng/9.2 |9.2-RELEASE |Normal |September 30, 2013|September 30, 2014| > |-----------+------------+--------+------------------+------------------| > |stable/10 |n/a |n/a |n/a |last release + 2y | > |-----------+------------+--------+------------------+------------------| > |releng/10.0|10.0-RELEASE|Normal |January 20, 2014 |January 31, 2015 | > +-----------------------------------------------------------------------+ > > When FreeBSD 9.3-RELEASE is released, it will receive "Extended" support, > i.e., it will be supported for at least 24 months. > > - -- > Xin Li > FreeBSD Security Officer (acting) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTapMPAAoJEO1n7NZdz2rnYEkP/joPmgeJuorywT+k0zzS//uy > Fdu7K35GECdOYmZLnX204xYQX6uWjuRPbNTm8cqAjeZ2bjwhJlcU3eW78AkJ4TQY > afTTtAfw74ey7zg2cdE6b8IQL6yb/tFikVaLkTkpnLxrU/Iuqr36eEFu95aMbjmV > jPZEHabj1yJ6LwIw13mS3O+VuBysoZU/U3JRKSiFDZOr+UVymCBSojMjYPtIu/zK > wXBe4WPgeDY2I3G4FvtZodJbjhvFmJwDtk7cxfR6yVilztVBkTVYBMtMgo2Z84mC > u36Wh9JynxzTVO5Snt+5R4bORCFv38aqUw1hyI/NBXWeg+yR0BCfJK+rGNyjYm8Y > 0esAfX1BLVeteAAKlgMji1toHY9IXXRlJZX4hNtoZ0rvww2+Ej+PvNPFD0ExSyif > yM+q68O2oJpHo0NhtWeAiuhvUWWUHhR3r7NjgeyM9qBMwhnwZYQL8qcPpOwnG2eU > zdSwgGkxET939UV0HB1tsSU2S/v4pkWmKVUQ18t0EQ87EKWvA1MbiC1enqNNl40m > K3A3HRtHhg/Z9M8CGthXYiVcMa+VFBg914dW4bNB7Fv/wm6hLxn6+cGhJDnltnII > BV/nmS3o2+tdBVcQ0Kh4tJy+M/zUf/OdCrCLpeufpD02pqTHRgUl27vyuu9sBet2 > 4FE5HacmypZPJcl0tUos > =xCZn > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-announce@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org > " > From owner-freebsd-security@FreeBSD.ORG Thu May 8 00:19:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 309A09E2 for ; Thu, 8 May 2014 00:19:10 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id E94C5A2 for ; Thu, 8 May 2014 00:19:09 +0000 (UTC) MIME-version: 1.0 Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N580041O8R1RE90@st11p09mm-asmtp001.mac.com> for freebsd-security@freebsd.org; Wed, 07 May 2014 23:18:40 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Re: FreeBSD-SA-14:08.tcp has nothing to do with tcp fragments! From: Kimmo Paasiala In-reply-to: <53675296.7060908@gibfest.dk> Date: Thu, 08 May 2014 02:18:32 +0300 Message-id: References: <53675296.7060908@gibfest.dk> To: Thomas Steen Rasmussen X-Mailer: Apple Mail (2.1874) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaEhEKTEMXGx0EGx0YBBIZBBsSEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsZGmJCH2lmHX9jGXhzB x4dGBkbEk8fEQpYXBcZBBoEGxsHTU4fGBgYGUsFGx0EGx0YBBIZBBsSEBseGh8bEQpeWRdhRW1 6WBEKTEYXYmtrEQpDWhcSEgQbEx8EGxgSBBkZEQpEWBcYEQpESRcbEQpCRRdmfX8TTW9cYGUaE hEKQk4Xa0UaUlAeQ1xZXGgRCkJMF25NHXlZY2RofhhGEQpCbBdhQHxTbEsfGGR7fhEKQkAXbGd FTVJGa3pnZkkRCnBoF2McSUdAf395XX5CEQpwaBdvQGMTfBxFcxJ/ZBEKcGgXYhoccHlNWlMfY GYRCnBoF24cX11mXmJnGUBNEQpwaBd6a2USRWJBc2QdaxEKcH8XbRsaeXttW39IRW4RCnBfF2l cE2RNbH5ZRXtPEQpwXxdtSBl5AW0fTnlGaxEKcF8XYUBcARpoEmZMWEURCnBrF3pFU1pbcm9vb 05NEQpwSxdiaXITWF1cZ21TcxEKcGsXbwFcQmtAYmVNelMRCnBsF21nbgUfYU5hHFsbEQpwTBd oaVpzGR4aexxiUhE= X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-05-07_06:2014-05-07,2014-05-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405070271 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 00:19:10 -0000 --Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 5.5.2014, at 11.57, Thomas Steen Rasmussen wrote: > Signed PGP part > Hello all, >=20 > I've been following the thread on FreeBSD-SA-14:08.tcp [1] and I > am concerned that people seem to have entirely misunderstood the > issue entirely - or perhaps it is me :) >=20 > I'll take the liberty of pasting the first two sections of > the advisory [2] here, please read them well: >=20 > ---------------------------------------------------------------- > I. Background >=20 > The Transmission Control Protocol (TCP) of the TCP/IP protocol suite > provides a connection-oriented, reliable, sequence-preserving data > stream service. When network packets making up a TCP stream (``TCP > segments'') are received out-of-sequence, they are maintained in a > reassembly queue by the destination system until they can be > re-ordered and re-assembled. >=20 > II. Problem Description >=20 > FreeBSD may add a reassemble queue entry on the stack into the > segment list when the reassembly queue reaches its limit. The > memory from the stack is undefined after the function returns. > Subsequent iterations of the reassembly function will attempt > to access this entry. > ---------------------------------------------------------------- >=20 > Now, the talk on this list has been centered around TCP > *fragments*, that is, a given TCP packet that was too big for the > MTU somewhere along it's path, which has been split into several > packets by a router. >=20 > But the advisory never mentioned TCP fragments - the issue is about > the queue in which *out of order TCP segments* are kept until they > can be reassembled. This has nothing to do with TCP fragments, and > blocking TCP fragments will do nothing to prevent this issue. >=20 > The reason that pf's excellent "scrub" option fixes this is that it > *reorders* out-of-sequence TCP packets before passing them on. > If pf receives TCP packets 1, 3 and 2 in that order, it reorders > them before passing them on. This means that FreeBSD doesn't have to > do it, which works around the issue. >=20 > To sum up: The only way to fix this issue without patching FreeBSD > is to make sure out-of-order TCP segments never reach the box. > Blocking TCP *fragments* will accomplish nothing except perhaps > break DNSSEC and other things. >=20 > Please speak up if you believe anything I wrote is incorrect, >=20 >=20 > Best regards, >=20 > Thomas Steen Rasmussen >=20 > [1] > = http://lists.freebsd.org/pipermail/freebsd-security/2014-May/007683.html > [2] = http://www.freebsd.org/security/advisories/FreeBSD-SA-14:08.tcp.asc Hello, I=92ve been wondering about the same question and done some reading of = the PF source code.=20 If we assume that (so we can agree on terminology, repeating what you=92re= saying above somewhat): - A fragment is a result of IP fragmentation when a packet is too large = to fit in to the MTU. - A segment is the unit for re-ordering reassembly for packets that have = arrived out of order. The PF source code mostly uses the term =93Fragment=94 in parts of it = that implements the scrub operations and the about the only mention of a = =93Segment=94 is in this comment at line 1888 of = sys/netpfil/pf/pf_norm.c. = http://svnweb.freebsd.org/base/stable/10/sys/netpfil/pf/pf_norm.c?revision= =3D263086&view=3Dmarkup&sortby=3Drev&sortdir=3Ddown#l1888 The comment says "/* I have a dream.... TCP segment reassembly.... */=93.= =20 Unless there=92s a mixup in the terminology in PF=92s source I would = make a bet that PF scrub rules do not perform TCP segment reassembly for = packets that have arrived out of order. -Kimmo --Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTar9MAAoJEFvLZC0FWRVpuE0H/29772pBlkWxv+n/Ggl6hPc0 21QBb5Oh96cJRRBOaGwotjqi8RkIdmop74+WVZXAXr1H02oPOW1HJhmu+WbzK9O+ WjqVWKtSvd+TP/Dm6T2GtMC2WxRSy0u9fhXIkYWOBjy1tEBmLTA5hewDunC7zQNZ f98nFR0Xe5VoYdzlhADyO/MNovSm6V4uJZdYbedDcGjP0e7RtWZd14KWHC+JctwU kVMJfXx2EyxC1cTCv2s3aXHcIqLAowlEhjpSBv9l7u922oNRmzdtw/QzFLIOwKoH UjuDP1AK7V+URay2s21MBOBsgZz5g+dNPf7ThYURQMZ7CkcWpROn39YY/v8qJCs= =DCeq -----END PGP SIGNATURE----- --Apple-Mail=_18821777-BDDD-4687-9667-078ACD830CE0-- From owner-freebsd-security@FreeBSD.ORG Thu May 8 08:29:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9CCC521 for ; Thu, 8 May 2014 08:29:49 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6E6FE6C for ; Thu, 8 May 2014 08:29:49 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WiJi5-0006Hz-S7; Thu, 08 May 2014 12:29:45 +0400 Date: Thu, 8 May 2014 12:29:45 +0400 From: Slawa Olhovchenkov To: Kevin Day Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:08.tcp Message-ID: <20140508082945.GA22384@zxy.spb.ru> References: <201404300435.s3U4ZAw1093717@freefall.freebsd.org> <6D007FDB-D94D-48BD-B066-30A23F9CB472@dragondata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D007FDB-D94D-48BD-B066-30A23F9CB472@dragondata.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:29:50 -0000 On Wed, Apr 30, 2014 at 01:48:41PM -0500, Kevin Day wrote: > > Affects: All supported versions of FreeBSD. > > Corrected: 2014-04-30 04:04:20 UTC (stable/8, 8.4-STABLE) > > 2014-04-30 04:05:47 UTC (releng/8.4, 8.4-RELEASE-p9) > > 2014-04-30 04:05:47 UTC (releng/8.3, 8.3-RELEASE-p16) > > 2014-04-30 04:04:20 UTC (stable/9, 9.2-STABLE) > > 2014-04-30 04:05:47 UTC (releng/9.2, 9.2-RELEASE-p5) > > 2014-04-30 04:05:47 UTC (releng/9.1, 9.1-RELEASE-p12) > > 2014-04-30 04:03:05 UTC (stable/10, 10.0-STABLE) > > 2014-04-30 04:04:42 UTC (releng/10.0, 10.0-RELEASE-p2) > > Does anyone know the lower bound for how far back this bug exists? Is it only present in the above versions, or does it affect earlier versions that aren't listed? > > (trying to come up with a deployment plan for some servers stuck on 8.1 and 7.x due to vendors abandoning device drivers) I think this is result of fixing kern/155407 in r226113 and r228016. From owner-freebsd-security@FreeBSD.ORG Wed May 14 00:00:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3033E24F; Wed, 14 May 2014 00:00:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 117FF2C6D; Wed, 14 May 2014 00:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4E001bg029901; Wed, 14 May 2014 00:00:01 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4E001KB029899; Wed, 14 May 2014 00:00:01 GMT (envelope-from security-advisories@freebsd.org) Date: Wed, 14 May 2014 00:00:01 GMT Message-Id: <201405140000.s4E001KB029899@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:10.openssl Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 00:00:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:10.openssl Security Advisory The FreeBSD Project Topic: OpenSSL NULL pointer deference vulnerability Category: contrib Module: openssl Announced: 2014-05-13 Affects: FreeBSD 10.x. Corrected: 2014-05-13 23:19:16 UTC (stable/10, 10.0-STABLE) 2014-05-13 23:22:28 UTC (releng/10.0, 10.0-RELEASE-p3) CVE Name: CVE-2014-0198 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. The TLS protocol supports an alert protocol which can be used to signal the other party with certain failures in the protocol context that may require immediate termination of the connection. II. Problem Description An attacker can trigger generation of an SSL alert which could cause a null pointer deference. III. Impact An attacker may be able to cause a service process that uses OpenSSL to crash, which can be used in a denial-of-service attack. IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, or not using SSL_MODE_RELEASE_BUFFERS and use the same process to handle multiple SSL connections, are not vulnerable. The FreeBSD base system service daemons and utilities do not use the SSL_MODE_RELEASE_BUFFERS mode. However, many third party software uses this mode to reduce their memory footprint and may therefore be affected by this issue. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:10/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:10/openssl.patch.asc # gpg --verify openssl.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r265986 releng/10.0/ r265987 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTcq5IAAoJEO1n7NZdz2rnNb4QAODp1Pxk3GlTwlptWQkC+DJb bwd2RRtkvkz677JIbdtyM7b5POgUih/NtAF9Yyy/pg8IJcSRiv0f7F5L+maV9nee KGb27zizWOgIqor6HhRAv2OniVN271OfoyCkt0xRmigBR6dQ80iBVuCk6McvxvjL 5Yfw8wtfF8zAo5p1d4V3EEPOIVPwgJ31YnB/sVv+SyV6Ldl5DS0Gp1Cm9KjvaJUI CUIljIaH6AFuzs671V4DpuFPtFPIsvGUhEdpf6+ypVJN1J/D+BNRvoIX1zxou4Kf 34qB6cs/LlyBKCPctK/qLU7UScNsuUItpWrw5ESHFHdgsTr8XA9POxU72wlCRCoQ T2A6zIqPQRgCWfrPnmJNwLN9riMQGc2oFBXd19iITyc8/7OcXAFnzIy+zu++jZp6 rMwGIUCg5UKkSGVWnoYyS/1SQRYqi4MzUqC/AwpQHKoE5CqUzVCJ7zGTFcsie0o4 wfWoFlkgbNl0Attn4HLuXncjvGVCMeWqUERKBU7xIxC1D5PKXF5QmCUqlZrddBaw ATIFsPEopu2bX/+sbgcGKSF5WAWwdT92vIgarjW3UkKDYihRNKusrOwp3sue7Iw+ QIweOaJLqpSnfQ3me62I3fWYjRwceeASeTx7dYdxrK1Dx5DnlN8gGwwhl/7cvoWe Xm6DqYXeQRsIxZ7Ng/PO =4EYM -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed May 14 10:43:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C486FD0E for ; Wed, 14 May 2014 10:43:09 +0000 (UTC) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by mx1.freebsd.org (Postfix) with ESMTP id 69FED227B for ; Wed, 14 May 2014 10:43:09 +0000 (UTC) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by strudel.ki.iif.hu (Postfix) with ESMTP id D5760110 for ; Wed, 14 May 2014 12:43:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id Bb46olkSB+vA for ; Wed, 14 May 2014 12:43:04 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 3077A558; Wed, 14 May 2014 12:43:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 2763C110 for ; Wed, 14 May 2014 12:43:04 +0200 (CEST) Date: Wed, 14 May 2014 12:43:04 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: freebsd-security@freebsd.org Subject: freebsd-update on Re: FreeBSD Security Advisory FreeBSD-SA-14:10.openssl In-Reply-To: <201405140000.s4E0023k029906@freefall.freebsd.org> Message-ID: References: <201405140000.s4E0023k029906@freefall.freebsd.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:43:09 -0000 Dear All, The freebsd-update a bit suspicious: " root@skye:/usr/home/mohacsi # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.0-RELEASE from update3.freebsd.org... done. Fetching metadata index... done. Fetching 2 metadata patches.. done. Applying metadata patches... done. Inspecting system... done. Preparing to download files... done. Fetching 11 patches.....10 done. Applying patches... done. The following files will be updated as part of updating to 10.0-RELEASE-p3: /bin/freebsd-version /boot/kernel/ciss.ko /boot/kernel/ciss.ko.symbols /boot/kernel/kernel /boot/kernel/kernel.symbols /usr/lib/libssl.a /usr/lib/libssl.so.7 /usr/lib/libssl_p.a /usr/lib32/libssl.a /usr/lib32/libssl.so.7 /usr/lib32/libssl_p.a " It seems to me the ciss(4) also updated. Is it intentional? Is it harmless? Regards, Janos Mohacsi Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 14 May 2014, FreeBSD Security Advisories wrote: > ----- Topal: Output generated on Wed May 14 12:38:26 CEST 2014 > ----- Topal: GPG output starts ----- > gpg: Signature made Wed May 14 01:44:08 2014 CEST using RSA key ID 5DCF6AE7 > gpg: Can't check signature: public key not found > ----- Topal: GPG output ends ----- > ----- Topal: Original message starts ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-14:10.openssl Security Advisory > The FreeBSD Project > > Topic: OpenSSL NULL pointer deference vulnerability > > Category: contrib > Module: openssl > Announced: 2014-05-13 > Affects: FreeBSD 10.x. > Corrected: 2014-05-13 23:19:16 UTC (stable/10, 10.0-STABLE) > 2014-05-13 23:22:28 UTC (releng/10.0, 10.0-RELEASE-p3) > CVE Name: CVE-2014-0198 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is > a collaborative effort to develop a robust, commercial-grade, full-featured > Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) > and Transport Layer Security (TLS v1) protocols as well as a full-strength > general purpose cryptography library. > > The TLS protocol supports an alert protocol which can be used to signal the > other party with certain failures in the protocol context that may require > immediate termination of the connection. > > II. Problem Description > > An attacker can trigger generation of an SSL alert which could cause a null > pointer deference. > > III. Impact > > An attacker may be able to cause a service process that uses OpenSSL to crash, > which can be used in a denial-of-service attack. > > IV. Workaround > > No workaround is available, but systems that do not use OpenSSL to implement > the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) > protocols, or not using SSL_MODE_RELEASE_BUFFERS and use the same process > to handle multiple SSL connections, are not vulnerable. > > The FreeBSD base system service daemons and utilities do not use the > SSL_MODE_RELEASE_BUFFERS mode. However, many third party software uses this > mode to reduce their memory footprint and may therefore be affected by this > issue. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-14:10/openssl.patch > # fetch http://security.FreeBSD.org/patches/SA-14:10/openssl.patch.asc > # gpg --verify openssl.patch.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > Recompile the operating system using buildworld and installworld as > described in . > > Restart all deamons using the library, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/10/ r265986 > releng/10.0/ r265987 > - ------------------------------------------------------------------------- > > 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 v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTcq5IAAoJEO1n7NZdz2rnNb4QAODp1Pxk3GlTwlptWQkC+DJb > bwd2RRtkvkz677JIbdtyM7b5POgUih/NtAF9Yyy/pg8IJcSRiv0f7F5L+maV9nee > KGb27zizWOgIqor6HhRAv2OniVN271OfoyCkt0xRmigBR6dQ80iBVuCk6McvxvjL > 5Yfw8wtfF8zAo5p1d4V3EEPOIVPwgJ31YnB/sVv+SyV6Ldl5DS0Gp1Cm9KjvaJUI > CUIljIaH6AFuzs671V4DpuFPtFPIsvGUhEdpf6+ypVJN1J/D+BNRvoIX1zxou4Kf > 34qB6cs/LlyBKCPctK/qLU7UScNsuUItpWrw5ESHFHdgsTr8XA9POxU72wlCRCoQ > T2A6zIqPQRgCWfrPnmJNwLN9riMQGc2oFBXd19iITyc8/7OcXAFnzIy+zu++jZp6 > rMwGIUCg5UKkSGVWnoYyS/1SQRYqi4MzUqC/AwpQHKoE5CqUzVCJ7zGTFcsie0o4 > wfWoFlkgbNl0Attn4HLuXncjvGVCMeWqUERKBU7xIxC1D5PKXF5QmCUqlZrddBaw > ATIFsPEopu2bX/+sbgcGKSF5WAWwdT92vIgarjW3UkKDYihRNKusrOwp3sue7Iw+ > QIweOaJLqpSnfQ3me62I3fWYjRwceeASeTx7dYdxrK1Dx5DnlN8gGwwhl/7cvoWe > Xm6DqYXeQRsIxZ7Ng/PO > =4EYM > -----END PGP SIGNATURE----- > ----- Topal: Original message ends ----- > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Wed May 14 10:47:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA9A5E54 for ; Wed, 14 May 2014 10:47:34 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE5222D0 for ; Wed, 14 May 2014 10:47:34 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 4087420E7088B; Wed, 14 May 2014 10:47:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id E67C820E70885; Wed, 14 May 2014 10:47:22 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Mohacsi Janos" , References: <201405140000.s4E0023k029906@freefall.freebsd.org> Subject: Re: freebsd-update on Re: FreeBSD Security Advisory FreeBSD-SA-14:10.openssl Date: Wed, 14 May 2014 11:47:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:47:34 -0000 ----- Original Message ----- From: "Mohacsi Janos" To: Sent: Wednesday, May 14, 2014 11:43 AM Subject: freebsd-update on Re: FreeBSD Security Advisory FreeBSD-SA-14:10.openssl > Dear All, > The freebsd-update a bit suspicious: > " > root@skye:/usr/home/mohacsi # freebsd-update fetch > Looking up update.FreeBSD.org mirrors... 5 mirrors found. > Fetching metadata signature for 10.0-RELEASE from update3.freebsd.org... > done. > Fetching metadata index... done. > Fetching 2 metadata patches.. done. > Applying metadata patches... done. > Inspecting system... done. > Preparing to download files... done. > Fetching 11 patches.....10 done. > Applying patches... done. > > The following files will be updated as part of updating to > 10.0-RELEASE-p3: > /bin/freebsd-version > /boot/kernel/ciss.ko > /boot/kernel/ciss.ko.symbols > /boot/kernel/kernel > /boot/kernel/kernel.symbols > /usr/lib/libssl.a > /usr/lib/libssl.so.7 > /usr/lib/libssl_p.a > /usr/lib32/libssl.a > /usr/lib32/libssl.so.7 > /usr/lib32/libssl_p.a > " > > It seems to me the ciss(4) also updated. Is it intentional? Is it > harmless? ciss(4) was included in a seperate errata notice this morning which detailed how it could cause corruption, so I would expect that updating it is indeed correct. Regards Steve From owner-freebsd-security@FreeBSD.ORG Wed May 14 13:58:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17EFBDA; Wed, 14 May 2014 13:58:56 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A704A2234; Wed, 14 May 2014 13:58:55 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id x13so2815357qcv.2 for ; Wed, 14 May 2014 06:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=CG0v5gOwTbBmlS+2IPK9vINoUeprxugnfKYFUaZUA04=; b=vD/LFlo6dwYjmEQnuyP0BfS7iMGlueUKOfASAgzT4dlQuBVcIrOjRXCDHNpkvin2WT dfW3yzGHcSHF8tCxQOcuoGbriy6J4eS3uD8/aNyABqTEeIG6iqW4pwDcJjznPUHS3G5R 9mzlSTQL4z8/bHy24NXQwDKTykE2zdRsi593K1v/vpXcc5uMeJZ3BHQH+QZ//bcGxR4F uJEpHLiYytOtjwpTicKQVuxliUm+eOSHrgpHRjRFhMK2LmC+BWeofu+lq9b+cQ/DZoy/ 8ZflJcTnxWSf3ZysqIoXWH3rR+D2lZCPZx56+cdVJ4X1uHdhA16JThgwbDkmo9chDoRF d4vA== X-Received: by 10.140.96.68 with SMTP id j62mr5832925qge.5.1400075934858; Wed, 14 May 2014 06:58:54 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id k9sm3018963qat.18.2014.05.14.06.58.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 May 2014 06:58:54 -0700 (PDT) Date: Wed, 14 May 2014 09:58:52 -0400 From: Shawn Webb To: freebsd-current@freebsd.org;, freebsd-security@freebsd.org;, freebsd-stable@freebsd.org Subject: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable Message-ID: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lymARMIdFDV9dylT" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:58:56 -0000 --lymARMIdFDV9dylT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable@. Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our implementation is based off of PaX's. Oliver Pinter, Danilo Egea, and I have been working hard to bring more features and robust stability to our ASLR patches. We've done extensive testing on amd64. We'd like to get as many people testing these patches. Given the nature of them, we'd also like as many eyeballs reviewing the code as well. I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on the RPI), when a parent forks a child, and the child gracefully exits, the parent segfaults with the pc register pointing to 0xc0000000. That address is always the same, no matter the application. If anyone knows the ARM architecture well, and how FreeBSD ties into it, I'd like a little guidance. I also have a sparc64 box, but I'm having trouble getting a vanilla 11-current system to be stable on it. I ought to file a few PRs. You can find links to the patches below. Patch for 11-current: http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff Patch for 10-stable: http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff Thanks, Shawn Webb --lymARMIdFDV9dylT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTc3abAAoJEGqEZY9SRW7u580QAJWLg7UFiDYh4kScgsbyKmGT oAtZvijHAmqqRZ3TAbenWfset3MkyxxQ56QupEVvIl7TiveyEzgYNOVsOluur+gZ KtfM8IUUWQqaxQL7H0lfG304KpZGM6dWahxIPTeM3nOwkb70Z9HY4geuS5B2cSLs 4Js85lwKE09a9dzyCZWz13bB173zTLD4Drx23L5LQdvLfYrn+bQ83SScyq8arzoy 0e3AltDxxqYw50FMCe3865856Umi6envzm1bV/fMMp36Wc4usgLjTcodxqEJvrGs cRTKCg5lJZQCrPmqOSLaxOwDa9ni6Q6CDHNOi0D1RzfAvLQKzvR+Cro33494PAOL Lx33GfN2YRPpCnJ7E46/M2Kk+4JF6wCIqqsg8WZAoXdHs9+grs86ID24lueUxR4Z HL7ubdx68thozBbdq89m9Lg5Iji7Z7UVEVClVgnS+Sy9EoBiJIiFULgB1OuVITzS TPQ20mfwuIEVxfU2mOdf8FdJuWw5Pb5SrivaNgi+lO73H/et9yhR/SGmoA1jo086 4Tm0acmsq0ITI8gqtIJ0rypjqJxhkvID9qeXsmd8Q6P03XuXV/U7Mr/Ry5Y1iXbh /lAW6fRosqgWK2UpNTFOXSKG1BVjv+UictZGtPnGV2c5BTeCVNb9NT558jv0FolU Ica4f4E1I5Auioxdw8Y9 =xhTr -----END PGP SIGNATURE----- --lymARMIdFDV9dylT-- From owner-freebsd-security@FreeBSD.ORG Wed May 14 17:10:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02348558; Wed, 14 May 2014 17:10:04 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DB992451; Wed, 14 May 2014 17:10:03 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id a108so3271609qge.36 for ; Wed, 14 May 2014 10:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=NKDnTiMs+LE6X4YRIDqGx9ycepCEUctPytISwVTq5/w=; b=PNCBPUtqN3WCFrqLE05XYHJkpWV6Wd3R4SFN8SSEH1N63ASVAeUTWelZZDxNs8UVor H0RXqGdqtB68WHlZ3Y6bwHIkh1VsEG1JOrohq/0rjSdu9/E3SCG9yynw4Gltw8Xl7PhN gU/7lHLICcJ8669CebUGJrGNgUTKsFM2b23u0hCtkmzWfBRWNe2hmyPKAV5obBmPlciI EdJPOppDAKV7TmTU1m6rhioi7TOz2b8GTZLM8DldkAm3dhg0WFquj8GGiDMtdLTIW4Wl rDz4lysf3BI1dmOHYW+HhdLcgXWcM2FP3lij0F8ep0PhC9OOdW4hXXSuYdvZIpEg47RE 2VRg== X-Received: by 10.140.95.80 with SMTP id h74mr7742148qge.2.1400087402642; Wed, 14 May 2014 10:10:02 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id y3sm3695714qaj.49.2014.05.14.10.10.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 May 2014 10:10:01 -0700 (PDT) Date: Wed, 14 May 2014 13:09:59 -0400 From: Shawn Webb To: Adrian Chadd Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable Message-ID: <20140514170959.GA31277@pwnie.vrt.sourcefire.com> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-security@freebsd.org, freebsd-current , FreeBSD Stable Mailing List X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:10:04 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It runs on all architectures FreeBSD supports. The question is how well it runs. The wider the testing, the better the code, of course. We're actively testing on amd64 and i386 with limited testing on sparc64 and ARM. I've been running with this patches on amd64 on multiple machines for months. amd64 is rock solid from my experience. But your mileage may vary, hence the CFT. :-) Thanks, Shawn On May 14, 2014 10:02 AM -0700, Adrian Chadd wrote: > Hi! >=20 > Cool! Does it run on MIPS? :P >=20 >=20 > -a >=20 >=20 > On 14 May 2014 06:58, Shawn Webb wrote: > > Hey All, > > > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > > > Address Space Layout Randomization, or ASLR for short, is an exploit > > mitigation technology. It helps secure applications against low-level > > exploits. A popular secure implementation is known as PaX ASLR, which is > > a third-party patch for Linux. Our implementation is based off of PaX's. > > > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > > features and robust stability to our ASLR patches. We've done extensive > > testing on amd64. We'd like to get as many people testing these patches. > > Given the nature of them, we'd also like as many eyeballs reviewing the > > code as well. > > > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > > the RPI), when a parent forks a child, and the child gracefully exits, > > the parent segfaults with the pc register pointing to 0xc0000000. That > > address is always the same, no matter the application. If anyone knows > > the ARM architecture well, and how FreeBSD ties into it, I'd like a > > little guidance. > > > > I also have a sparc64 box, but I'm having trouble getting a vanilla > > 11-current system to be stable on it. I ought to file a few PRs. > > > > You can find links to the patches below. > > > > Patch for 11-current: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current= -aslr-segvguard-SNAPSHOT.diff > > > > Patch for 10-stable: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-= 10-aslr-segvguard-SNAPSHOT.diff > > > > Thanks, > > > > Shawn Webb --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTc6NnAAoJEGqEZY9SRW7u6+AP/0uOILtPQTmgOjtBOVYTmula sHDK1jwa6QQOTgRhUf6Nep76gUmeyOEBCCv8ExJB9YoOHF3ndLydz8RhkxEvHOWv RLEfmVf8ZFIw0flP9NPlzOdgleOmxFekzOSUUQR8B/bIRGprrDCBfob7CpoKNp79 ygKJQgICmz651n3fLGH7NZyHe+Iw4X1Et8EMfRNyemjB1+X3IKB4egdntXe/qbAk +Viig7g5A8iGUFZ9vtPfJjSMMccIkWTTsI9rgajhOtR1GRA3Cx69dqclkgMB4Ijl yekMf3iuUcmvMVddIRcszi+5WXXUIFGTdu2eNxhJqf6ejB51vDo9CoV0cfrtFRfz RT1f2S/rcl6+m7wexvv/R7yoDYJTebDQoN0M3zH7SrmeTc7LkYRPaLlDbnKKp1Q7 IR+ia/46ypDprnFtNw3tg9zah2bsGo93eQyBgOx2lzADMZKBVf27mFTVRwH4dDd/ 87TugPAMfK/ViiF4mZ7yuQEJRYcaHMUVx4ayS1xUuBAF+VbNYxR3minpZKKy3Le0 6PZMifTYCgM+D3ny6iUYVhIx5XzBTNnrWMJgOg7p/PYVY9jRW7U9/7hZS57koE1b jzr9wtu+Zp5jH5V1UwBXngW9+6854bV/5dveF0bh2PqB2bEPvWtNBscaY8B/9GSd JmLQ73v8jEpfcK73TqJ9 =a9Ka -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-security@FreeBSD.ORG Wed May 14 17:02:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0429CDF1; Wed, 14 May 2014 17:02:11 +0000 (UTC) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97C7423CD; Wed, 14 May 2014 17:02:10 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id i17so3255564qcy.36 for ; Wed, 14 May 2014 10:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0AgJCZtCTU3IFbwQo02Wv/q7DvEnT6pEaVUOwXXctLQ=; b=q36ggtuqlBJkZfEbablxYhv/WAoJRwvlYpnF0XVQY2iWysRrxS3kajYtS+JE4d2kH4 YXGhBZkTnUsxvxnBZ8CrXeix1YvyT/xJkVUfcUxAmYOuVPW3CY17CCtFrgE6Wdp7rQVO hYTcH+86umUWs1QUOwuNztmLJ6Vg3J2O6halrtZtwBnZdb+Hl/o/BMxoHZYxTwjrVuSu Dv9HKH/9DLdnIcxePnxQcp0wEiPs3lM8W9iI1rsLyShQ8p3iUk+S87AlKrp8iPQJo8TH UnEI/o+/6OolfDmQq9ne3vdW29xoUKCsJnZIDBK7iYgSf8wCe10NBeJPRN71tX/Nt7yl 06cg== MIME-Version: 1.0 X-Received: by 10.140.104.195 with SMTP id a61mr7324093qgf.102.1400086929717; Wed, 14 May 2014 10:02:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Wed, 14 May 2014 10:02:09 -0700 (PDT) In-Reply-To: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> Date: Wed, 14 May 2014 10:02:09 -0700 X-Google-Sender-Auth: GmFptiiCoBTRx-N3HUWrxicEmm8 Message-ID: Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Adrian Chadd To: Shawn Webb Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 14 May 2014 21:18:39 +0000 Cc: freebsd-security@freebsd.org, freebsd-current , FreeBSD Stable Mailing List X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:02:11 -0000 Hi! Cool! Does it run on MIPS? :P -a On 14 May 2014 06:58, Shawn Webb wrote: > Hey All, > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > Address Space Layout Randomization, or ASLR for short, is an exploit > mitigation technology. It helps secure applications against low-level > exploits. A popular secure implementation is known as PaX ASLR, which is > a third-party patch for Linux. Our implementation is based off of PaX's. > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > features and robust stability to our ASLR patches. We've done extensive > testing on amd64. We'd like to get as many people testing these patches. > Given the nature of them, we'd also like as many eyeballs reviewing the > code as well. > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > the RPI), when a parent forks a child, and the child gracefully exits, > the parent segfaults with the pc register pointing to 0xc0000000. That > address is always the same, no matter the application. If anyone knows > the ARM architecture well, and how FreeBSD ties into it, I'd like a > little guidance. > > I also have a sparc64 box, but I'm having trouble getting a vanilla > 11-current system to be stable on it. I ought to file a few PRs. > > You can find links to the patches below. > > Patch for 11-current: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > Patch for 10-stable: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > Thanks, > > Shawn Webb From owner-freebsd-security@FreeBSD.ORG Wed May 14 17:18:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B23B3BD2; Wed, 14 May 2014 17:18:35 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50F1A255B; Wed, 14 May 2014 17:18:35 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id a108so3291438qge.36 for ; Wed, 14 May 2014 10:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=V7EFTOsYq5afLCXkup+4+gos1RIJMdSuwH9zhDkc4jQ=; b=XZgsGCDtYHCAL9S5mws7AOCrQhJzMVupLlmqC4aDr1lOro7JXBDgBmDfRrj4qPfmkP d/AG2h1/qVE7+zci/8R/AR8bvUAAGza+tlOpf347EfmzXUxORVjJCakBFCCKS+8wAeEz uSYRF0le8zaGo4lnnq73vUwtqlqmSiMHQv4WS3i1Lfv94Ja0+qrKp+1ZBFN4K1eB9894 aPCwwSv/WsFLsxn+OAMoqsf40/PZXDPBZxvyfvCAyj+LZBMkJ9xpc6k8H0cbeqU0jUD9 jYR0lEkRfJkpzC8cP9/QRP9yDe8sOI1bIhlqv6/Pexqgz706Q2RojbsZZ2jtUl6u72ml liMw== MIME-Version: 1.0 X-Received: by 10.140.22.209 with SMTP id 75mr7803141qgn.4.1400087914537; Wed, 14 May 2014 10:18:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.191.201 with HTTP; Wed, 14 May 2014 10:18:34 -0700 (PDT) In-Reply-To: <20140514170959.GA31277@pwnie.vrt.sourcefire.com> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <20140514170959.GA31277@pwnie.vrt.sourcefire.com> Date: Wed, 14 May 2014 10:18:34 -0700 X-Google-Sender-Auth: nowHCVcNJhPWfq7GVWNQxRq5Tn8 Message-ID: Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Adrian Chadd To: Shawn Webb Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 14 May 2014 21:18:49 +0000 Cc: freebsd-security@freebsd.org, freebsd-current , FreeBSD Stable Mailing List X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:18:35 -0000 On 14 May 2014 10:09, Shawn Webb wrote: > It runs on all architectures FreeBSD supports. The question is how well > it runs. The wider the testing, the better the code, of course. We're > actively testing on amd64 and i386 with limited testing on sparc64 and > ARM. I've been running with this patches on amd64 on multiple machines > for months. amd64 is rock solid from my experience. But your mileage may > vary, hence the CFT. :-) :) So for MIPS, there's a documented way to run up the emulator framework to do testing. https://wiki.freebsd.org/FreeBSD/MipsEmulation That way you can give it a whirl before us MIPS people with hardware can get around to it. :P -a From owner-freebsd-security@FreeBSD.ORG Fri May 23 23:24:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7371E5FE; Fri, 23 May 2014 23:24:31 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2675B208B; Fri, 23 May 2014 23:24:31 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id i4so6360099oah.33 for ; Fri, 23 May 2014 16:24:30 -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=u95dhOhVt7zFBDnwHenhVMslCnIQ5lxkJHJsROfKxTM=; b=hCBX6+rxJzjCtdsB6NYgpT3aBSwmHT0u3bzzJ74k8Q6WSAS6kwIqx5u6fbNP/Y4av9 0q5ZfgQpk1+aOjpbPzl2hduGfsrPQp0ZDI+vxWLw+IM/vrD8Y/J7KWeUNZZa9o9v10y/ EsQ4jkzXYDnkzMxSICMLC5q2DDqVRF+jhIOMebDE7GMKGGFwtmodDOuYb/S5SpXTrcD1 RYADQp05IomTCUMW8BinkoTCsqVItP26VFn6j5n9MPc9Pqhd9czFbWKfm9g0FDVdy666 gMa+DFlUEdwIf+wIWFqt1Cl7uxMpuskqGEso5z1s5Dc4ADT/+N61IhuiwBvBchaLvlfA pPFw== MIME-Version: 1.0 X-Received: by 10.182.229.101 with SMTP id sp5mr8673093obc.52.1400887470143; Fri, 23 May 2014 16:24:30 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Fri, 23 May 2014 16:24:30 -0700 (PDT) In-Reply-To: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> Date: Sat, 24 May 2014 01:24:30 +0200 Message-ID: Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Oliver Pinter To: Shawn Webb Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 23:24:31 -0000 On 5/14/14, Shawn Webb wrote: > Hey All, > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > Address Space Layout Randomization, or ASLR for short, is an exploit > mitigation technology. It helps secure applications against low-level > exploits. A popular secure implementation is known as PaX ASLR, which is > a third-party patch for Linux. Our implementation is based off of PaX's. > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > features and robust stability to our ASLR patches. We've done extensive > testing on amd64. We'd like to get as many people testing these patches. > Given the nature of them, we'd also like as many eyeballs reviewing the > code as well. > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > the RPI), when a parent forks a child, and the child gracefully exits, > the parent segfaults with the pc register pointing to 0xc0000000. That > address is always the same, no matter the application. If anyone knows > the ARM architecture well, and how FreeBSD ties into it, I'd like a > little guidance. > > I also have a sparc64 box, but I'm having trouble getting a vanilla > 11-current system to be stable on it. I ought to file a few PRs. > > You can find links to the patches below. > > Patch for 11-current: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > Patch for 10-stable: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > Thanks, > > Shawn Webb > New round of patches are there: 11-CURRENT: http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-current-aslr-segvguard-SNAPSHOT.diff 10-STABLE: http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff What's changed related to previous tag: 11-CURRENT: Oliver Pinter (17): PAX ASLR: update license in kern_pax_aslr.c PAX: update license in kern_pax.c PAX SEGVGUARD: update license in kern_pax_segvguard.c PAX: update license in pax.h PAX ASLR: remove unneeded parameter from pax_aslr_stack function PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl PAX ASLR: fixed debug sysctl PAX: blacklist clang and related binaries from PIE support PAX ASLR: make ASLR by default opt-out Merge remote-tracking branch 'freebsd/master' into hardened/current/aslr Merge branch 'hardened/current/aslr' of github.com:HardenedBSD/hardenedBSD into hardened/current/aslr Shawn Webb (10): Remove CAN_PIE in preparation for NO_PIE Merge remote-tracking branch 'upstream/master' into hardened/current/aslr PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable Merge remote-tracking branch 'upstream/master' into hardened/current/aslr Disable PAX_SEGVGUARD in LATT-ASLR kernel PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings PAX ASLR: Fix bug with pax_aslr_active() PAX ASLR: Use a full kernel config for LATT-ASLR Revert "PAX: blacklist clang and related binaries from PIE support" Revert "Revert "PAX: blacklist clang and related binaries from PIE support"" 10-STABLE: Oliver Pinter (20): PAX ASLR: update license in kern_pax_aslr.c PAX: update license in kern_pax.c PAX SEGVGUARD: update license in kern_pax_segvguard.c PAX: update license in pax.h PAX ASLR: remove unneeded parameter from pax_aslr_stack function PAX LOG: implement new logging subsystem PAX LOG: fix pax_ulog_segvguard PAX LOG: added sysctl's and tunables PAX ASLR: use PAX LOG PAX LOG: fix pax_ulog_##name() PAX LOG: fix prison init PAX LOG: fixed log and ulog sysctl PAX ASLR: fixed debug sysctl Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr added OPN-ASLR kernel config PAX: Remove CAN_PIE in preparation for NO_PIE from /bin/sh PAX: blacklist clang and related binaries from PIE support PAX ASLR: make ASLR by default opt-out Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr Shawn Webb (4): PAX: Remove CAN_PIE in preparation for NO_PIE PAX ASLR: Blacklist the applications that don't support being built as a position-independent executable PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings PAX ASLR: Fix bug with pax_aslr_active() From owner-freebsd-security@FreeBSD.ORG Sat May 24 00:35:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D3CC7F6; Sat, 24 May 2014 00:35:29 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D82BB25E7; Sat, 24 May 2014 00:35:28 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id q108so9053347qgd.41 for ; Fri, 23 May 2014 17:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VN+qHBx9X+q5u+TaSn89y6Reu2C40Jtv1UWqrtKtWnw=; b=eEEp9dpW2bDM0Jinl81LSV1Ur8BLCthpBe4fiegQ4qZKol8jjhKTKtE/IVmwPMY2Wt NXBAL5pbp4SJ0iTaNIQvzWfhqPdSD9uicTSlgKEhdO3PYgkQO+xfBL50Wan0gTRNjeFv JQzw+KtmhT/TylynHCtrOjlHVebhj6g4D/QsdoezpYc39WKDILlts/KAnoxIFbyBtI5s 76XseDpUS+ieJORiducPaXDR4Q0k3D8Tnjn9vN2yEh0d2Rjtere0wH+SY+WA0dwSG7oU +0upQFY7YnaC6bzMchjW2SwI8apZiIqPddEZdidlR7YGd2xb/V8s3a/pbKxtISyKlrNr BUcQ== X-Received: by 10.224.57.142 with SMTP id c14mr12208338qah.23.1400891728042; Fri, 23 May 2014 17:35:28 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id u77sm2947055qga.46.2014.05.23.17.35.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 May 2014 17:35:27 -0700 (PDT) Date: Fri, 23 May 2014 20:35:25 -0400 From: Shawn Webb To: "Wojciech A. Koszek" Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable Message-ID: <20140524003525.GC2029@pwnie.vrt.sourcefire.com> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <20140523195329.GC91702@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <20140523195329.GC91702@FreeBSD.org> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Oliver Pinter X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 00:35:29 -0000 --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On May 23, 2014 07:53 PM +0000, Wojciech A. Koszek wrote: > On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > > Hey All, > >=20 > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > >=20 > > Address Space Layout Randomization, or ASLR for short, is an exploit > > mitigation technology. It helps secure applications against low-level > > exploits. A popular secure implementation is known as PaX ASLR, which is > > a third-party patch for Linux. Our implementation is based off of PaX's. > >=20 > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > > features and robust stability to our ASLR patches. We've done extensive > > testing on amd64. We'd like to get as many people testing these patches. > > Given the nature of them, we'd also like as many eyeballs reviewing the > > code as well. > >=20 > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > > the RPI), when a parent forks a child, and the child gracefully exits, > > the parent segfaults with the pc register pointing to 0xc0000000. That > > address is always the same, no matter the application. If anyone knows > > the ARM architecture well, and how FreeBSD ties into it, I'd like a > > little guidance. > >=20 > > I also have a sparc64 box, but I'm having trouble getting a vanilla > > 11-current system to be stable on it. I ought to file a few PRs. > >=20 > > You can find links to the patches below. > >=20 > > Patch for 11-current: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current= -aslr-segvguard-SNAPSHOT.diff > >=20 > > Patch for 10-stable: > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-= 10-aslr-segvguard-SNAPSHOT.diff > >=20 >=20 > Shawn >=20 > I appreciate you working on this. We must have this in FreeBSD. >=20 > I looked at the patch and I read, but not run it. Comments below. >=20 > My personal opinion is that kern_pax.c should be compiled in by default. = If > it adds a lot of size, it'd be better to provide empty stub calls instead= of > #ifdef'ing everything. But security is very important especially in > embeddded systems, so you can imagine you're writing the code that everyb= ody > wants and must have enabled for decent level of security. >=20 > All modern systems run with ASLR turned on. >=20 > I skipped user-space stuff. I don't think it's necessary in this commit a= nd > should be separated. >=20 > There's a lot of lines of code for status showing. Not sure if we care th= at > much: ASLR is either on or off. Not sure about more granularity. More bel= ow. We provide the level of granularity because there are a lot of applications that might exhibit weird behaviors or even crash if we randomize too many bits. We provide sane defaults, but allow each user to choose the level of security versus the level of stability they desire. >=20 > Lots of files: >=20 > You conditionally make .sv_pax_aslr_init method point to something else. = I'd > assume PAX function _pax_aslr_init32() always gets called and based on > whether ASLR is on or not, it does something or not. This will simplify t= he > code a lot, and the difference probably won't be measurable. >=20 > You have: >=20 > int a; > int b; >=20 > instead of: >=20 > int a, b; >=20 > And you miss spaces around "=3D" sometimes. Cleaning up the code and make style changes are a high priority on my list. Once I get a few more pieces of code locked down, I'm going to go over every line with a comb to make sure I'm adhering to the FreeBSD coding style. des@ has made a lot of suggestions in that regard and has even provided me with a sample vimrc. Prior to talking with des@, I was re-using the same vimrc that I use for ClamAV (which, admittedly, has a much different coding style than FreeBSD). >=20 > kern_jail.c: >=20 > something looks wrong here. Sounds like you need "pr->pax". But I don't > understand why you need to have these pr_* values here. It seems > unnecessary. I've made it possible to have per-jail ASLR settings. If you have an application that misbehaves, you can jail it with ASLR turned off just for that jail. My BSDCan presentation talks about this. The recording isn't up, yet, though. >=20 > kern_pax.c: >=20 > I can't quickly tell what locking is using. Some ASSERTS() in pax_ functi= on > would help. >=20 > pax_aslr_active(): >=20 > I don't see why you need to pass "td" and "proc" (I looked at usage: you > pass proc only once). I think you could always pass proc to it, with > td->td_proc passed typically. > kern_pax_*: >=20 > There's so many SYSCTLs I think people will have problem configuring it. > Pick reasonable value for all values and let users change them via > SYSCTL_INT (static sysctls) only for debugging. There are quite a few SYSCTLs, I agree. I'll talk with Oliver Pinter, one of the developers that is working with me on this ASLR implementation, to see if we can simplify this. >=20 > I can imagine we won't want ASLR only temporarily, for ports which break = and > must be fixed. So we probably just need per-process ASLR on/off switch an= d a > wrapper which could be used like: >=20 > aslr off program .... So we have right now an addition to mac_bsdextended(4)/ugidfw(8) that does this exact thing. We also plan on adding FS extended attribute support soon, too. Also, per-jail ASLR settings. >=20 > The debug stuff I'd remove too. We could have additional CTR stubs used > there, if necessary. Oliver just released a new patchset today with new debugging functionality. I'd love to hear your commments on it. >=20 > segvguard part I didn't understand. Why do you keep a list of programs th= at > failed? There was no ASSERTs, thus it was hard to understand the locking > too. We've semi-paused development of segvguard for the moment to focus on ASLR. Though the features are related and segvguard is recommended for a proper ASLR implementation, it is not required. Danilo Egea Gondolfo is the principal engineer behind our segvguard implementation. We're still working out the kinks and the underlying design and architecture of this feature. >=20 > I'm trying to understand if randomization is done correctly. Do you think > you could post the results? >=20 > Program: >=20 > http://pastebin.com/XTRHLhMg My results on an amd64 VM are pasted here: http://ix.io/cD5 We're in talks with des@, kib@, and Alan Cox regarding how our implementation could affect the VM system, with special consideration to superpages. Thanks for taking the time to read through the code and offer insight. One of the things we need to do is write documentation regarding our implementation. Both Oliver and I have wiki accounts and we've created the start of the documentation there. I think if we had better documented our implementation, there would've been less confusion on the part of those reading/analysing our code. wiki page: https://wiki.freebsd.org/Hardening Thanks, Shawn --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTf+lMAAoJEGqEZY9SRW7uq0gP/0clziBh6ejNHvFKkfejVAMz QGdqWilb3ptuOOLO3ujK0LVr1OJDdaIHxPQVQj2/fZ4yvDGjX6WK2/wUyjUsWbsr AzF2oGibPTLLBVkz7PEbJ9owrqEXU4e8AwVD7MWTTOI1vIU+Cw1i5NKyxhMiFMng dcF1/9Ym2TzZfX7WBquqA+7eb3AeHDc0JlpAE6P9F1tvPgKpukHYyDn7NBBXxXZS MOXQsws6Y7XmiJIjqTKV39sENcepPA44wEDBWgGWbjR9D2Y8ukxdOC3Fn9xMfFfE 4DbqvNB4prkK8xjtwuF1J14aqqQxWcKBP1gDOXCzcVXjZZXfmF0RZDPhDMhy7eKN kJbvfJYV0IyMqCw8+zvnFYATco4a1Pmux+jF3XWhQNcykrl8a7Iy4NLPrw2tJKa8 QAA9H/UE/Rg8QCp2vdo5dsyujo6hkh1Onq/vOHzTZHHrt6fo8ynTLkdefALttbt+ FZ8AF3arKB1ne9Amu2IqmEz38glpZCra5y9+QNf/0IHIlNWiym4q8ysTsPMGGaMP 1sXK3oQ2M+BP+2gEnAzLOAdJCzGMpR/Km7sm56/1olfr1aauG7cMdrvUdqRXpRG7 b0XMOosWJbGBS6kyibpbZjVrsKNul7LEA5FK1xLTzPMNSkE+Cu35kLUQKhJckQEd H3yLsGXKY1xhUcZG/PCx =bR7+ -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- From owner-freebsd-security@FreeBSD.ORG Fri May 23 19:59:37 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 760F08FF; Fri, 23 May 2014 19:59:37 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A676020C6; Fri, 23 May 2014 19:59:36 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s4NJrTQD002137; Fri, 23 May 2014 19:53:29 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s4NJrT0j002136; Fri, 23 May 2014 19:53:29 GMT (envelope-from wkoszek) Date: Fri, 23 May 2014 19:53:29 +0000 From: "Wojciech A. Koszek" To: Shawn Webb Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable Message-ID: <20140523195329.GC91702@FreeBSD.org> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Fri, 23 May 2014 19:53:34 +0000 (UTC) X-Mailman-Approved-At: Sat, 24 May 2014 18:38:35 +0000 Cc: , freebsd-security@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 19:59:37 -0000 On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > Hey All, > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > Address Space Layout Randomization, or ASLR for short, is an exploit > mitigation technology. It helps secure applications against low-level > exploits. A popular secure implementation is known as PaX ASLR, which is > a third-party patch for Linux. Our implementation is based off of PaX's. > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > features and robust stability to our ASLR patches. We've done extensive > testing on amd64. We'd like to get as many people testing these patches. > Given the nature of them, we'd also like as many eyeballs reviewing the > code as well. > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > the RPI), when a parent forks a child, and the child gracefully exits, > the parent segfaults with the pc register pointing to 0xc0000000. That > address is always the same, no matter the application. If anyone knows > the ARM architecture well, and how FreeBSD ties into it, I'd like a > little guidance. > > I also have a sparc64 box, but I'm having trouble getting a vanilla > 11-current system to be stable on it. I ought to file a few PRs. > > You can find links to the patches below. > > Patch for 11-current: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > Patch for 10-stable: > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > Shawn I appreciate you working on this. We must have this in FreeBSD. I looked at the patch and I read, but not run it. Comments below. My personal opinion is that kern_pax.c should be compiled in by default. If it adds a lot of size, it'd be better to provide empty stub calls instead of #ifdef'ing everything. But security is very important especially in embeddded systems, so you can imagine you're writing the code that everybody wants and must have enabled for decent level of security. All modern systems run with ASLR turned on. I skipped user-space stuff. I don't think it's necessary in this commit and should be separated. There's a lot of lines of code for status showing. Not sure if we care that much: ASLR is either on or off. Not sure about more granularity. More below. Lots of files: You conditionally make .sv_pax_aslr_init method point to something else. I'd assume PAX function _pax_aslr_init32() always gets called and based on whether ASLR is on or not, it does something or not. This will simplify the code a lot, and the difference probably won't be measurable. You have: int a; int b; instead of: int a, b; And you miss spaces around "=" sometimes. kern_jail.c: something looks wrong here. Sounds like you need "pr->pax". But I don't understand why you need to have these pr_* values here. It seems unnecessary. kern_pax.c: I can't quickly tell what locking is using. Some ASSERTS() in pax_ function would help. pax_aslr_active(): I don't see why you need to pass "td" and "proc" (I looked at usage: you pass proc only once). I think you could always pass proc to it, with td->td_proc passed typically. kern_pax_*: There's so many SYSCTLs I think people will have problem configuring it. Pick reasonable value for all values and let users change them via SYSCTL_INT (static sysctls) only for debugging. I can imagine we won't want ASLR only temporarily, for ports which break and must be fixed. So we probably just need per-process ASLR on/off switch and a wrapper which could be used like: aslr off program .... The debug stuff I'd remove too. We could have additional CTR stubs used there, if necessary. segvguard part I didn't understand. Why do you keep a list of programs that failed? There was no ASSERTs, thus it was hard to understand the locking too. I'm trying to understand if randomization is done correctly. Do you think you could post the results? Program: http://pastebin.com/XTRHLhMg Results: cat > aslr.c gcc aslr.c -o aslr echo 1 2 3 4 5 | xargs -I % -n 1 echo "./aslr > aslr.%" | sh paste aslr.[12345] | column -t Linux with ASLR: http://pastebin.com/UuwW1JMN MacOSX: http://pastebin.com/kuQnYS4e Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-security@FreeBSD.ORG Sat May 24 20:50:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 908F46E6; Sat, 24 May 2014 20:50:50 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 343732CC6; Sat, 24 May 2014 20:50:50 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id i4so6963395oah.35 for ; Sat, 24 May 2014 13:50:49 -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=tdwWCTgp24lKNI8CkBqddjA1MZBrKOiPo85jVfOBH6Q=; b=acSKj2PAV68XLx2Dalk+sl4RDAP1Kn1DA+tagziwLqu9/sK5xxFKBG8oUX5TiTWLd5 8pGeoy3B2T/7SWyhcXEHXMeR32ZoBYEnEV1nLlSYBoCr3X238e27MQ06JD3Ml6DK7b4A GhVWHqTrlZES8aiJqrxHTr1ye0QN4IoRT6RGIZKn1CE83iE/z1rhdM8aQ4s+B1e0LkNE fyHcJGONWsHDZlqqwEGr5mhNp7RhFr6qv5/VyvRNFOB3Lr3d/VmjoVsqCIDba0TTwBBk /Grl3mAnK4JIX67v6mNuPFkUrguKlOb1YV21J3DPAx56iUAmy9XNbizfxYWXlX4YvGmh c2YA== MIME-Version: 1.0 X-Received: by 10.60.41.104 with SMTP id e8mr14788496oel.18.1400964649217; Sat, 24 May 2014 13:50:49 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Sat, 24 May 2014 13:50:49 -0700 (PDT) In-Reply-To: <20140524003525.GC2029@pwnie.vrt.sourcefire.com> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <20140523195329.GC91702@FreeBSD.org> <20140524003525.GC2029@pwnie.vrt.sourcefire.com> Date: Sat, 24 May 2014 22:50:49 +0200 Message-ID: Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Oliver Pinter To: Shawn Webb Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, "Wojciech A. Koszek" , freebsd-stable@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 20:50:50 -0000 On 5/24/14, Shawn Webb wrote: > On May 23, 2014 07:53 PM +0000, Wojciech A. Koszek wrote: >> On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: >> > Hey All, >> > >> > [NOTE: crossposting between freebsd-current@, freebsd-security@, and >> > freebsd-stable@. Please forgive me if crossposting is frowned upon.] >> > >> > Address Space Layout Randomization, or ASLR for short, is an exploit >> > mitigation technology. It helps secure applications against low-level >> > exploits. A popular secure implementation is known as PaX ASLR, which >> > is >> > a third-party patch for Linux. Our implementation is based off of >> > PaX's. >> > >> > Oliver Pinter, Danilo Egea, and I have been working hard to bring more >> > features and robust stability to our ASLR patches. We've done extensive >> > testing on amd64. We'd like to get as many people testing these >> > patches. >> > Given the nature of them, we'd also like as many eyeballs reviewing the >> > code as well. >> > >> > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on >> > the RPI), when a parent forks a child, and the child gracefully exits, >> > the parent segfaults with the pc register pointing to 0xc0000000. That >> > address is always the same, no matter the application. If anyone knows >> > the ARM architecture well, and how FreeBSD ties into it, I'd like a >> > little guidance. >> > >> > I also have a sparc64 box, but I'm having trouble getting a vanilla >> > 11-current system to be stable on it. I ought to file a few PRs. >> > >> > You can find links to the patches below. >> > >> > Patch for 11-current: >> > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff >> > >> > Patch for 10-stable: >> > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff >> > >> >> Shawn >> >> I appreciate you working on this. We must have this in FreeBSD. >> >> I looked at the patch and I read, but not run it. Comments below. >> >> My personal opinion is that kern_pax.c should be compiled in by default. >> If >> it adds a lot of size, it'd be better to provide empty stub calls instead >> of >> #ifdef'ing everything. But security is very important especially in >> embeddded systems, so you can imagine you're writing the code that >> everybody >> wants and must have enabled for decent level of security. >> >> All modern systems run with ASLR turned on. >> >> I skipped user-space stuff. I don't think it's necessary in this commit >> and >> should be separated. >> >> There's a lot of lines of code for status showing. Not sure if we care >> that >> much: ASLR is either on or off. Not sure about more granularity. More >> below. > > We provide the level of granularity because there are a lot of > applications that might exhibit weird behaviors or even crash if we > randomize too many bits. We provide sane defaults, but allow each user > to choose the level of security versus the level of stability they > desire. Two idea here: a) create a tunable security.pax.expert_mode, and create sysctls at boot time depending from expert mode ( https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/aslr/sys/kern/kern_sysctl.c#L460 ) b) just add CTLFLAG_SKIP and hide the sysctl from normal user ( https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/aslr/sys/kern/kern_sysctl.c#L739 ) > >> >> Lots of files: >> >> You conditionally make .sv_pax_aslr_init method point to something else. >> I'd >> assume PAX function _pax_aslr_init32() always gets called and based on >> whether ASLR is on or not, it does something or not. This will simplify >> the >> code a lot, and the difference probably won't be measurable. >> >> You have: >> >> int a; >> int b; >> >> instead of: >> >> int a, b; >> >> And you miss spaces around "=" sometimes. > > Cleaning up the code and make style changes are a high priority on my > list. Once I get a few more pieces of code locked down, I'm going to go > over every line with a comb to make sure I'm adhering to the FreeBSD > coding style. des@ has made a lot of suggestions in that regard and has > even provided me with a sample vimrc. Prior to talking with des@, I was > re-using the same vimrc that I use for ClamAV (which, admittedly, has a > much different coding style than FreeBSD). > >> >> kern_jail.c: >> >> something looks wrong here. Sounds like you need "pr->pax". But I don't >> understand why you need to have these pr_* values here. It seems >> unnecessary. > > I've made it possible to have per-jail ASLR settings. If you have an > application that misbehaves, you can jail it with ASLR turned off just > for that jail. My BSDCan presentation talks about this. The recording > isn't up, yet, though. > >> >> kern_pax.c: >> >> I can't quickly tell what locking is using. Some ASSERTS() in pax_ >> function >> would help. >> >> pax_aslr_active(): >> >> I don't see why you need to pass "td" and "proc" (I looked at usage: you >> pass proc only once). I think you could always pass proc to it, with >> td->td_proc passed typically. >> kern_pax_*: >> >> There's so many SYSCTLs I think people will have problem configuring it. >> Pick reasonable value for all values and let users change them via >> SYSCTL_INT (static sysctls) only for debugging. > > There are quite a few SYSCTLs, I agree. I'll talk with Oliver Pinter, > one of the developers that is working with me on this ASLR > implementation, to see if we can simplify this. > >> >> I can imagine we won't want ASLR only temporarily, for ports which break >> and >> must be fixed. So we probably just need per-process ASLR on/off switch and >> a >> wrapper which could be used like: >> >> aslr off program .... > > So we have right now an addition to mac_bsdextended(4)/ugidfw(8) that > does this exact thing. We also plan on adding FS extended attribute > support soon, too. Also, per-jail ASLR settings. > >> >> The debug stuff I'd remove too. We could have additional CTR stubs used >> there, if necessary. > > Oliver just released a new patchset today with new debugging > functionality. I'd love to hear your commments on it. > >> >> segvguard part I didn't understand. Why do you keep a list of programs >> that >> failed? There was no ASSERTs, thus it was hard to understand the locking >> too. > > We've semi-paused development of segvguard for the moment to focus on > ASLR. Though the features are related and segvguard is recommended for a > proper ASLR implementation, it is not required. Danilo Egea Gondolfo is > the principal engineer behind our segvguard implementation. We're still > working out the kinks and the underlying design and architecture of this > feature. > >> >> I'm trying to understand if randomization is done correctly. Do you think >> you could post the results? >> >> Program: >> >> http://pastebin.com/XTRHLhMg > > My results on an amd64 VM are pasted here: http://ix.io/cD5 > > We're in talks with des@, kib@, and Alan Cox regarding how our > implementation could affect the VM system, with special consideration to > superpages. > > Thanks for taking the time to read through the code and offer insight. > One of the things we need to do is write documentation regarding our > implementation. Both Oliver and I have wiki accounts and we've created > the start of the documentation there. I think if we had better > documented our implementation, there would've been less confusion on the > part of those reading/analysing our code. > > wiki page: https://wiki.freebsd.org/Hardening > > Thanks, > > Shawn > From owner-freebsd-security@FreeBSD.ORG Sun May 25 16:33:02 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8ACD80B; Sun, 25 May 2014 16:33:02 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6CCB32D38; Sun, 25 May 2014 16:33:01 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 46CFDA5FF; Sun, 25 May 2014 16:33:00 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 779C230F49; Sun, 25 May 2014 18:33:00 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Oliver Pinter Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <20140523195329.GC91702@FreeBSD.org> <20140524003525.GC2029@pwnie.vrt.sourcefire.com> Date: Sun, 25 May 2014 18:33:00 +0200 In-Reply-To: (Oliver Pinter's message of "Sat, 24 May 2014 22:50:49 +0200") Message-ID: <86egzh6coz.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, freebsd-current@freebsd.org, "Wojciech A. Koszek" , freebsd-stable@freebsd.org, Shawn Webb X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 16:33:02 -0000 Oliver Pinter writes: > Two idea here: > a) create a tunable security.pax.expert_mode, and create sysctls at > boot time depending from expert mode > b) just add CTLFLAG_SKIP and hide the sysctl from normal user The cost of an unused sysctl is about a hundred bytes of kernel memory. What is the cost of the code required to turn it on and off, keeping in mind that most of the contents of the struct sysctl_oid must be present anyway so you can fill in the malloc()ed node? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sun May 25 17:23:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59B61316; Sun, 25 May 2014 17:23:55 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6B220E5; Sun, 25 May 2014 17:23:54 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 52CE2A682; Sun, 25 May 2014 17:23:53 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 65D2830FF4; Sun, 25 May 2014 19:23:53 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Oliver Pinter Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> Date: Sun, 25 May 2014 19:23:53 +0200 In-Reply-To: (Oliver Pinter's message of "Sat, 24 May 2014 01:24:30 +0200") Message-ID: <86a9a56ac6.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, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Shawn Webb X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 17:23:55 -0000 Oliver Pinter writes: > PAX LOG: implement new logging subsystem > PAX LOG: fix pax_ulog_segvguard > PAX LOG: added sysctl's and tunables > PAX ASLR: use PAX LOG > PAX LOG: fix pax_ulog_##name() > PAX LOG: fix prison init > PAX LOG: fixed log and ulog sysctl What exactly is the purpose of PAX LOG? Have you considered using ktrace instead? > PAX: blacklist clang and related binaries from PIE support Why? Performance, or do they actually break? > PAX ASLR: Blacklist the applications that don't support being built= as a position-independent executable "don't support" as in you have tested them and confirmed that they break in some way? Could you post your test methodology so people can replicate the failures and look into fixing them? > PAX ASLR: Use a full kernel config for LATT-ASLR What is the difference between LATT-ASLR and OP-ASLR, and why not just "include GENERIC"? You know about "nooptions", right? > Revert "PAX: blacklist clang and related binaries from PIE support" > Revert "Revert "PAX: blacklist clang and related binaries from PIE = support"" Hmm... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sun May 25 17:42:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9E74A5A; Sun, 25 May 2014 17:42:17 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E80A225A; Sun, 25 May 2014 17:42:17 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id j17so7514342oag.41 for ; Sun, 25 May 2014 10:42:16 -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:content-transfer-encoding; bh=eMJaJwzCcNgG8Swi4d14ow+Z7ffnhy6lksU+kThcGsM=; b=YwRjH2IhXG6Gnnr8V0Wk59yNF++Wgx5CnzEEWyqWTOHsdSigiNg5khpQ86Kny9hoJI mwz0/EVkX1/r5KC/f+otN+Brh3k6mgwweeN/7gIqAvzOYOTVcfkUuyBY7aMRfdFx40ZT 7SLHG4Z4UldymB5o+zFjUK/f3JT4CH8ZrdFdAwvhz0Z3likC5bEAWDG0lGPqrL2GvSWH rbxc6VLY25svY3hkNT+U2BsG57O5bWIpdr7hSIp32xGzYMNOz2lig89vGZ3cQHP8wYD+ KlLu1r4af1crM1t2fIoUa8G4UKTLYgbV0TU3yrQzNmfidPReo8E8APVboea8vGHmQmBP ssrg== MIME-Version: 1.0 X-Received: by 10.182.227.135 with SMTP id sa7mr19265739obc.3.1401039736765; Sun, 25 May 2014 10:42:16 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Sun, 25 May 2014 10:42:16 -0700 (PDT) In-Reply-To: <86a9a56ac6.fsf@nine.des.no> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <86a9a56ac6.fsf@nine.des.no> Date: Sun, 25 May 2014 19:42:16 +0200 Message-ID: Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Oliver Pinter To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, dim@freebsd.org, Shawn Webb X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 17:42:18 -0000 On 5/25/14, Dag-Erling Sm=F8rgrav wrote: > Oliver Pinter writes: >> PAX LOG: implement new logging subsystem >> PAX LOG: fix pax_ulog_segvguard >> PAX LOG: added sysctl's and tunables >> PAX ASLR: use PAX LOG >> PAX LOG: fix pax_ulog_##name() >> PAX LOG: fix prison init >> PAX LOG: fixed log and ulog sysctl > > What exactly is the purpose of PAX LOG? Have you considered using > ktrace instead? pax_log will be in future a generic pax related logging framework, with ratelimiting and other features. It will log user, IP, binary name, path, checksum, and others. > >> PAX: blacklist clang and related binaries from PIE support > > Why? Performance, or do they actually break? No. If you definded WITH_CLANG_EXTRAS=3D in src.conf, the breaked the build= . (added dim@ to CC) --- usr.bin.all__D --- /usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/.= ./../../lib/clang/libllvmirreader/libllvmirreader.a: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocatio= n) *** [bugpoint] Error code 1 bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint 1 error bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint *** [all_subdir_bugpoint] Error code 2 bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/cla= ng --- usr.sbin.all__D --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi/iasl *** [all] Error code 2 bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/ac= pi 1 error bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/ac= pi *** [all_subdir_acpi] Error code 2 bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin 1 error bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin *** [usr.sbin.all__D] Error code 2 bmake[2]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git --- usr.bin.all__D --- --- all_subdir_tblgen --- A failure has been detected in another branch of the parallel make bmake[5]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/tblgen *** [all_subdir_tblgen] Error code 2 bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/cla= ng 2 errors bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/cla= ng *** [all_subdir_clang] Error code 2 bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin > >> PAX ASLR: Blacklist the applications that don't support being buil= t >> as a position-independent executable > > "don't support" as in you have tested them and confirmed that they break > in some way? Could you post your test methodology so people can > replicate the failures and look into fixing them? > >> PAX ASLR: Use a full kernel config for LATT-ASLR > > What is the difference between LATT-ASLR and OP-ASLR, and why not just > "include GENERIC"? You know about "nooptions", right? In upstreamed patch will be removed this kernel configs. These are Shawn's and my kernel config. > >> Revert "PAX: blacklist clang and related binaries from PIE support= " >> Revert "Revert "PAX: blacklist clang and related binaries from PIE >> support"" > > Hmm... See above. > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > From owner-freebsd-security@FreeBSD.ORG Sun May 25 20:21:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38869AC2; Sun, 25 May 2014 20:21:34 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EBB0C2E59; Sun, 25 May 2014 20:21:33 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id B6E3FA8C9; Sun, 25 May 2014 20:21:32 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id E045E3102B; Sun, 25 May 2014 22:21:13 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Oliver Pinter Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <86a9a56ac6.fsf@nine.des.no> Date: Sun, 25 May 2014 22:21:13 +0200 In-Reply-To: (Oliver Pinter's message of "Sun, 25 May 2014 19:42:16 +0200") Message-ID: <86wqd94nk6.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, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, dim@freebsd.org, Shawn Webb X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 20:21:34 -0000 Oliver Pinter writes: > pax_log will be in future a generic pax related logging framework, > with ratelimiting and other features. It will log user, IP, binary > name, path, checksum, and others. What are you using this for? Are you sure you can't use ktrace? It's a lot more flexible and powerful than you probably realize. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sun May 25 20:31:37 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96AB6ED6; Sun, 25 May 2014 20:31:37 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39F192F48; Sun, 25 May 2014 20:31:37 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id wo20so7284079obc.34 for ; Sun, 25 May 2014 13:31:36 -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:content-transfer-encoding; bh=hoFCHkhL4jYMaA2Lu2sXkzUYl+zTPgWvbGsSlYAgo5Q=; b=drE3kW6r1rJRHobtK4MFLThUAfu6/ln/iW/ojTJ2mndLlfoE9fPgkBXNVfHn1/7atA dSlxlhULwHKT7mgZHVFS1m84wRAbczeOleqeQ8Fm+9kmatAFNhbmBwuJd9UJmDk8Ju7z FB2p0ajSxR7m0pjoo2oqoe80q6xriUaQGW/hA16pDrirRxw4jSF4YRH7ZN8/ek5MupL6 RQwubtsR3OJCWyZsa+OhMFb1WSS344tqwbG6BygvX/umNNvN6fpjd4wHOYJZvuzHFQvL 3R0FZvnzfWU2gR/5V0CVwePu4eYeB4oIWmn5KQ3X9Ffpc+I5osol5IgrUMORBVAMyilL WcZg== MIME-Version: 1.0 X-Received: by 10.60.70.200 with SMTP id o8mr15219949oeu.55.1401049896076; Sun, 25 May 2014 13:31:36 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Sun, 25 May 2014 13:31:35 -0700 (PDT) In-Reply-To: <86wqd94nk6.fsf@nine.des.no> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <86a9a56ac6.fsf@nine.des.no> <86wqd94nk6.fsf@nine.des.no> Date: Sun, 25 May 2014 22:31:35 +0200 Message-ID: Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Oliver Pinter To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, dim@freebsd.org, Shawn Webb X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 20:31:37 -0000 On 5/25/14, Dag-Erling Sm=F8rgrav wrote: > Oliver Pinter writes: >> pax_log will be in future a generic pax related logging framework, >> with ratelimiting and other features. It will log user, IP, binary >> name, path, checksum, and others. > > What are you using this for? Are you sure you can't use ktrace? It's a > lot more flexible and powerful than you probably realize. Logging to system log, The feature will similar to this in grsecurity: http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configu= ration_Options#Kernel_Auditing > > DES > -- > Dag-Erling Sm=F8rgrav - des@des.no > From owner-freebsd-security@FreeBSD.ORG Sun May 25 09:15:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26F14253 for ; Sun, 25 May 2014 09:15:51 +0000 (UTC) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.103]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6382DCB for ; Sun, 25 May 2014 09:15:50 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:in-reply-to:user-agent:sender; b=mnsEqs/JqYz2BvmwC2nzqoakQbI4HPZjS/T7mt/5VtsMoDXzVk4PnXA3SKee01ENphi3vu/hZ84z T/laU7Hlr7936ybiA5WQyZGuIFlcfdEFGSuPN2T0Em9nxGhN4Ah0 Received: from sol (21-157-103-86.dynamic.dsl.tng.de [86.103.157.21]) by mx.zohomail.com with SMTPS id 1401008298593446.0385811052279; Sun, 25 May 2014 01:58:18 -0700 (PDT) Date: Sun, 25 May 2014 10:58:09 +0200 From: kaltheat@googlemail.com To: Todor Todorov Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140525085809.GA1531@sol> References: <534B11F0.9040400@paladin.bulgarpress.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534B11F0.9040400@paladin.bulgarpress.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: kaltheat@zoho.com X-ZohoMailClient: External X-Zoho-Virus-Status: 2 X-Mailman-Approved-At: Sun, 25 May 2014 22:03:41 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 09:15:51 -0000 On Mon, Apr 14, 2014 at 01:38:40AM +0300, Todor Todorov wrote: > Hi everyone, > I came across this : > > https://groups.google.com/forum/#!topic/mailing.openbsd.tech/xALfxxR3oKo > > " You are welcome. Stuart Henderson wrote the draft, but he forgot that > part, and Damien Miller and I realized it was needed. We sensed there > might be some ambiguity... we'll take care the next time an > OpenOffice problem also. > > ... as long as you aren't using FreeBSD or a derivative (hint: Jupiper), > you are fine. That's the only place I know of an OpenSSH hole. > > Oh now I sense some angst. Please ask Kirk McKusick, he knows the > story about why this is not being disclosed to FreeBSD. Sometimes I > feel a bit sorry for them (and for him), but then the next minute I > don't feel sorry because there's damn good reasons they won't be > told about what I found. > > Does that answer help? Hope so." > > Any guidance here? So, just to sum it up and get it right for me: De Raadt might have found a security hole in OpenSSH for FreeBSD and derivates, but he doesn't give any details on that. He himself does not explain his behaviour, but advises to ask McKusick about it. Nobody has asked McKusick for details (though it would be really strange if he is able to look into someone elses head), but there are some people thinking that it might be a reaction on a communication problem dated back to 2005, were a security hole was found in FreeBSD, but other *BSDs weren't informed immediately about details. Have I missed something or is this the essence? Regards, kaltheat From owner-freebsd-security@FreeBSD.ORG Sun May 25 18:07:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94FE757E; Sun, 25 May 2014 18:07:00 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3C3240F; Sun, 25 May 2014 18:07:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::7059:63a3:928c:92b9] (unknown [IPv6:2001:7b8:3a7:0:7059:63a3:928c:92b9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EAC3C5C43; Sun, 25 May 2014 20:06:45 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_BA330A0E-BAD8-4F4B-A868-F6AA7CD1287E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: Dimitry Andric In-Reply-To: Date: Sun, 25 May 2014 20:06:40 +0200 Message-Id: <49702223-7624-4D44-9371-2F8C5E2D4D38@FreeBSD.org> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <86a9a56ac6.fsf@nine.des.no> To: Oliver Pinter X-Mailer: Apple Mail (2.1878.2) X-Mailman-Approved-At: Sun, 25 May 2014 23:52:30 +0000 Cc: freebsd-security@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Shawn Webb X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 18:07:00 -0000 --Apple-Mail=_BA330A0E-BAD8-4F4B-A868-F6AA7CD1287E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 25 May 2014, at 19:42, Oliver Pinter wrote: > On 5/25/14, Dag-Erling Sm=F8rgrav wrote: >> Oliver Pinter writes: ... >>> PAX: blacklist clang and related binaries from PIE support >>=20 >> Why? Performance, or do they actually break? >=20 > No. If you definded WITH_CLANG_EXTRAS=3D in src.conf, the breaked the = build. > (added dim@ to CC) >=20 > --- usr.bin.all__D --- > = /usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/= ../../../lib/clang/libllvmirreader/libllvmirreader.a: > could not read symbols: Bad value > c++: error: linker command failed with exit code 1 (use -v to see = invocation) > *** [bugpoint] Error code 1 I assume you only get this with your ASLR patches applied? Maybe this = is because the clang binary itself gets built statically (and so will = definitely not be PIE), but the rest of the 'extras', such as bugpoint, = are regular dynamic executables. And note that none of the libraries = built under lib/libclang are built with -fPIC, at the moment. So that = might cause trouble with your PIE patches. In any case, the interesting thing is what the actual linker error was. = Do you have more of the preceding build log, including the rest of the = settings that were used to build world? And also, what does "file = /usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/= ../../../lib/clang/libllvmirreader/libllvmirreader.a" say? -Dimitry --Apple-Mail=_BA330A0E-BAD8-4F4B-A868-F6AA7CD1287E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlOCMTMACgkQsF6jCi4glqNQmQCgxsg9UC9JkSn8kNHnariVhESs xa4An2oaJXR9EThhr5gpLZ9LjH907/rQ =kgCZ -----END PGP SIGNATURE----- --Apple-Mail=_BA330A0E-BAD8-4F4B-A868-F6AA7CD1287E-- From owner-freebsd-security@FreeBSD.ORG Sun May 25 21:18:32 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A1FCBED; Sun, 25 May 2014 21:18:32 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50942227E; Sun, 25 May 2014 21:18:31 +0000 (UTC) Received: from [192.168.0.96] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s4PLIOiD085171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 May 2014 21:18:27 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable From: David Chisnall In-Reply-To: Date: Sun, 25 May 2014 22:18:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38F830B6-4B52-4372-9BC6-565B2387720F@FreeBSD.org> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <86a9a56ac6.fsf@nine.des.no> <86wqd94nk6.fsf@nine.des.no> To: Oliver Pinter X-Mailer: Apple Mail (2.1874) X-Mailman-Approved-At: Sun, 25 May 2014 23:52:44 +0000 Cc: freebsd-stable@freebsd.org, dim@freebsd.org, Shawn Webb , freebsd-security@freebsd.org, freebsd-current@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 21:18:32 -0000 On 25 May 2014, at 21:31, Oliver Pinter wrote: > On 5/25/14, Dag-Erling Sm=F8rgrav wrote: >> Oliver Pinter writes: >>> pax_log will be in future a generic pax related logging framework, >>> with ratelimiting and other features. It will log user, IP, binary >>> name, path, checksum, and others. >>=20 >> What are you using this for? Are you sure you can't use ktrace? = It's a >> lot more flexible and powerful than you probably realize. >=20 > Logging to system log, The feature will similar to this in grsecurity: > = http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Config= uration_Options#Kernel_Auditing It sounds like you actually want to be writing audit events then. See = audit(4). David From owner-freebsd-security@FreeBSD.ORG Mon May 26 01:54:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA322FCC; Mon, 26 May 2014 01:54:44 +0000 (UTC) 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)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 858642735; Mon, 26 May 2014 01:54:44 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-232-70.lns20.per1.internode.on.net [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s4Q1sTEf081233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 25 May 2014 18:54:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53829ED0.7010105@freebsd.org> Date: Mon, 26 May 2014 09:54:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Chisnall , Oliver Pinter Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <86a9a56ac6.fsf@nine.des.no> <86wqd94nk6.fsf@nine.des.no> <38F830B6-4B52-4372-9BC6-565B2387720F@FreeBSD.org> In-Reply-To: <38F830B6-4B52-4372-9BC6-565B2387720F@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org, dim@freebsd.org, Shawn Webb , freebsd-security@freebsd.org, freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 01:54:44 -0000 On 5/26/14, 5:18 AM, David Chisnall wrote: > On 25 May 2014, at 21:31, Oliver Pinter wrote: > >> On 5/25/14, Dag-Erling Smųrgrav wrote: >>> Oliver Pinter writes: >>>> pax_log will be in future a generic pax related logging framework, >>>> with ratelimiting and other features. It will log user, IP, binary >>>> name, path, checksum, and others. >>> What are you using this for? Are you sure you can't use ktrace? It's a >>> lot more flexible and powerful than you probably realize. >> Logging to system log, The feature will similar to this in grsecurity: >> http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing > It sounds like you actually want to be writing audit events then. See audit(4). yeah I think the point is not "use ktrace" but "use and/or possibly extend one of the several already existing methods". we don't need *another* logging facility. > > David > > _______________________________________________ > 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 Mon May 26 02:40:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56C63A31 for ; Mon, 26 May 2014 02:40:12 +0000 (UTC) Received: from pandora.au.calorieking.net (114.179.70.115.static.exetel.com.au [115.70.179.114]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F219E2A90 for ; Mon, 26 May 2014 02:40:11 +0000 (UTC) Received: from pandora.internal (localhost [127.0.0.1]) by pandora.au.calorieking.net (Postfix) with ESMTP id D453533C82 for ; Mon, 26 May 2014 10:40:09 +0800 (WST) X-Virus-Scanned: amavisd-new at calorieking.com Received: from pandora.au.calorieking.net ([127.0.0.1]) by pandora.internal (pandora.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZoAqYP1pIC3 for ; Mon, 26 May 2014 10:40:04 +0800 (WST) Received: from egeria.internal (egeria.internal [192.168.2.111]) by pandora.au.calorieking.net (Postfix) with ESMTPSA id AA8D433C6D for ; Mon, 26 May 2014 10:40:04 +0800 (WST) Message-ID: <5382A982.6090304@calorieking.com> Date: Mon, 26 May 2014 10:40:02 +0800 From: Gregory Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: freebsd-update.conf IgnorePaths linker.hints not working 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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 02:40:12 -0000 Hi everyone, I've got freebsd-update cron running every night, and each time get the following (regardless of whether I then run freebsd-update install): ---- The following files will be updated as part of updating to 8.4-RELEASE-p10: /boot/kernel/linker.hints ---- I've found a few discussion threads suggesting changes to freebsd-update.conf being advisable, so I've done that, to no avail. Also following these instructions for rc.conf: https://forums.freebsd.org/viewtopic.php?p=208260#p208260 No luck. I still get the message at every run. My freebsd-update.conf has no other changes: http://pastebin.com/KHdVCyBY Can anyone suggest how should I resolve this? TIA, Greg. PS: Sorry if this is considered off-topic for -security. I tried -questions, and have met silence for a week. I'm not sure where else to try. From owner-freebsd-security@FreeBSD.ORG Mon May 26 02:47:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7331BBF; Mon, 26 May 2014 02:47:47 +0000 (UTC) Date: Sun, 25 May 2014 22:47:43 -0400 From: Glen Barber To: Gregory Orange Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working Message-ID: <20140526024743.GC90742@hub.FreeBSD.org> References: <5382A982.6090304@calorieking.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline In-Reply-To: <5382A982.6090304@calorieking.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-security@freebsd.org, Colin Percival X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 02:47:48 -0000 --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 26, 2014 at 10:40:02AM +0800, Gregory Orange wrote: > Hi everyone, >=20 > I've got freebsd-update cron running every night, and each time get the > following (regardless of whether I then run freebsd-update install): > ---- > The following files will be updated as part of updating to 8.4-RELEASE-p1= 0: > /boot/kernel/linker.hints > ---- > I've found a few discussion threads suggesting changes to > freebsd-update.conf being advisable, so I've done that, to no avail. Also > following these instructions for rc.conf: >=20 > https://forums.freebsd.org/viewtopic.php?p=3D208260#p208260 >=20 > No luck. I still get the message at every run. My freebsd-update.conf has= no > other changes: >=20 > http://pastebin.com/KHdVCyBY >=20 > Can anyone suggest how should I resolve this? >=20 > TIA, > Greg. >=20 > PS: Sorry if this is considered off-topic for -security. I tried -questio= ns, > and have met silence for a week. I'm not sure where else to try. Seems related to PR 186273 http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/186273 Glen --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCAAGBQJTgqtPAAoJELls3eqvi17Q8mEQANTWzFqSMVgymVCrS6H+RhtW CDbh/roPU1P9C6g5vewjid1hCBxHSUFplUXmE6/67Q2w/POVvnVyK1FjIrPdBcfO 1eYfMBVxgoQtdsx09lhPWnTxkwf1dsfamQ2iCZdvV1od8sa/5EMcOjn/OQnKNH89 jgAyqFkv9g+nkLhuUZPlpO7zl1ANXfKZ5eAVb46j5yNv6PKtPAfjvOKbEv3hmLGH ZwPSWoORG9CdkRZPpLu2wm7be/kz2SVVLIZvGdVp7JyrQjF2fh4NqzHiUFu4SfGW WZ0od9RWkK2Ri0sl+fclubfKh1uF5XQY032PCPLkhNAZqMttEQjq7V5odGUy6brY Ep7up8PomTRPrXYN6E1NUdgc2uv+qbdTvA1nFPJMph00ebB1C8MiR9Oejdy1zNKQ eBIHQQb8PHsPjSHI3VdPLX7uaFWlP3rA/MiZnJrUDWw7Ind/vNjgacqKUR3xyoYT axM4Rtxe2JtZ01O6pGPK8Ad4rqIIOLgHo3SOxFWwtuAcpq6GNLcgYsHi8NaM74b8 8gGVXUGlWgDq74Qi1TIeHv4EBnyOyZG5Idva9fbg5koB5DrndsL3Uud/RNuUlWky 4FgRWheFGiwyRVfrhL6QY2ABu3afyiinHkBg57/8J22t1J5395/ytSqcw4SKK4c1 pO6Q2Pqs0b7DRbIjLB2b =Q25+ -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C-- From owner-freebsd-security@FreeBSD.ORG Mon May 26 03:24:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DBE331A; Mon, 26 May 2014 03:24:27 +0000 (UTC) Received: from pandora.au.calorieking.net (114.179.70.115.static.exetel.com.au [115.70.179.114]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 527252E59; Mon, 26 May 2014 03:24:26 +0000 (UTC) Received: from pandora.internal (localhost [127.0.0.1]) by pandora.au.calorieking.net (Postfix) with ESMTP id E8B3D33CA3; Mon, 26 May 2014 11:24:17 +0800 (WST) X-Virus-Scanned: amavisd-new at calorieking.com Received: from pandora.au.calorieking.net ([127.0.0.1]) by pandora.internal (pandora.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCRiH4HWaOp3; Mon, 26 May 2014 11:24:08 +0800 (WST) Received: from egeria.internal (egeria.internal [192.168.2.111]) by pandora.au.calorieking.net (Postfix) with ESMTPSA id 0189233C9B; Mon, 26 May 2014 11:24:08 +0800 (WST) Message-ID: <5382B3D5.8050500@calorieking.com> Date: Mon, 26 May 2014 11:24:05 +0800 From: Gregory Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Glen Barber Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working References: <5382A982.6090304@calorieking.com> <20140526024743.GC90742@hub.FreeBSD.org> In-Reply-To: <20140526024743.GC90742@hub.FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, Colin Percival X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:24:27 -0000 On 26/05/14 10:47, Glen Barber wrote: > On Mon, May 26, 2014 at 10:40:02AM +0800, Gregory Orange wrote: >> I've got freebsd-update cron running every night, and each time get the >> following (regardless of whether I then run freebsd-update install): >> ---- >> The following files will be updated as part of updating to 8.4-RELEASE-p10: >> /boot/kernel/linker.hints > > Seems related to PR 186273 > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/186273 Okay thanks, I didn't come across that in my searching. What do you suggest next? Would removing the file completely stop kernel modules from loading, or some other unwanted behaviour? Cheers, Greg. From owner-freebsd-security@FreeBSD.ORG Mon May 26 03:26:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 388F2427 for ; Mon, 26 May 2014 03:26:45 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 22B222E8C for ; Mon, 26 May 2014 03:26:44 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 53BC53AD92 for ; Sun, 25 May 2014 20:26:44 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Local Denial of Service: logger(1) Date: Sun, 25 May 2014 20:26:44 -0700 Message-ID: <2091.1401074804@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:26:45 -0000 I can't have been the first person to to have thought of this... can I? ========================================================================== #!/bin/sh while (1) dd if=/dev/random bs=15 count=1 | od -c | xargs logger end ========================================================================== Ought to fill up the /var partition in due course. And perhaps more importantly, once it does, all manner of nefarious activities, perpetrated by all manner of miscreants, might ensue, none of which would be logged in any way. From owner-freebsd-security@FreeBSD.ORG Mon May 26 03:37:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F5A85B6 for ; Mon, 26 May 2014 03:37:08 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 27E2B2F53 for ; Mon, 26 May 2014 03:37:07 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 91C8C3AD92 for ; Sun, 25 May 2014 20:37:07 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: NEVERMIND! (was: Local Denial of Service: logger(1)) In-Reply-To: <2091.1401074804@server1.tristatelogic.com> Date: Sun, 25 May 2014 20:37:07 -0700 Message-ID: <2218.1401075427@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:37:08 -0000 In message <2091.1401074804@server1.tristatelogic.com>, I wrote: >========================================================================== >#!/bin/sh > >while (1) > dd if=/dev/random bs=15 count=1 | od -c | xargs logger >end >========================================================================== DUH! I forgot that newsyslog(8) should limit the size of /var/log/messages, and that as long as you limit the size of that to a reasnable value, and as long as you have newsyslog(8) only keeping a finite & reasonable number of "rotated out" copies, then /var won't fill up. My apologies to everyone for the distraction. From owner-freebsd-security@FreeBSD.ORG Mon May 26 03:51:18 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF234744 for ; Mon, 26 May 2014 03:51:18 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D915208A for ; Mon, 26 May 2014 03:51:18 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hl10so2682820igb.3 for ; Sun, 25 May 2014 20:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HGuwFgONEohDP3CdPikypjH20NaDT8NjXpwF2Mj6CW0=; b=OJzDf8PlsRmrbk+xRZwFK+3Pv6OUEdANHYECzGuI576JcMp5z0J7fo6K+9SrZPE5IX TabuCmmYO7hsZchurRuUTD6pyikvZs2B7JmIFOEdB1cFY9UMZ8zOqefo3Z52QX2sNj/f ZIsx4aGiRSGEUSnqPyfGH898EW04k776RIfT8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HGuwFgONEohDP3CdPikypjH20NaDT8NjXpwF2Mj6CW0=; b=VAsArSUgTQ6R5rZBe1yXptZZq6qI0/KbSkEQFeMeu83z4biZP+4Ja9QOgopX3J0Z9Z xDKqByRABiLajolXklhxKdLhvQiSHh2ybBJHJKBpJjS5UyzN7f8cHkndmxNAbFf1+P9A snjP6e2lZg0DyiMuk9Ye3u3BtmS2pHy4FJgx1pn2SoG4pnmyzwt/kI78P9ZRpOVSN7oX mmufaUu11hadLuGiiCEhBv+Fis96ZVGU6frGc4JCi/cJ7eUGZbNBEPKRco1tABb1uRst phaCwZxjWy6+Q+0HYhLg8XhdkFHbA9c+txOToApxwP4TMV36c2N6cVhns0K9XJU6386x /Rvg== X-Gm-Message-State: ALoCoQmGoAOZ5KmxGlD+aJlDBR+JOgngMPh5AYJVMnOvyN/mJk/e/p+ocPauf/WJFgSJE/MMFwUa X-Received: by 10.42.78.136 with SMTP id n8mr19887454ick.28.1401076277853; Sun, 25 May 2014 20:51:17 -0700 (PDT) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id y7sm24258568igl.13.2014.05.25.20.51.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 May 2014 20:51:17 -0700 (PDT) References: <2218.1401075427@server1.tristatelogic.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2218.1401075427@server1.tristatelogic.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5BF8CCF0-33C6-4757-9988-E861765ADBAF; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <61CB0E46-3969-4A00-866E-731F44E0B29A@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: NEVERMIND! (was: Local Denial of Service: logger(1)) Date: Sun, 25 May 2014 23:51:14 -0400 To: "Ronald F. Guilmette" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-security@freebsd.org" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:51:18 -0000 --Apple-Mail-5BF8CCF0-33C6-4757-9988-E861765ADBAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That and/or you could just disallow the use of logger to that of just a spec= ial group say staff and modify the mtree(8) files to keep the changes.=20 These are just medial tasks into hardening a system for its specific needs. s= ecurity/logcheck should pick up these events pretty quickly and shoot out an= email to your admin group to alert them of the miscreant :-) --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On May 25, 2014, at 23:37, "Ronald F. Guilmette" w= rote: >=20 >=20 > In message <2091.1401074804@server1.tristatelogic.com>, I wrote: >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> #!/bin/sh >>=20 >> while (1) >> dd if=3D/dev/random bs=3D15 count=3D1 | od -c | xargs logger >> end >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > DUH! >=20 > I forgot that newsyslog(8) should limit the size of /var/log/messages, and= > that as long as you limit the size of that to a reasnable value, and as > long as you have newsyslog(8) only keeping a finite & reasonable number > of "rotated out" copies, then /var won't fill up. >=20 > My apologies to everyone for the distraction. > _______________________________________________ > 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= " --Apple-Mail-5BF8CCF0-33C6-4757-9988-E861765ADBAF Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDUyNjAzNTExNlowIwYJKoZIhvcN AQkEMRYEFK4/UFTirMv686B2b7kHANVVXsC7MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAKnvHA17dsjf1qfNQPFUD SFFR5N2HEiOroTc9yzgCuPFpKEVoeZLvedj/zGWYmAmCYJBhu/uTOH8Y3gf0IqYwQpwiEUHMpPRv IAxUvvbxJD1NUKCEzewcl7DRox+Wl+EzJRWWmD1Sg+NVK1RZ6pgLbcTSymEhX72/Q9Xge+TaI/Xl WhVnAEg9mMUJKay9vcfJk5xM4NoZZDq8CDLQk+PHhtJzyCeORLNwySiVXitgWV4KlFBE76HrIx8E wRJmBf5mIaA2zs/r1nPf+pIizSODO8fQcLa1hV3FYUZakS97RUYk8XwGQWDo7sPdbQVGch6tmnRh Hzeu1nktwaAzq1sE2wAAAAAAAA== --Apple-Mail-5BF8CCF0-33C6-4757-9988-E861765ADBAF-- From owner-freebsd-security@FreeBSD.ORG Mon May 26 14:00:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5DFD74A for ; Mon, 26 May 2014 14:00:54 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 76E6725F2 for ; Mon, 26 May 2014 14:00:54 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 46DD4A6AA; Mon, 26 May 2014 14:00:53 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2355A31122; Mon, 26 May 2014 16:00:34 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Gregory Orange Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working References: <5382A982.6090304@calorieking.com> Date: Mon, 26 May 2014 16:00:34 +0200 In-Reply-To: <5382A982.6090304@calorieking.com> (Gregory Orange's message of "Mon, 26 May 2014 10:40:02 +0800") Message-ID: <86vbssr665.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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 14:00:54 -0000 Gregory Orange writes: > I've got freebsd-update cron running every night, and each time get > the following (regardless of whether I then run freebsd-update > install): > ---- > The following files will be updated as part of updating to 8.4-RELEASE-p1= 0: > /boot/kernel/linker.hints > ---- This was supposed to be fixed by the following errata notice: http://www.freebsd.org/security/advisories/FreeBSD-EN-14:04.kldxref.asc DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon May 26 14:12:13 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 216DFB58 for ; Mon, 26 May 2014 14:12:13 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D70AE2770 for ; Mon, 26 May 2014 14:12:12 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 85D10A6DE; Mon, 26 May 2014 14:12:11 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 62DCC31126; Mon, 26 May 2014 16:11:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Ronald F. Guilmette" Subject: Re: NEVERMIND! References: <2218.1401075427@server1.tristatelogic.com> Date: Mon, 26 May 2014 16:11:52 +0200 In-Reply-To: <2218.1401075427@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Sun, 25 May 2014 20:37:07 -0700") Message-ID: <86r43gr5nb.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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 14:12:13 -0000 "Ronald F. Guilmette" writes: > I forgot that newsyslog(8) should limit the size of /var/log/messages, and > that as long as you limit the size of that to a reasnable value, and as > long as you have newsyslog(8) only keeping a finite & reasonable number > of "rotated out" copies, then /var won't fill up. It can still happen, since newsyslog only runs once per hour. If /var fills up between two newsyslog runs, there is no guarantee that the space freed up by deleting the oldest logs is sufficient to compress the newest log. The only way to really handle this issue would be to fold newsyslog into syslog. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon May 26 15:54:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7608FE0D for ; Mon, 26 May 2014 15:54:29 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C679B21C1 for ; Mon, 26 May 2014 15:54:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s4QFsD6o064382; Tue, 27 May 2014 01:54:14 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 27 May 2014 01:54:13 +1000 (EST) From: Ian Smith To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Subject: Re: NEVERMIND! In-Reply-To: <86r43gr5nb.fsf@nine.des.no> Message-ID: <20140527004708.U5669@sola.nimnet.asn.au> References: <2218.1401075427@server1.tristatelogic.com> <86r43gr5nb.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-security@freebsd.org, "Ronald F. Guilmette" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 15:54:29 -0000 On Mon, 26 May 2014 16:11:52 +0200, Dag-Erling Smųrgrav wrote: > > "Ronald F. Guilmette" writes: >> I forgot that newsyslog(8) should limit the size of /var/log/messages, and >> that as long as you limit the size of that to a reasnable value, and as >> long as you have newsyslog(8) only keeping a finite & reasonable number >> of "rotated out" copies, then /var won't fill up. > It can still happen, since newsyslog only runs once per hour. If > /var fills up between two newsyslog runs, there is no guarantee that > the space freed up by deleting the oldest logs is sufficient to > compress the newest log. The only way to really handle this issue > would be to fold newsyslog into syslog. Mitigating that - in the case of single repeating messages at least - is that syslog accumulates these and reports totals at a certain interval. At 5.5-stable (yes, I know) it was 10 minutes, just one example: May 16 19:17:05 x inetd[5768]: pop3 from 92.247.169.210 exceeded counts/min (limit 4/min) May 16 19:17:26 x last message repeated 30 times May 16 19:19:37 x last message repeated 55 times May 16 19:29:44 x last message repeated 450 times May 16 19:39:44 x last message repeated 367 times [.. every 10 minutes until ..] May 16 22:09:42 x last message repeated 349 times May 16 22:10:57 x last message repeated 54 times Of course just to blow my case, tonight I find 967 lines in 82418 bytes from two hosts apparently in Mexico doing the same gig in parallel, for less than two minutes - over a very slow ADSL line. syslog doesn't need the complication of attempts at such pattern matching. Rather than merging the two, might syslog trigger adhoc rotations by newsyslog - of a particular log, not all - after learning how to measure 'stress', perhaps by rates of delta filesize, diskspace consumption etc? Then newsyslog would only need to learn how to be so invoked? just a thought, Ian From owner-freebsd-security@FreeBSD.ORG Mon May 26 20:01:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCD5B2BB for ; Mon, 26 May 2014 20:01:56 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id B2488262C for ; Mon, 26 May 2014 20:01:56 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0FFDD3ACAE for ; Mon, 26 May 2014 13:01:56 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! In-Reply-To: <86r43gr5nb.fsf@nine.des.no> Date: Mon, 26 May 2014 13:01:56 -0700 Message-ID: <7159.1401134516@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 20:01:56 -0000 In message <86r43gr5nb.fsf@nine.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: >"Ronald F. Guilmette" writes: >> I forgot that newsyslog(8) should limit the size of /var/log/messages, >and >> that as long as you limit the size of that to a reasnable value, and as >> long as you have newsyslog(8) only keeping a finite & reasonable number >> of "rotated out" copies, then /var won't fill up. > >It can still happen, since newsyslog only runs once per hour. If /var >fills up between two newsyslog runs... Yes. Good point. So should I file a PR on this, or what? My first thought is that perhaps what's needed is per-account logging quotas, so that loging could be limited... on a per account basis... much as the usage of memory and other finite resources are. However it occurs to me that perhaps the scenario I mentioned is only one of a number of plausible scenarios that might result in total exhaustion of /var between hourly newsyslog runs. For example, I can easily envision remotely filling up your /var simply by sending you, in rapid succession, a sufficient quantity of malformed http requests, or perhaps even just an endless set of minimalist HELO/QUIT sequences to your mail server. Of course, none of these kinds of attacks will really be all that harmful to any well-attended machines that are being properly monitored by even minimally competent system administrators. But given that more and more machines these days run as "appliances" for long periods with no monitoring whatsoever, attacks which exhaust /var, or which attemp to do so, might actually be an issue worthy of attention. From owner-freebsd-security@FreeBSD.ORG Tue May 27 02:46:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93F04313 for ; Tue, 27 May 2014 02:46:16 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 7A821238E for ; Tue, 27 May 2014 02:46:15 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id CA01A3ACAE for ; Mon, 26 May 2014 19:46:14 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! In-Reply-To: <20140527004708.U5669@sola.nimnet.asn.au> Date: Mon, 26 May 2014 19:46:14 -0700 Message-ID: <9187.1401158774@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:46:16 -0000 In message <20140527004708.U5669@sola.nimnet.asn.au>, Ian Smith wrote: >... might syslog trigger adhoc rotations by >newsyslog - of a particular log, not all - after learning how to measure >'stress', perhaps by rates of delta filesize, diskspace consumption etc? (Not that anyone has any reason to care what _I_ think, but...) I must say that I like that idea. The specific thing (i.e. "measurment") that should trigger such an event/action seems altogether obvious. If syslogd is writing a file and it sees that the file in question has just exceeded its allowed maximum (according to /etc/newsyslog.conf) then it is clearly time to do something about it. >Then newsyslog would only need to learn how to be so invoked? How about "kill -HUP" ? That seems to be the pro-forma thing that pretty much everything else already uses as a way to tell any given daemon that it should wake up and smell the coffee (again). Of course, *if* one were in fact going to endow syslogd with all of the intelligence necessary to read, understand, check, and act on the various max filesize specifications contained within /etc/newsyslog.conf then that would certainly prompt the question: Why not just merge the two programs into one? (Obviously, that would eliminate the need for interprocess signaling of any kind.) From owner-freebsd-security@FreeBSD.ORG Tue May 27 08:05:26 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0340AE2 for ; Tue, 27 May 2014 08:05:26 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 35C192ABF for ; Tue, 27 May 2014 08:05:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s4R85DrT098778; Tue, 27 May 2014 18:05:16 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 27 May 2014 18:05:13 +1000 (EST) From: Ian Smith To: "Ronald F. Guilmette" Subject: Re: NEVERMIND! In-Reply-To: <9187.1401158774@server1.tristatelogic.com> Message-ID: <20140527172016.J5669@sola.nimnet.asn.au> References: <9187.1401158774@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: des@des.no, freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:05:26 -0000 On Mon, 26 May 2014 19:46:14 -0700, Ronald F. Guilmette wrote: > Ian Smith wrote: > > >... might syslog trigger adhoc rotations by > >newsyslog - of a particular log, not all - after learning how to measure > >'stress', perhaps by rates of delta filesize, diskspace consumption etc? > > (Not that anyone has any reason to care what _I_ think, but...) I must > say that I like that idea. > > The specific thing (i.e. "measurment") that should trigger such an > event/action seems altogether obvious. If syslogd is writing a file > and it sees that the file in question has just exceeded its allowed > maximum (according to /etc/newsyslog.conf) then it is clearly time to > do something about it. I was more thinking that syslogd might use its own criteria, based on preservation of functionality in the face of DoS (or pilot error) in regard to its diskspace requirements. I used delta filesize (rate of file growth) in a script against a certain DNS mini-DoS some years ago and found it effective for both reporting and blacklisting offenders. And don't forget remote logging, where syslogd has no clue re filesize. > >Then newsyslog would only need to learn how to be so invoked? > > How about "kill -HUP" ? > > That seems to be the pro-forma thing that pretty much everything > else already uses as a way to tell any given daemon that it should > wake up and smell the coffee (again). Except that newsyslog isn't a daemon; it's a userland program, usually invoked hourly by cron, which usually itself sends a HUP signal to the daemon associated with a rotated log. It already has ability to work on single file/s and to avoid signalling its caller, and in fact may need no modification at all .. but I've never played with its many options. > Of course, *if* one were in fact going to endow syslogd with all of > the intelligence necessary to read, understand, check, and act on the > various max filesize specifications contained within /etc/newsyslog.conf > then that would certainly prompt the question: Why not just merge the > two programs into one? (Obviously, that would eliminate the need for > interprocess signaling of any kind.) Which is more or less what des@ suggested, rather to my surprise. To me it doesn't smell quite right, unix-philosophically, merging two distinct processes that each perform related but really very separate functions, near doubling the size and complicating the functionality of the daemon. But I'm no more likely than you are to be able to do anything about it, so I'll leave it there. cheers, Ian From owner-freebsd-security@FreeBSD.ORG Tue May 27 08:05:44 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEC6EBC4 for ; Tue, 27 May 2014 08:05:44 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B27692AD3 for ; Tue, 27 May 2014 08:05:44 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id AE47DA4E5; Tue, 27 May 2014 08:05:42 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id E3BD331226; Tue, 27 May 2014 10:05:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Ronald F. Guilmette" Subject: Re: NEVERMIND! References: <7159.1401134516@server1.tristatelogic.com> Date: Tue, 27 May 2014 10:05:23 +0200 In-Reply-To: <7159.1401134516@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 26 May 2014 13:01:56 -0700") Message-ID: <867g57bq9o.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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:05:45 -0000 "Ronald F. Guilmette" writes: > So should I file a PR on this, or what? *shrug* I think this falls under the same heading as a fork bomb - one of thousands of ways local users can screw you over if they want to. > For example, I can easily envision remotely filling up your /var simply > by sending you, in rapid succession, a sufficient quantity of malformed > http requests, or perhaps even just an endless set of minimalist HELO/QUIT > sequences to your mail server. or an ssh brute force scan, etc. In my opinion, this belongs in a system administration textbook, not in a bug tracker. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue May 27 11:20:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B51CE5A for ; Tue, 27 May 2014 11:20:56 +0000 (UTC) Received: from pacha.mail.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 943322D61 for ; Tue, 27 May 2014 11:20:55 +0000 (UTC) Received: from catnip.dyslexicfish.net (space.mail.dyslexicfish.net [91.109.5.35]) by pacha.mail.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id s4RBKkT1096462; Tue, 27 May 2014 12:20:46 +0100 (BST) (envelope-from jamie@catnip.dyslexicfish.net) Received: (from jamie@localhost) by catnip.dyslexicfish.net (8.14.5/8.14.5/Submit) id s4RBKiHp096461; Tue, 27 May 2014 12:20:44 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201405271120.s4RBKiHp096461@catnip.dyslexicfish.net> Date: Tue, 27 May 2014 12:20:44 +0100 To: rfg@tristatelogic.com, freebsd-security@freebsd.org Subject: Re: NEVERMIND! References: <9187.1401158774@server1.tristatelogic.com> In-Reply-To: <9187.1401158774@server1.tristatelogic.com> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (pacha.mail.dyslexicfish.net [91.109.5.35]); Tue, 27 May 2014 12:20:46 +0100 (BST) X-Mailman-Approved-At: Tue, 27 May 2014 11:48:17 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 11:20:56 -0000 I've not actually used it, but I notice this in ports: /usr/ports/sysutils/socklog: | svlogd has a built in log file rotation based on file size, so there is no | need for any cron jobs or similar to rotate the logs. Log partitions can be | calculated properly. | | WWW: http://smarden.org/socklog/ Cheers, Jamie From owner-freebsd-security@FreeBSD.ORG Tue May 27 13:36:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8907671A for ; Tue, 27 May 2014 13:36:51 +0000 (UTC) Received: from mx1.rsle.net (mx1.rsle.net [IPv6:2607:ff40:b0b::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DAE82A79 for ; Tue, 27 May 2014 13:36:51 +0000 (UTC) Received: from prometheus.rsle.net (UNKNOWN [206.162.203.14] (may be forged)) (authenticated bits=0) by mx1.rsle.net (8.14.7/8.14.7) with ESMTP id s4RDaj1e062081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 27 May 2014 09:36:46 -0400 (EDT) (envelope-from freebsd-security@rsle.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.3 at antivirus.rsle.net Message-ID: <538494E8.2060302@rsle.net> Date: Tue, 27 May 2014 09:36:40 -0400 From: "R. Scott Evans" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working References: <5382A982.6090304@calorieking.com> <86vbssr665.fsf@nine.des.no> In-Reply-To: <86vbssr665.fsf@nine.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mx1.rsle.net [206.162.201.2]); Tue, 27 May 2014 09:36:46 -0400 (EDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 13:36:51 -0000 On 05/26/14 10:00, Dag-Erling SmĆørgrav wrote: > Gregory Orange writes: >> I've got freebsd-update cron running every night, and each time get >> the following (regardless of whether I then run freebsd-update >> install): >> ---- >> The following files will be updated as part of updating to 8.4-RELEASE-p10: >> /boot/kernel/linker.hints >> ---- > > This was supposed to be fixed by the following errata notice: > > http://www.freebsd.org/security/advisories/FreeBSD-EN-14:04.kldxref.asc > > DES Well it is still broken after the 9.2-RELEASE-p6 also in that errata. The relevant thread in freebsd-questions: http://lists.freebsd.org/pipermail/freebsd-questions/2014-May/258238.html -scott From owner-freebsd-security@FreeBSD.ORG Tue May 27 18:43:38 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99921A39 for ; Tue, 27 May 2014 18:43:38 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 82FB42888 for ; Tue, 27 May 2014 18:43:37 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 4B33D3ADD6 for ; Tue, 27 May 2014 11:43:37 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! In-Reply-To: <867g57bq9o.fsf@nine.des.no> Date: Tue, 27 May 2014 11:43:37 -0700 Message-ID: <5833.1401216217@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:43:38 -0000 In message <867g57bq9o.fsf@nine.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wrote: >"Ronald F. Guilmette" writes: >> So should I file a PR on this, or what? > >*shrug* > >I think this falls under the same heading as a fork bomb - Ah! But unlike unlimited syslogging, there _is_ already something in place that limits the damage from a "fork bomb": % limits Resource limits (current): ... maxprocesses 5547 <===================== ... From owner-freebsd-security@FreeBSD.ORG Tue May 27 18:49:03 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66683D99 for ; Tue, 27 May 2014 18:49:03 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2EB28E7 for ; Tue, 27 May 2014 18:49:02 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id A30F93ADD6 for ; Tue, 27 May 2014 11:49:02 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! In-Reply-To: <201405271120.s4RBKiHp096461@catnip.dyslexicfish.net> Date: Tue, 27 May 2014 11:49:02 -0700 Message-ID: <5918.1401216542@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:49:03 -0000 In message <201405271120.s4RBKiHp096461@catnip.dyslexicfish.net>, Jamie Landeg-Jones wrote: >I've not actually used it, but I notice this in ports: > >/usr/ports/sysutils/socklog: > > | svlogd has a built in log file rotation based on file size, so there is no > | need for any cron jobs or similar to rotate the logs. Log partitions can be > | calculated properly. > | > | WWW: http://smarden.org/socklog/ Just skimming the man page for that, I have to agree that this looks like an entirely adequate solution for the problem I posed. (So clearly no need for a PR.) From owner-freebsd-security@FreeBSD.ORG Thu May 29 02:04:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBBEFBC6 for ; Thu, 29 May 2014 02:04:09 +0000 (UTC) Received: from pandora.au.calorieking.net (114.179.70.115.static.exetel.com.au [115.70.179.114]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 722912CC0 for ; Thu, 29 May 2014 02:04:08 +0000 (UTC) Received: from pandora.internal (localhost [127.0.0.1]) by pandora.au.calorieking.net (Postfix) with ESMTP id CE83133CF6 for ; Thu, 29 May 2014 10:03:53 +0800 (WST) X-Virus-Scanned: amavisd-new at calorieking.com Received: from pandora.au.calorieking.net ([127.0.0.1]) by pandora.internal (pandora.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0S8MoYlvvPE for ; Thu, 29 May 2014 10:03:43 +0800 (WST) Received: from egeria.internal (egeria.internal [192.168.2.111]) by pandora.au.calorieking.net (Postfix) with ESMTPSA id EA4A133CF5 for ; Thu, 29 May 2014 10:03:43 +0800 (WST) Message-ID: <5386957E.2070000@calorieking.com> Date: Thu, 29 May 2014 10:03:42 +0800 From: Gregory Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working References: <5382A982.6090304@calorieking.com> <86vbssr665.fsf@nine.des.no> <538494E8.2060302@rsle.net> In-Reply-To: <538494E8.2060302@rsle.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 02:04:09 -0000 On 27/05/14 21:36, R. Scott Evans wrote: > On 05/26/14 10:00, Dag-Erling SmĆørgrav wrote: >> This was supposed to be fixed by the following errata notice: >> http://www.freebsd.org/security/advisories/FreeBSD-EN-14:04.kldxref.asc > > Well it is still broken after the 9.2-RELEASE-p6 also in that errata. > > The relevant thread in freebsd-questions: > http://lists.freebsd.org/pipermail/freebsd-questions/2014-May/258238.html I'm left wondering what to do next: * Should I simply delete linker.hints - would that cause unwanted behaviour? * Should I instead move linker.hints aside before freebsd-update cron & freebsd-update install, then move it back again? That seems to work on a manual test, but seems ugly. * Should I post an official PR somewhere? Greg. From owner-freebsd-security@FreeBSD.ORG Sat May 31 00:43:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BFEF1FB; Sat, 31 May 2014 00:43:50 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93F722090; Sat, 31 May 2014 00:43:49 +0000 (UTC) Received-SPF: pass (freebsd.czest.pl: domain of wkoszek@freebsd.czest.pl designates 212.87.224.105 as permitted sender) receiver=freebsd.czest.pl; client-ip=212.87.224.105; helo=freebsd.czest.pl; envelope-from=wkoszek@freebsd.czest.pl; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf-unknown; Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s4V0dqLG075195; Sat, 31 May 2014 00:39:52 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s4V0dqqH075194; Sat, 31 May 2014 00:39:52 GMT (envelope-from wkoszek) Date: Sat, 31 May 2014 00:39:52 +0000 From: "Wojciech A. Koszek" To: Shawn Webb Subject: Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable Message-ID: <20140531003952.GM91702@FreeBSD.org> References: <20140514135852.GC3063@pwnie.vrt.sourcefire.com> <20140523195329.GC91702@FreeBSD.org> <20140524003525.GC2029@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140524003525.GC2029@pwnie.vrt.sourcefire.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Sat, 31 May 2014 00:39:59 +0000 (UTC) X-Mailman-Approved-At: Sat, 31 May 2014 01:51:38 +0000 Cc: freebsd-security@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Oliver Pinter X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 00:43:50 -0000 On Fri, May 23, 2014 at 08:35:25PM -0400, Shawn Webb wrote: > On May 23, 2014 07:53 PM +0000, Wojciech A. Koszek wrote: > > On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote: > > > Hey All, > > > > > > [NOTE: crossposting between freebsd-current@, freebsd-security@, and > > > freebsd-stable@. Please forgive me if crossposting is frowned upon.] > > > > > > Address Space Layout Randomization, or ASLR for short, is an exploit > > > mitigation technology. It helps secure applications against low-level > > > exploits. A popular secure implementation is known as PaX ASLR, which is > > > a third-party patch for Linux. Our implementation is based off of PaX's. > > > > > > Oliver Pinter, Danilo Egea, and I have been working hard to bring more > > > features and robust stability to our ASLR patches. We've done extensive > > > testing on amd64. We'd like to get as many people testing these patches. > > > Given the nature of them, we'd also like as many eyeballs reviewing the > > > code as well. > > > > > > I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on > > > the RPI), when a parent forks a child, and the child gracefully exits, > > > the parent segfaults with the pc register pointing to 0xc0000000. That > > > address is always the same, no matter the application. If anyone knows > > > the ARM architecture well, and how FreeBSD ties into it, I'd like a > > > little guidance. > > > > > > I also have a sparc64 box, but I'm having trouble getting a vanilla > > > 11-current system to be stable on it. I ought to file a few PRs. > > > > > > You can find links to the patches below. > > > > > > Patch for 11-current: > > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff > > > > > > Patch for 10-stable: > > > http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff > > > > > > > Shawn > > > > I appreciate you working on this. We must have this in FreeBSD. > > > > I looked at the patch and I read, but not run it. Comments below. > > > > My personal opinion is that kern_pax.c should be compiled in by default. If > > it adds a lot of size, it'd be better to provide empty stub calls instead of > > #ifdef'ing everything. But security is very important especially in > > embeddded systems, so you can imagine you're writing the code that everybody > > wants and must have enabled for decent level of security. > > > > All modern systems run with ASLR turned on. > > > > I skipped user-space stuff. I don't think it's necessary in this commit and > > should be separated. > > > > There's a lot of lines of code for status showing. Not sure if we care that > > much: ASLR is either on or off. Not sure about more granularity. More below. > > We provide the level of granularity because there are a lot of > applications that might exhibit weird behaviors or even crash if we > randomize too many bits. We provide sane defaults, but allow each user > to choose the level of security versus the level of stability they > desire. I'm OK with it being more granular if that's the case. But Linux/MacOSX all have ASLR. If we have programs in ports/ that run on Linux, it's likely they'll just work. If they break, we'll just marked them as broken and to be fixed by the maintainer. Can you run GNOME or KDE with your patch? Or node.js? Node.js uses JIT engine for Javascript. If it works, it's quite likely other will work. > > > > kern_jail.c: > > > > something looks wrong here. Sounds like you need "pr->pax". But I don't > > understand why you need to have these pr_* values here. It seems > > unnecessary. > > I've made it possible to have per-jail ASLR settings. If you have an > application that misbehaves, you can jail it with ASLR turned off just > for that jail. My BSDCan presentation talks about this. The recording > isn't up, yet, though. I don't get it. If there's a program that is broken but you want to run it in jail, our rc.d jail startup script should earn a "NOPIE" function maybe. I believed PIE/NOPIE is per-process setting on whether to use PIE or not. In this case we'd be able to do: /usr/sbin/jail ...... /usr/sbin/nopax program ... In Linux you can do it with personalities. I don't know what it would translate in the FreeBSD to. I guess this could be achieved with simple per-process SYSCTL. "nopax" would disable ASLR, fork and exec(). > > I can imagine we won't want ASLR only temporarily, for ports which break and > > must be fixed. So we probably just need per-process ASLR on/off switch and a > > wrapper which could be used like: > > > > aslr off program .... > > So we have right now an addition to mac_bsdextended(4)/ugidfw(8) that > does this exact thing. We also plan on adding FS extended attribute > support soon, too. Also, per-jail ASLR settings. If you can already do it with MAC layer, it should be enough. Touching jail(8) will require lots of people to review this patch and analyze it in a great details, which typically slows things down a lot. > > The debug stuff I'd remove too. We could have additional CTR stubs used > > there, if necessary. > > Oliver just released a new patchset today with new debugging > functionality. I'd love to hear your commments on it. Like des@ and David said: I'd just use ktrace/audit subsystem. > > > > segvguard part I didn't understand. Why do you keep a list of programs that > > failed? There was no ASSERTs, thus it was hard to understand the locking > > too. > > We've semi-paused development of segvguard for the moment to focus on > ASLR. Though the features are related and segvguard is recommended for a > proper ASLR implementation, it is not required. Danilo Egea Gondolfo is > the principal engineer behind our segvguard implementation. We're still > working out the kinks and the underlying design and architecture of this > feature. What is it for? What does it do? I'd remove it until you get basic ASLR in the kernel. > > I'm trying to understand if randomization is done correctly. Do you think > > you could post the results? > > > > Program: > > > > http://pastebin.com/XTRHLhMg > > My results on an amd64 VM are pasted here: http://ix.io/cD5 > OK, so the comparison for stack is: MacOSX : 0xfffff000 20 random bits Linux : 0xfffffff0 28 random bits FreeBSD: 0x000ffff0 16 random bits Could we make FreeBSD be like Linux? Heap randomization also looks better on Linux. Thanks for preparing it. -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-security@FreeBSD.ORG Tue Jun 3 19:34:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76BC2B7; Tue, 3 Jun 2014 19:34:10 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5787E2E86; Tue, 3 Jun 2014 19:34:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s53JYAEL015015; Tue, 3 Jun 2014 19:34:10 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s53JYAtk015013; Tue, 3 Jun 2014 19:34:10 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 3 Jun 2014 19:34:10 GMT Message-Id: <201406031934.s53JYAtk015013@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:11.sendmail Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:34:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:11.sendmail Security Advisory The FreeBSD Project Topic: sendmail improper close-on-exec flag handling Category: contrib Module: sendmail Announced: 2014-06-03 Affects: All supported versions of FreeBSD. Corrected: 2014-05-26 15:35:11 UTC (stable/10, 10.0-STABLE) 2014-06-03 19:02:52 UTC (releng/10.0, 10.0-RELEASE-p4) 2014-05-26 20:10:00 UTC (stable/9, 9.3-PRERELEASE) 2014-06-03 19:03:11 UTC (releng/9.2, 9.2-RELEASE-p7) 2014-06-03 19:03:11 UTC (releng/9.1, 9.1-RELEASE-p14) 2014-05-26 15:30:27 UTC (stable/8, 8.4-STABLE) 2014-06-03 19:03:23 UTC (releng/8.4, 8.4-RELEASE-p11) For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes sendmail(8), a general purpose internetwork mail routing facility, as the default Mail Transfer Agent (MTA). FreeBSD uses file descriptor as an abstract indicator for accessing a file. Upon execve(2), file descriptors open in the calling process image remain open in the new process image, except for those for which the close-on-exec flag is set. II. Problem Description There is a programming error in sendmail(8) that prevented open file descriptors have close-on-exec properly set. Consequently a subprocess will be able to access all open files that the parent process have open. III. Impact A local user who can execute their own program for mail delivery will be able to interfere with an open SMTP connection. IV. Workaround Do not allow untrusted users to specify programs for mail delivery, for instance, procmail. Systems that do not use sendmail(8) MTA are not affected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:11/sendmail.patch # fetch http://security.FreeBSD.org/patches/SA-14:11/sendmail.patch.asc # gpg --verify sendmail.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart the applicable daemons, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r266693 releng/8.4/ r267019 stable/9/ r266711 releng/9.1/ r267018 releng/9.2/ r267018 stable/10/ r266692 releng/10.0/ r267017 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTjiDaAAoJEO1n7NZdz2rnMxgP/0N9dTCKztkx92+Er1riKEns k0dfQswsTn2BwKzqIwiuzYcC9YFuBbU/ydfhIy3CGHJoZXd98sl0IZkWok7N7gYb N46aSyMypHh5RtoxtRm7aLhmKSBXiXhygwoeV8HW5fBhgZG544BQ+zs3wDWL/Y4J sfTEV4C254hm8+loCjtg+WIoFDtaYFWTWCUm1Yhxb1puN5scCNNgbvqvmhmrCLtb n/AoWUvqQi8B7tu2YafbG+BE8qaLC+tGpqC4mF3NxtNUX++4HMC6ZhbcOaa2PKrk kepReV/zdc3DaZ0e0KsiwFBiWMe9NW0RjHaZeDe3wzbX9fer2WjoOszLw7xLo/8s GPZwI+fPRysKGRXeW+0Bp3itbHYAFUhS5PttZQcGqzFKIRNLdVcAIMsj/+j32/LM vVw3e1NpsIhpxqIorxJEwuBxr4SWzCY26TbJVG+jWqEzhaRgjgpW+TZ2bhW3EDKm CNnngufJzh54/rEKolWxntyiw442JRpcPvumiUiH9WmRHipkCrMttQGA9TfjUy0u diQFs/nWNa9YeUkF1jB7eMFoJubg5d/7/gDFPbHMvgjP7kN75k1TmeyzrBVUuplH ek+XMzxkWYPStw1QHub94VpKhVm7fjvLrq2+2bfdQnM7bRbgwdA66jSwqVQ569Hr oOFXJjVfz279BMqszAsw =JUzV -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jun 3 19:34:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15AF4BB; Tue, 3 Jun 2014 19:34:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB7352E8A; Tue, 3 Jun 2014 19:34:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s53JYAhr015050; Tue, 3 Jun 2014 19:34:10 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s53JYAPV015048; Tue, 3 Jun 2014 19:34:10 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 3 Jun 2014 19:34:10 GMT Message-Id: <201406031934.s53JYAPV015048@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:12.ktrace Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:34:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:12.ktrace Security Advisory The FreeBSD Project Topic: ktrace kernel memory disclosure Category: core Module: kern Announced: 2014-06-03 Credits: Jilles Tjoelker Affects: FreeBSD 8.4, FreeBSD 9.1 and FreeBSD 9.2 Corrected: 2014-06-03 19:02:33 UTC (stable/9, 9.3-BETA1) 2014-06-03 19:02:33 UTC (stable/9, 9.3-BETA1-p1) 2014-06-03 19:03:11 UTC (releng/9.2, 9.2-RELEASE-p7) 2014-06-03 19:03:11 UTC (releng/9.1, 9.1-RELEASE-p14) 2014-06-03 19:02:42 UTC (stable/8, 8.4-STABLE) 2014-06-03 19:03:23 UTC (releng/8.4, 8.4-RELEASE-p11) CVE Name: CVE-2014-3873 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ktrace utility enables kernel trace logging for the specified processes, commonly used for diagnostic or debugging purposes. The kernel operations that are traced include system calls, namei translations, signal processing, and I/O as well as data associated with these operations. The utility may be used only with a kernel that has been built with the ``KTRACE'' option in the kernel configuration file, which is enabled by default. II. Problem Description Due to an overlooked merge to -STABLE branches, the size for page fault kernel trace entries was set incorrectly. III. Impact A user who can enable kernel process tracing could end up reading the contents of kernel memory. Such 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 The system administrator may set sysctl security.bsd.unprivileged_proc_debug to 0 to prevent non-privileged users from using all process debugging facilities provided by the kernel, that includes ktrace functionality. Please note that this flag have broad effect and may break applications, as some of them may rely on certain debugging facilities to function. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-14:12/ktrace.patch # fetch http://security.FreeBSD.org/patches/SA-14:12/ktrace.patch.asc # gpg --verify ktrace.patch.asc b) Apply the patch. Execute the following commands as root: # 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/ r267016 releng/8.4/ r267019 stable/9/ r267015 releng/9.1/ r267018 releng/9.2/ r267018 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTjiDaAAoJEO1n7NZdz2rnIfQP/0kHBNvnNUiZ+1OWo5fMDg3N Oe7UdrvnfyeXlgw5bP4t0qwbTpn0kVYL2dfr3bxhkT1w7oF/xQjbcosx/DbzPZZs VtlAGQYh0CvOXcUZmh+COuRfcy2wkr1kKFlc2bGQVTq1uzKS+vceqA3619IWMnJO b6ClzFnn+0hk6BrUd8xdvoiYIF2RG+zcw7CxuoBQrzPYA9iO/S4ACmxzfTIgRcAD ZLGXfUEw3wlftfg605H1iV9xKm4FDUGr9qoL4W0UmYmmTmU4Z71yXSzX3A53qlRg Xd1Grw2K+zhaKaV6xL+mqox0nzSKiYuNf/ZguB5+x9ZA14ck7NtCYg6up1fgh7Ms pznVb8/GCc+IPdWJGXpSz6yFhl/MJc6mTOi+L0gOGvNKp0raNHelCpxlqavGt/tv 9Niv791FK32S8ynlP0yKRvd8Hzq4b185ehWuGWbQO8bEHljqhOyZDhysBYYWdgFi 0KG16lJopCbMPPPBVb4zfsFBvokr31m2w+/xsDD+hmaXa6C9bHIvHpuyJep4q02E 4NOoVr1x8dO5s7yVk7bNZx0WFCDYZ/DLMycLjEftHog7iq4nw29HW/Mt/rPgJWOf NiO0GEJ1XucJ1ShV/OC0B+69mFx9OsOI8kDNLE4l9oqGu2UqcZ/W0Dsa9PPl+ec+ njyksdL+yqvx9kF8fnJ0 =46Yf -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jun 3 19:34:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CC3DBF; Tue, 3 Jun 2014 19:34:11 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87A702E8E; Tue, 3 Jun 2014 19:34:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s53JYBqr015084; Tue, 3 Jun 2014 19:34:11 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s53JYB6S015082; Tue, 3 Jun 2014 19:34:11 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 3 Jun 2014 19:34:11 GMT Message-Id: <201406031934.s53JYB6S015082@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:13.pam Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:34:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:13.pam Security Advisory The FreeBSD Project Topic: Incorrect error handling in PAM policy parser Category: contrib Module: pam Announced: 2014-06-03 Credits: Peter Wemm, Dag-Erling SmĆørgrav Affects: FreeBSD 9.2 and later. Corrected: 2014-06-03 19:02:33 UTC (stable/9, 9.3-BETA1) 2014-06-03 19:02:33 UTC (stable/9, 9.3-BETA1-p1) 2014-06-03 19:03:11 UTC (releng/9.2, 9.2-RELEASE-p7) 2014-06-03 19:02:18 UTC (stable/10, 10.0-STABLE) 2014-06-03 19:02:52 UTC (releng/10.0, 10.0-RELEASE-p4) CVE Name: CVE-2014-3879 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The PAM (Pluggable Authentication Modules) library provides a flexible framework for user authentication and session setup / teardown. It is used not only in the base system, but also by a large number of third-party applications. Various authentication methods (UNIX, LDAP, Kerberos etc.) are implemented in modules which are loaded and executed according to predefined, named policies. These policies are defined in /etc/pam.conf, /etc/pam.d/, /usr/local/etc/pam.conf or /usr/local/etc/pam.d/. The PAM API is a de facto industry standard which has been implemented by several parties. FreeBSD uses the OpenPAM implementation. II. Problem Description The OpenPAM library searches for policy definitions in several locations. While doing so, the absence of a policy file is a soft failure (handled by searching in the next location) while the presence of an invalid file is a hard failure (handled by returning an error to the caller). The policy parser returns the same error code (ENOENT) when a syntactically valid policy references a non-existent module as when the requested policy file does not exist. The search loop regards this as a soft failure and looks for the next similarly-named policy, without discarding the partially-loaded configuration. A similar issue can arise if a policy contains an include directive that refers to a non-existent policy. III. Impact If a module is removed, or the name of a module is misspelled in the policy file, the PAM library will proceed with a partially loaded configuration. Depending on the exact circumstances, this may result in a fail-open scenario where users are allowed to log in without a password, or with an incorrect password. In particular, if a policy references a module installed by a package or port, and that package or port is being reinstalled or upgraded, there is a brief window of time during which the module is absent and policies that use it may fail open. This can be especially damaging to Internet-facing SSH servers, which are regularly subjected to brute-force scans. IV. Workaround If your system uses customized PAM policies, carefully review your policies to ensure that all module names are spelled correctly. If your system uses third-party authentication modules, either refrain from upgrading those modules until you have patched your system, or shut down the affected services before upgrading. 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] # fetch http://security.FreeBSD.org/patches/SA-14:13/pam-freebsd9.patch # fetch http://security.FreeBSD.org/patches/SA-14:13/pam-freebsd9.patch.asc # gpg --verify pam-freebsd9.patch.asc [FreeBSD 9.3 and 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:13/pam-freebsd10.patch # fetch http://security.FreeBSD.org/patches/SA-14:13/pam-freebsd10.patch.asc # gpg --verify pam-freebsd10.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r267015 releng/9.2/ r267018 stable/10/ r267014 releng/10.0/ r267017 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTjiDaAAoJEO1n7NZdz2rnx90P/je9ArC02N90sK//UauenbXV BJCNh1WRSVE3hoxgVyPC0R+6Ts6J9At42ANUHXHVxipA2Qpu2UKf+/c3JreSuSGs 6rgAj1TPZEideQInTs9qCJWr6f/M2aPlYCF8iHuuLMJTO35wfVYQENDaFJmebKoI fKkVvTh8ig2cgJWe7RZxd+Y4tPxKZb5ix5jV+xFjDPrmzVgSCUVpW0GrD7qWOg1W 25Ysx+LLBr03guDnFd9RodObWoNZ+aFxuvkKELmjUKva7xRSEw6PfwPCpLp9/83Q HDVlkw0jH+0sF1SY7V+GUvQriPNpwyGNEOfDvL47gnlN/Z7HOZ0hYlVuYw4QYGv5 l5PZOL5eFC6xl88fn+ypKQwGDdzpM4i+svBy//2CW17luU31L4F/cde+yCxsEJB5 JXNhVTYe2z+ACfSs+Oxzk5uGI1f9FhvTzIyoO26Coq6e2Nk2633451kRgdPNxoAP kMimT2Mle/1kqupLirGi44lEyUYV9As2AhnLBFFUXTnESlWVe6q0N0Rb8G6D2jcR 0m5hccsS2HcysUtSIP8ADB6LlSgH+bKP2FUFopdjQUx3J+/KQ5kl6L/UhOOr1Hag 4PdoCPpR15s2CaICmu5HkDtGNkZQV7xdN6TLcksJHXRshISlbzZjlaNyrbu6oJu9 nz3mhzGz1ZH6l7kuNYXD =qUxk -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jun 3 20:03:58 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B55C22F8 for ; Tue, 3 Jun 2014 20:03:58 +0000 (UTC) Received: from awww.jeah.net (mail-first2.jeah.net [208.185.93.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75F3524AC for ; Tue, 3 Jun 2014 20:03:57 +0000 (UTC) Received: from [0.0.0.0] (localhost.jeah.net [127.0.0.1]) by awww.jeah.net (8.14.6/8.14.6) with ESMTP id s53JdY6o002811 for ; Tue, 3 Jun 2014 14:39:35 -0500 (CDT) (envelope-from chris@jeah.co) Message-ID: <538E2472.5070809@jeah.co> Date: Tue, 03 Jun 2014 14:39:30 -0500 From: Chris User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:11.sendmail References: <201406031934.s53JYAn9015020@freefall.freebsd.org> In-Reply-To: <201406031934.s53JYAn9015020@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.4 required=4.0 tests=ALL_TRUSTED,BAYES_00, KHOP_PGP_INLINE,KHOP_THREADED autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on awww.jeah.net X-Mailman-Approved-At: Tue, 03 Jun 2014 20:20:04 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:03:58 -0000 http://security.FreeBSD.org/patches/SA-14:11/sendmail.patch does not exist. Chris On 6/3/2014 2:34 PM, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-14:11.sendmail Security Advisory > The FreeBSD Project > > Topic: sendmail improper close-on-exec flag handling > > Category: contrib > Module: sendmail > Announced: 2014-06-03 > Affects: All supported versions of FreeBSD. > Corrected: 2014-05-26 15:35:11 UTC (stable/10, 10.0-STABLE) > 2014-06-03 19:02:52 UTC (releng/10.0, 10.0-RELEASE-p4) > 2014-05-26 20:10:00 UTC (stable/9, 9.3-PRERELEASE) > 2014-06-03 19:03:11 UTC (releng/9.2, 9.2-RELEASE-p7) > 2014-06-03 19:03:11 UTC (releng/9.1, 9.1-RELEASE-p14) > 2014-05-26 15:30:27 UTC (stable/8, 8.4-STABLE) > 2014-06-03 19:03:23 UTC (releng/8.4, 8.4-RELEASE-p11) > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes sendmail(8), a general purpose internetwork mail > routing facility, as the default Mail Transfer Agent (MTA). > > FreeBSD uses file descriptor as an abstract indicator for accessing a file. > Upon execve(2), file descriptors open in the calling process image remain > open in the new process image, except for those for which the close-on-exec > flag is set. > > II. Problem Description > > There is a programming error in sendmail(8) that prevented open file > descriptors have close-on-exec properly set. Consequently a subprocess > will be able to access all open files that the parent process have open. > > III. Impact > > A local user who can execute their own program for mail delivery will be > able to interfere with an open SMTP connection. > > IV. Workaround > > Do not allow untrusted users to specify programs for mail delivery, for > instance, procmail. > > Systems that do not use sendmail(8) MTA are not affected. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to a supported FreeBSD stable or > release / security branch (releng) dated after the correction date. > > 2) To update your vulnerable system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-14:11/sendmail.patch > # fetch http://security.FreeBSD.org/patches/SA-14:11/sendmail.patch.asc > # gpg --verify sendmail.patch.asc > > b) Apply the patch. Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile the operating system using buildworld and installworld as > described in . > > Restart the applicable daemons, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r266693 > releng/8.4/ r267019 > stable/9/ r266711 > releng/9.1/ r267018 > releng/9.2/ r267018 > stable/10/ r266692 > releng/10.0/ r267017 > - ------------------------------------------------------------------------- > > 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 v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTjiDaAAoJEO1n7NZdz2rnMxgP/0N9dTCKztkx92+Er1riKEns > k0dfQswsTn2BwKzqIwiuzYcC9YFuBbU/ydfhIy3CGHJoZXd98sl0IZkWok7N7gYb > N46aSyMypHh5RtoxtRm7aLhmKSBXiXhygwoeV8HW5fBhgZG544BQ+zs3wDWL/Y4J > sfTEV4C254hm8+loCjtg+WIoFDtaYFWTWCUm1Yhxb1puN5scCNNgbvqvmhmrCLtb > n/AoWUvqQi8B7tu2YafbG+BE8qaLC+tGpqC4mF3NxtNUX++4HMC6ZhbcOaa2PKrk > kepReV/zdc3DaZ0e0KsiwFBiWMe9NW0RjHaZeDe3wzbX9fer2WjoOszLw7xLo/8s > GPZwI+fPRysKGRXeW+0Bp3itbHYAFUhS5PttZQcGqzFKIRNLdVcAIMsj/+j32/LM > vVw3e1NpsIhpxqIorxJEwuBxr4SWzCY26TbJVG+jWqEzhaRgjgpW+TZ2bhW3EDKm > CNnngufJzh54/rEKolWxntyiw442JRpcPvumiUiH9WmRHipkCrMttQGA9TfjUy0u > diQFs/nWNa9YeUkF1jB7eMFoJubg5d/7/gDFPbHMvgjP7kN75k1TmeyzrBVUuplH > ek+XMzxkWYPStw1QHub94VpKhVm7fjvLrq2+2bfdQnM7bRbgwdA66jSwqVQ569Hr > oOFXJjVfz279BMqszAsw > =JUzV > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 12:28:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BBD6385 for ; Thu, 5 Jun 2014 12:28:22 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 22B3F2493 for ; Thu, 5 Jun 2014 12:28:22 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id q108so1386752qgd.33 for ; Thu, 05 Jun 2014 05:28:21 -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:cc:content-type; bh=4NMCkhdGRswfT3CihubaanxEL7l2u71M9/zNg7FBvnA=; b=0wGMaIwf6zaSYfkVGqZ2inIxNlMobAXGkYLU4p2F1O/Y4z40Ml5Jg5iyvi5CWhtjyo QFjHLw5Pyj03q22ChvoBIQNwQ2ypTnU+foqXjGI1vOzLjU7Btf84VCoMNz0vINpGv1kh qdMIDiaO2LOF6a8sPVL+0q8p8KHtKGv3F1tS9pd48V9me3dTviTTj4FJ7pNk3nq/Cexb QOLd5C0hvK3jXZUSppaPpaKSHe+D9qlTD4OOyRiAwMH3HEo3gzmhuMyXeHrdJy+dlRaD k4dr8PA9onOxpkBskw3glx9VpAE9+43mmdm5C/ku0G78SoOEQcAooJyFuAy0nk7aug5a NL1w== MIME-Version: 1.0 X-Received: by 10.140.21.239 with SMTP id 102mr80035633qgl.31.1401971300917; Thu, 05 Jun 2014 05:28:20 -0700 (PDT) Received: by 10.229.96.132 with HTTP; Thu, 5 Jun 2014 05:28:20 -0700 (PDT) Date: Thu, 5 Jun 2014 13:28:20 +0100 Message-ID: Subject: New OpenSSL SA From: Big Lebowski Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:28:22 -0000 https://www.openssl.org/news/secadv_20140605.txt Debian and RHEL already published theirs: Debian advisory: https://lists.debian.org/debian-security-announce/2014/msg00129.html Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html I wonder when we'll get ours this time? ;) Regards, BL From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 13:16:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9498146; Thu, 5 Jun 2014 13:16:55 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B46632B4F; Thu, 5 Jun 2014 13:16:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s55DGtLS041950; Thu, 5 Jun 2014 13:16:55 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s55DGtwI041948; Thu, 5 Jun 2014 13:16:55 GMT (envelope-from security-advisories@freebsd.org) Date: Thu, 5 Jun 2014 13:16:55 GMT Message-Id: <201406051316.s55DGtwI041948@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:16:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:14.openssl Security Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-06-05 Affects: All supported versions of FreeBSD. Corrected: 2014-06-05 12:32:38 UTC (stable/10, 10.0-STABLE) 2014-06-05 12:33:23 UTC (releng/10.0, 10.0-RELEASE-p5) 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1) 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1-p2) 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) 2014-06-05 12:33:23 UTC (releng/9.1, 9.1-RELEASE-p15) 2014-06-05 12:32:38 UTC (stable/8, 8.4-STABLE) 2014-06-05 12:33:23 UTC (releng/8.4, 8.4-RELEASE-p12) CVE Name: CVE-2014-0195, CVE-2014-0221, CVE-2014-0224, CVE-2014-3470 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description Receipt of an invalid DTLS fragment on an OpenSSL DTLS client or server can lead to a buffer overrun. [CVE-2014-0195] Receipt of an invalid DTLS handshake on an OpenSSL DTLS client can lead the code to unnecessary recurse. [CVE-2014-0221] Carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. [CVE-2014-0224] Carefully crafted packets can lead to a NULL pointer deference in OpenSSL TLS client code if anonymous ECDH ciphersuites are enabled. [CVE-2014-3470] III. Impact A remote attacker may be able to run arbitrary code on a vulnerable client or server by sending invalid DTLS fragments to an OpenSSL DTLS client or server. [CVE-2014-0195] A remote attacker who can send an invalid DTLS handshake to an OpenSSL DTLS client can crash the remote OpenSSL DTLS client. [CVE-2014-0221] A remote attacker who can send a carefully crafted handshake can force the use of weak keying material between a vulnerable client and a vulnerable server and decrypt and/or modify traffic from the attacked client and server in a man-in-the-middle (MITM) attack. [CVE-2014-0224] A remote attacker who can send carefully crafted packets can cause OpenSSL TLS client to crash. [CVE-2014-3470] 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 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch.asc # gpg --verify openssl-10.patch.asc [FreeBSD 9.x and 8.x] # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch.asc # gpg --verify openssl-9.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r267103 releng/8.4/ r267104 stable/9/ r267106 releng/9.1/ r267104 releng/9.2/ r267104 stable/10/ r267103 releng/10.0/ r267104 - ------------------------------------------------------------------------- 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 v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTkGuTAAoJEO1n7NZdz2rnomEP/AzIur2b4KXcOJnPSq+Fgz2E ThZnGpYaWGQXkBnPcARtLUN+98UQkdcVOpDXExdTP/mz+fRH5P14qBCwgFXfMX1a Ins6M696pAyBE+SHjFMwX/pSA402Y2LFcfUgq1f9oBKPM77+X/9J4z4NPXB72qTp ULLTBVtHiqwlcO6bD+YlpE5AfvoKoUI0MmmkuA4R1zmY/JBgDqN68oiTn7KwRp5m v44uVuGF+gGMMkN5oZmXqn89+CbRjDkyk9gvHhe1VXZLfZi6GDlayNMpuBdj9laU 3jpMMqwXGF45j524Ai03U/lAzO7Fn1Zl87dlElPk1BMaVmG8uGFipiULPQqsyUC9 rchzXxtDM7VVA/p7G3Vn6RHbOPeNCxhuFonq1WxVBrXImIw23PRWDlYx+Kve5trH gJvztI6CkD0f6NOf7HM7LYU1slvGFykFhoGeurxFVfKT2YlulL6HcRx4QPFE33c1 W57wPHUvZ2w8hO0OU1zX1pz1qE6je+DoSTq7bob5ExXmDWCu2LElmKXW67N2tGYq kNetRkTR9qwDlmexrcyAVgR45a/9oe/p9taTgm2/8ITzaHjexYcGn/tL7Mc9pYCa Dj9FP0D52foKj3PjVfSZc/8kgJklKhtugDvbK74MmruA6vUELRrY84O2kfpgAzLj KfE2eBuieG9+Pdpk011t =/CUF -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 14:16:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27CDB3C9 for ; Thu, 5 Jun 2014 14:16:00 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id C31192226 for ; Thu, 5 Jun 2014 14:15:58 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s55EEMtf043950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jun 2014 15:14:22 +0100 (BST) Date: Thu, 05 Jun 2014 15:14:22 +0100 From: Karl Pielorz To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl Message-ID: <08DED76B16E5AB7BE75CA6B5@Mail-PC.tdx.co.uk> In-Reply-To: <201406051316.s55DGtwI041948@freefall.freebsd.org> References: <201406051316.s55DGtwI041948@freefall.freebsd.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:16:00 -0000 --On 05 June 2014 13:16 +0000 FreeBSD Security Advisories wrote: ># cd /usr/src ># patch < /path/to/patch > > c) Recompile the operating system using buildworld and installworld as > described in . Hi, Is it necessary to build/install the entire world if you're more concerned with protecting specific applications using the OpenSSL library? - e.g. if the machine is just running Apache? How would you just recompile / install openssl in the base on it's own? Is there anything in FreeBSD that statically links against openssl anyway? Cheers, -Karl From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 15:18:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23065D9D for ; Thu, 5 Jun 2014 15:18:41 +0000 (UTC) Received: from smtp2.ppse.net (smtp2.ppse.net [217.195.113.12]) by mx1.freebsd.org (Postfix) with ESMTP id A417528BA for ; Thu, 5 Jun 2014 15:18:40 +0000 (UTC) Received: from Jappes-MacBook-Pro.local (office.vellance.net [95.97.142.106]) by smtp2.ppse.net (Postfix) with ESMTPA id F28E93F404 for ; Thu, 5 Jun 2014 17:09:57 +0200 (CEST) Message-ID: <53908845.20900@lowlife.org> Date: Thu, 05 Jun 2014 17:09:57 +0200 From: Jappe Reuling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtGw041955@freefall.freebsd.org> In-Reply-To: <201406051316.s55DGtGw041955@freefall.freebsd.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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:18:41 -0000 Hi, One, my appologies if it's a stupid one, question: the advisory is for DTLS, hence UDP TLS, right? Normally you would run SSL (TLS a.o.) via TCP. So what would use DTLS (in the base system) and could be vulnerable? A mailserver using TLS and linked to the base system's openssl would be using TCP...? Thanks in advance. Jappe On 05/06/14 15:16, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-14:14.openssl Security Advisory > The FreeBSD Project > > Topic: OpenSSL multiple vulnerabilities > > Category: contrib > Module: openssl > Announced: 2014-06-05 > Affects: All supported versions of FreeBSD. > Corrected: 2014-06-05 12:32:38 UTC (stable/10, 10.0-STABLE) > 2014-06-05 12:33:23 UTC (releng/10.0, 10.0-RELEASE-p5) > 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1) > 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1-p2) > 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) > 2014-06-05 12:33:23 UTC (releng/9.1, 9.1-RELEASE-p15) > 2014-06-05 12:32:38 UTC (stable/8, 8.4-STABLE) > 2014-06-05 12:33:23 UTC (releng/8.4, 8.4-RELEASE-p12) > CVE Name: CVE-2014-0195, CVE-2014-0221, CVE-2014-0224, CVE-2014-3470 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is > a collaborative effort to develop a robust, commercial-grade, full-featured > Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) > and Transport Layer Security (TLS v1) protocols as well as a full-strength > general purpose cryptography library. > > II. Problem Description > > Receipt of an invalid DTLS fragment on an OpenSSL DTLS client or server can > lead to a buffer overrun. [CVE-2014-0195] > > Receipt of an invalid DTLS handshake on an OpenSSL DTLS client can lead the > code to unnecessary recurse. [CVE-2014-0221] > > Carefully crafted handshake can force the use of weak keying material in > OpenSSL SSL/TLS clients and servers. [CVE-2014-0224] > > Carefully crafted packets can lead to a NULL pointer deference in OpenSSL > TLS client code if anonymous ECDH ciphersuites are enabled. [CVE-2014-3470] > > III. Impact > > A remote attacker may be able to run arbitrary code on a vulnerable client > or server by sending invalid DTLS fragments to an OpenSSL DTLS client or > server. [CVE-2014-0195] > > A remote attacker who can send an invalid DTLS handshake to an OpenSSL DTLS > client can crash the remote OpenSSL DTLS client. [CVE-2014-0221] > > A remote attacker who can send a carefully crafted handshake can force the > use of weak keying material between a vulnerable client and a vulnerable > server and decrypt and/or modify traffic from the attacked client and > server in a man-in-the-middle (MITM) attack. [CVE-2014-0224] > > A remote attacker who can send carefully crafted packets can cause OpenSSL > TLS client to crash. [CVE-2014-3470] > > 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 10.0] > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch.asc > # gpg --verify openssl-10.patch.asc > > [FreeBSD 9.x and 8.x] > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch.asc > # gpg --verify openssl-9.patch.asc > > b) Apply the patch. Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile the operating system using buildworld and installworld as > described in . > > Restart all deamons using the library, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r267103 > releng/8.4/ r267104 > stable/9/ r267106 > releng/9.1/ r267104 > releng/9.2/ r267104 > stable/10/ r267103 > releng/10.0/ r267104 > - ------------------------------------------------------------------------- > > 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 v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTkGuTAAoJEO1n7NZdz2rnomEP/AzIur2b4KXcOJnPSq+Fgz2E > ThZnGpYaWGQXkBnPcARtLUN+98UQkdcVOpDXExdTP/mz+fRH5P14qBCwgFXfMX1a > Ins6M696pAyBE+SHjFMwX/pSA402Y2LFcfUgq1f9oBKPM77+X/9J4z4NPXB72qTp > ULLTBVtHiqwlcO6bD+YlpE5AfvoKoUI0MmmkuA4R1zmY/JBgDqN68oiTn7KwRp5m > v44uVuGF+gGMMkN5oZmXqn89+CbRjDkyk9gvHhe1VXZLfZi6GDlayNMpuBdj9laU > 3jpMMqwXGF45j524Ai03U/lAzO7Fn1Zl87dlElPk1BMaVmG8uGFipiULPQqsyUC9 > rchzXxtDM7VVA/p7G3Vn6RHbOPeNCxhuFonq1WxVBrXImIw23PRWDlYx+Kve5trH > gJvztI6CkD0f6NOf7HM7LYU1slvGFykFhoGeurxFVfKT2YlulL6HcRx4QPFE33c1 > W57wPHUvZ2w8hO0OU1zX1pz1qE6je+DoSTq7bob5ExXmDWCu2LElmKXW67N2tGYq > kNetRkTR9qwDlmexrcyAVgR45a/9oe/p9taTgm2/8ITzaHjexYcGn/tL7Mc9pYCa > Dj9FP0D52foKj3PjVfSZc/8kgJklKhtugDvbK74MmruA6vUELRrY84O2kfpgAzLj > KfE2eBuieG9+Pdpk011t > =/CUF > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security-notifications@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications > To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 15:22:42 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1AEB544B for ; Thu, 5 Jun 2014 15:22:42 +0000 (UTC) Received: from smtp2.ppse.net (smtp2.ppse.net [217.195.113.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9B46229A2 for ; Thu, 5 Jun 2014 15:22:41 +0000 (UTC) Received: from Jappes-MacBook-Pro.local (office.vellance.net [95.97.142.106]) by smtp2.ppse.net (Postfix) with ESMTPA id B657B3F40E for ; Thu, 5 Jun 2014 17:22:40 +0200 (CEST) Message-ID: <53908B40.1040804@lowlife.org> Date: Thu, 05 Jun 2014 17:22:40 +0200 From: Jappe Reuling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtGw041955@freefall.freebsd.org> <53908845.20900@lowlife.org> In-Reply-To: <53908845.20900@lowlife.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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:22:42 -0000 Small addition: CVE-2014-0195 and CVE-2014-0221 refer to DTLS , the other two don't off course. regards jappe On 05/06/14 17:09, Jappe Reuling wrote: > Hi, > > One, my appologies if it's a stupid one, question: the advisory is > for DTLS, hence UDP TLS, right? Normally you would run SSL (TLS a.o.) > via TCP. So what would use DTLS (in the base system) and could be > vulnerable? A mailserver using TLS and linked to the base system's > openssl would be using TCP...? > > Thanks in advance. > > Jappe > > On 05/06/14 15:16, FreeBSD Security Advisories wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> ============================================================================= >> >> FreeBSD-SA-14:14.openssl Security Advisory >> The >> FreeBSD Project >> >> Topic: OpenSSL multiple vulnerabilities >> >> Category: contrib >> Module: openssl >> Announced: 2014-06-05 >> Affects: All supported versions of FreeBSD. >> Corrected: 2014-06-05 12:32:38 UTC (stable/10, 10.0-STABLE) >> 2014-06-05 12:33:23 UTC (releng/10.0, 10.0-RELEASE-p5) >> 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1) >> 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1-p2) >> 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) >> 2014-06-05 12:33:23 UTC (releng/9.1, 9.1-RELEASE-p15) >> 2014-06-05 12:32:38 UTC (stable/8, 8.4-STABLE) >> 2014-06-05 12:33:23 UTC (releng/8.4, 8.4-RELEASE-p12) >> CVE Name: CVE-2014-0195, CVE-2014-0221, CVE-2014-0224, >> CVE-2014-3470 >> >> For general information regarding FreeBSD Security Advisories, >> including descriptions of the fields above, security branches, and the >> following sections, please visit . >> >> I. Background >> >> FreeBSD includes software from the OpenSSL Project. The OpenSSL >> Project is >> a collaborative effort to develop a robust, commercial-grade, >> full-featured >> Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) >> and Transport Layer Security (TLS v1) protocols as well as a >> full-strength >> general purpose cryptography library. >> >> II. Problem Description >> >> Receipt of an invalid DTLS fragment on an OpenSSL DTLS client or >> server can >> lead to a buffer overrun. [CVE-2014-0195] >> >> Receipt of an invalid DTLS handshake on an OpenSSL DTLS client can >> lead the >> code to unnecessary recurse. [CVE-2014-0221] >> >> Carefully crafted handshake can force the use of weak keying material in >> OpenSSL SSL/TLS clients and servers. [CVE-2014-0224] >> >> Carefully crafted packets can lead to a NULL pointer deference in >> OpenSSL >> TLS client code if anonymous ECDH ciphersuites are enabled. >> [CVE-2014-3470] >> >> III. Impact >> >> A remote attacker may be able to run arbitrary code on a vulnerable >> client >> or server by sending invalid DTLS fragments to an OpenSSL DTLS client or >> server. [CVE-2014-0195] >> >> A remote attacker who can send an invalid DTLS handshake to an >> OpenSSL DTLS >> client can crash the remote OpenSSL DTLS client. [CVE-2014-0221] >> >> A remote attacker who can send a carefully crafted handshake can >> force the >> use of weak keying material between a vulnerable client and a vulnerable >> server and decrypt and/or modify traffic from the attacked client and >> server in a man-in-the-middle (MITM) attack. [CVE-2014-0224] >> >> A remote attacker who can send carefully crafted packets can cause >> OpenSSL >> TLS client to crash. [CVE-2014-3470] >> >> 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 10.0] >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch >> # fetch >> http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch.asc >> # gpg --verify openssl-10.patch.asc >> >> [FreeBSD 9.x and 8.x] >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch.asc >> # gpg --verify openssl-9.patch.asc >> >> b) Apply the patch. Execute the following commands as root: >> >> # cd /usr/src >> # patch < /path/to/patch >> >> c) Recompile the operating system using buildworld and installworld as >> described in . >> >> Restart all deamons using the library, or reboot the system. >> >> 3) To update your vulnerable system via a binary patch: >> >> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >> platforms can be updated via the freebsd-update(8) utility: >> >> # freebsd-update fetch >> # freebsd-update install >> >> VI. Correction details >> >> The following list contains the correction revision numbers for each >> affected branch. >> >> Branch/path Revision >> - >> ------------------------------------------------------------------------- >> stable/8/ r267103 >> releng/8.4/ r267104 >> stable/9/ r267106 >> releng/9.1/ r267104 >> releng/9.2/ r267104 >> stable/10/ r267103 >> releng/10.0/ r267104 >> - >> ------------------------------------------------------------------------- >> >> 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 v2.0.22 (FreeBSD) >> >> iQIcBAEBCgAGBQJTkGuTAAoJEO1n7NZdz2rnomEP/AzIur2b4KXcOJnPSq+Fgz2E >> ThZnGpYaWGQXkBnPcARtLUN+98UQkdcVOpDXExdTP/mz+fRH5P14qBCwgFXfMX1a >> Ins6M696pAyBE+SHjFMwX/pSA402Y2LFcfUgq1f9oBKPM77+X/9J4z4NPXB72qTp >> ULLTBVtHiqwlcO6bD+YlpE5AfvoKoUI0MmmkuA4R1zmY/JBgDqN68oiTn7KwRp5m >> v44uVuGF+gGMMkN5oZmXqn89+CbRjDkyk9gvHhe1VXZLfZi6GDlayNMpuBdj9laU >> 3jpMMqwXGF45j524Ai03U/lAzO7Fn1Zl87dlElPk1BMaVmG8uGFipiULPQqsyUC9 >> rchzXxtDM7VVA/p7G3Vn6RHbOPeNCxhuFonq1WxVBrXImIw23PRWDlYx+Kve5trH >> gJvztI6CkD0f6NOf7HM7LYU1slvGFykFhoGeurxFVfKT2YlulL6HcRx4QPFE33c1 >> W57wPHUvZ2w8hO0OU1zX1pz1qE6je+DoSTq7bob5ExXmDWCu2LElmKXW67N2tGYq >> kNetRkTR9qwDlmexrcyAVgR45a/9oe/p9taTgm2/8ITzaHjexYcGn/tL7Mc9pYCa >> Dj9FP0D52foKj3PjVfSZc/8kgJklKhtugDvbK74MmruA6vUELRrY84O2kfpgAzLj >> KfE2eBuieG9+Pdpk011t >> =/CUF >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-security-notifications@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications >> To unsubscribe, send any mail to >> "freebsd-security-notifications-unsubscribe@freebsd.org" >> > > _______________________________________________ > 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 Jun 5 15:27:05 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A8BE696 for ; Thu, 5 Jun 2014 15:27:05 +0000 (UTC) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 084FD2A0A for ; Thu, 5 Jun 2014 15:27:04 +0000 (UTC) Received: by mail-yh0-f48.google.com with SMTP id a41so970196yho.21 for ; Thu, 05 Jun 2014 08:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irrelevant.org; s=irrelevant; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pbKNNdl+Rk580KJjsC1q7XXyHJJk9ityc0PD4jlGid4=; b=YZiKFZTfDrsCjvFlenHnBTeigSRnEs/Qmrd/mNEKeDXIDNsp4UFepzXbt8XORQ3vCt XAeWpkMJ6W488aB0K0TEK56tHbMER5AKwxjXg+6W0l9HJ6tjKD+I5ahJPmqiWmpuVqwv iGHhssd/Dsevw3PIcWjDv7x5lTVswxL80Rg14= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pbKNNdl+Rk580KJjsC1q7XXyHJJk9ityc0PD4jlGid4=; b=GNdJbjhdwsqDRUr5vDveKg3XmJqHuq2X8FUJm36nCYt2HB/4zQqViaYSVLQ8m97+I2 k8vWlzR1tMByEeGpdVB1xfdRudOjZBa3dRTVtXSTPlBiplL/KHY3TmxTFZcBDQbyFg/X lwAm3n/y/wl4cB/1j3MsBLq0ziMI6Eriq9T0AOqjs8vP1w4HDdayh3ZJz2Bj0ii6cDKB z8vFVk1hu2JWOOtj49I4fvJIMdF3LdhmCp2IVgf/wYBevosSMCmJOr8bt4zRePq703qZ sHapqRoo3ctT34UzSB4wfrx0tnbvLVJcFr0aGfU0u4mgWDh/73t75eayuzKEPRTI0akZ EeDg== X-Gm-Message-State: ALoCoQmG18UrfvPqDJ0LtK57g2KP2B9yZ4Wiv9XFzhepAwnamkJEBbZzVI6UKMbsDvUqgy829iUy MIME-Version: 1.0 X-Received: by 10.236.151.116 with SMTP id a80mr85103106yhk.48.1401982024022; Thu, 05 Jun 2014 08:27:04 -0700 (PDT) Received: by 10.170.118.199 with HTTP; Thu, 5 Jun 2014 08:27:03 -0700 (PDT) X-Originating-IP: [94.31.26.101] In-Reply-To: <53908845.20900@lowlife.org> References: <201406051316.s55DGtGw041955@freefall.freebsd.org> <53908845.20900@lowlife.org> Date: Thu, 5 Jun 2014 16:27:03 +0100 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl From: Simon Dick To: Jappe Reuling Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:27:05 -0000 Mostly any third party ports that link against it... On 5 June 2014 16:09, Jappe Reuling wrote: > Hi, > > One, my appologies if it's a stupid one, question: the advisory is for > DTLS, hence UDP TLS, right? Normally you would run SSL (TLS a.o.) via TCP. > So what would use DTLS (in the base system) and could be vulnerable? A > mailserver using TLS and linked to the base system's openssl would be using > TCP...? > > Thanks in advance. > > Jappe > > > On 05/06/14 15:16, FreeBSD Security Advisories wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> >> ============================================================================= >> FreeBSD-SA-14:14.openssl Security >> Advisory >> The FreeBSD >> Project >> >> Topic: OpenSSL multiple vulnerabilities >> >> Category: contrib >> Module: openssl >> Announced: 2014-06-05 >> Affects: All supported versions of FreeBSD. >> Corrected: 2014-06-05 12:32:38 UTC (stable/10, 10.0-STABLE) >> 2014-06-05 12:33:23 UTC (releng/10.0, 10.0-RELEASE-p5) >> 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1) >> 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1-p2) >> 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) >> 2014-06-05 12:33:23 UTC (releng/9.1, 9.1-RELEASE-p15) >> 2014-06-05 12:32:38 UTC (stable/8, 8.4-STABLE) >> 2014-06-05 12:33:23 UTC (releng/8.4, 8.4-RELEASE-p12) >> CVE Name: CVE-2014-0195, CVE-2014-0221, CVE-2014-0224, CVE-2014-3470 >> >> For general information regarding FreeBSD Security Advisories, >> including descriptions of the fields above, security branches, and the >> following sections, please visit . >> >> I. Background >> >> FreeBSD includes software from the OpenSSL Project. The OpenSSL Project >> is >> a collaborative effort to develop a robust, commercial-grade, >> full-featured >> Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) >> and Transport Layer Security (TLS v1) protocols as well as a full-strength >> general purpose cryptography library. >> >> II. Problem Description >> >> Receipt of an invalid DTLS fragment on an OpenSSL DTLS client or server >> can >> lead to a buffer overrun. [CVE-2014-0195] >> >> Receipt of an invalid DTLS handshake on an OpenSSL DTLS client can lead >> the >> code to unnecessary recurse. [CVE-2014-0221] >> >> Carefully crafted handshake can force the use of weak keying material in >> OpenSSL SSL/TLS clients and servers. [CVE-2014-0224] >> >> Carefully crafted packets can lead to a NULL pointer deference in OpenSSL >> TLS client code if anonymous ECDH ciphersuites are enabled. >> [CVE-2014-3470] >> >> III. Impact >> >> A remote attacker may be able to run arbitrary code on a vulnerable client >> or server by sending invalid DTLS fragments to an OpenSSL DTLS client or >> server. [CVE-2014-0195] >> >> A remote attacker who can send an invalid DTLS handshake to an OpenSSL >> DTLS >> client can crash the remote OpenSSL DTLS client. [CVE-2014-0221] >> >> A remote attacker who can send a carefully crafted handshake can force the >> use of weak keying material between a vulnerable client and a vulnerable >> server and decrypt and/or modify traffic from the attacked client and >> server in a man-in-the-middle (MITM) attack. [CVE-2014-0224] >> >> A remote attacker who can send carefully crafted packets can cause OpenSSL >> TLS client to crash. [CVE-2014-3470] >> >> 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 10.0] >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch.asc >> # gpg --verify openssl-10.patch.asc >> >> [FreeBSD 9.x and 8.x] >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch >> # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch.asc >> # gpg --verify openssl-9.patch.asc >> >> b) Apply the patch. Execute the following commands as root: >> >> # cd /usr/src >> # patch < /path/to/patch >> >> c) Recompile the operating system using buildworld and installworld as >> described in . >> >> Restart all deamons using the library, or reboot the system. >> >> 3) To update your vulnerable system via a binary patch: >> >> Systems running a RELEASE version of FreeBSD on the i386 or amd64 >> platforms can be updated via the freebsd-update(8) utility: >> >> # freebsd-update fetch >> # freebsd-update install >> >> VI. Correction details >> >> The following list contains the correction revision numbers for each >> affected branch. >> >> Branch/path Revision >> - >> ------------------------------------------------------------------------- >> stable/8/ r267103 >> releng/8.4/ r267104 >> stable/9/ r267106 >> releng/9.1/ r267104 >> releng/9.2/ r267104 >> stable/10/ r267103 >> releng/10.0/ r267104 >> - >> ------------------------------------------------------------------------- >> >> 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 v2.0.22 (FreeBSD) >> >> iQIcBAEBCgAGBQJTkGuTAAoJEO1n7NZdz2rnomEP/AzIur2b4KXcOJnPSq+Fgz2E >> ThZnGpYaWGQXkBnPcARtLUN+98UQkdcVOpDXExdTP/mz+fRH5P14qBCwgFXfMX1a >> Ins6M696pAyBE+SHjFMwX/pSA402Y2LFcfUgq1f9oBKPM77+X/9J4z4NPXB72qTp >> ULLTBVtHiqwlcO6bD+YlpE5AfvoKoUI0MmmkuA4R1zmY/JBgDqN68oiTn7KwRp5m >> v44uVuGF+gGMMkN5oZmXqn89+CbRjDkyk9gvHhe1VXZLfZi6GDlayNMpuBdj9laU >> 3jpMMqwXGF45j524Ai03U/lAzO7Fn1Zl87dlElPk1BMaVmG8uGFipiULPQqsyUC9 >> rchzXxtDM7VVA/p7G3Vn6RHbOPeNCxhuFonq1WxVBrXImIw23PRWDlYx+Kve5trH >> gJvztI6CkD0f6NOf7HM7LYU1slvGFykFhoGeurxFVfKT2YlulL6HcRx4QPFE33c1 >> W57wPHUvZ2w8hO0OU1zX1pz1qE6je+DoSTq7bob5ExXmDWCu2LElmKXW67N2tGYq >> kNetRkTR9qwDlmexrcyAVgR45a/9oe/p9taTgm2/8ITzaHjexYcGn/tL7Mc9pYCa >> Dj9FP0D52foKj3PjVfSZc/8kgJklKhtugDvbK74MmruA6vUELRrY84O2kfpgAzLj >> KfE2eBuieG9+Pdpk011t >> =/CUF >> -----END PGP SIGNATURE----- >> _______________________________________________ >> freebsd-security-notifications@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications >> To unsubscribe, send any mail to >> "freebsd-security-notifications-unsubscribe@freebsd.org" >> > > _______________________________________________ > 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 Jun 5 15:45:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B9F71C2 for ; Thu, 5 Jun 2014 15:45:08 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A59A2BED for ; Thu, 5 Jun 2014 15:45:08 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 580E313346; Thu, 5 Jun 2014 08:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1401983107; bh=B/zmKKzcZ/BITJ7piQ8JZ4WyEd1T0BdjDWZyioC4QpY=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=UjNCPGDw9qiA0XfboBQWl94LX/zI8/o78Gvun1jx6+pJiDXqUxVSzzcffKpLlR1SK wGkOaEFAn14AduvGH8YsS7aXmd/OM1HbAfHKdOSuO/BFL+9ip++acaFZd56MEgCDtt j7Y0niAG+NKRWQfgGvgotfcrIIh39x5OjJhyVJ08= Message-ID: <53909083.5000304@delphij.net> Date: Thu, 05 Jun 2014 08:45:07 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Karl Pielorz , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtwI041948@freefall.freebsd.org> <08DED76B16E5AB7BE75CA6B5@Mail-PC.tdx.co.uk> In-Reply-To: <08DED76B16E5AB7BE75CA6B5@Mail-PC.tdx.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:45:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/5/14, 7:14 AM, Karl Pielorz wrote: > > > --On 05 June 2014 13:16 +0000 FreeBSD Security Advisories > wrote: > >> # cd /usr/src # patch < /path/to/patch >> >> c) Recompile the operating system using buildworld and >> installworld as described in >> . > > Hi, > > Is it necessary to build/install the entire world if you're more > concerned with protecting specific applications using the OpenSSL > library? - e.g. if the machine is just running Apache? We recommend recompiling the entire world because it's less likely to miss something. > How would you just recompile / install openssl in the base on it's > own? You can do openssl only build as long as you know what you are doing. > Is there anything in FreeBSD that statically links against openssl > anyway? For this one advisory, no, no statically linked binaries are affected. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTkJCDAAoJEJW2GBstM+ns9TIP/1oPhf5pg2QN1rX/SbwHh4h6 PKcB6dg4WDFzChjLXvR/C+C+tJ7Z7W5kDs6FT22hsgUqEvyqGkepNmLvP5MeCS4s FLfptjJDj2tZHQ099nr4iY4nmw+5B+1i76nr1HfO9Cew2VLs3M0XOh9IqJ0k0Jh7 5Bj97E2fePJDak+Fd5umaCbFxLRWoyx/rOjfgPu+Ux045VCmAZ6cOqkCSGtLF9qo zut4RwFMACMezvPy7xPt9URwWnCRpnbN3ijSHTEIonkkJuWyz52Dxw9EsEJrLQgB qqlY4r8WSYP5QBgl2CtEqfgUy8qyAnKIBMjn00Y/258iPUxI70AXHVTLbi0yOG0D hsEp5PZjC6GM0M+8Lvsi1Psd5ySVi/J3FyPmEG3aSRDhvQzn7sE9C+KxlJl20zhM f5xWtRInBBB3GQxYfvKQpsowVxTzkZ+kJWOSJCcfmU5Sbq+twprhOBN+XfPcRX9Q KlKdnr0+KOthTK/LM8dRYO7CAfFC1RV3HeXMWlp2xzwz+tgbLsyDwD1bnxDY+F8n WfBV7FEFIn37M3Q/5WItbO4GEoh2ZsTcIAO0y+SQW6xUlnLQqQ6GdMrMviVDTRcN szcD7mtB1LE1zM6mLmS324pQlxCypGTYyBEqAwhMa1LOaNxgAKD7KKvBMkQlN7LK axCSurcrM5FMrBp3hCYT =jTd5 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 15:57:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54A1E5A9 for ; Thu, 5 Jun 2014 15:57:56 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A8512D4A for ; Thu, 5 Jun 2014 15:57:56 +0000 (UTC) Received: from delphij-macbook.local (c-24-5-244-32.hsd1.ca.comcast.net [24.5.244.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id B8B9C1351E; Thu, 5 Jun 2014 08:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1401983875; bh=bRv20c7XaI8ZMSfhcW6L84Olf+lPKJaT4PJ6GaCi/+s=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=Xn5r6hbkRaOF00RRi8vjEVnwfGrpKwXbfsXfrb7HnCe47RCK/kwMcnd3jPdQ+Z+pd QlbhhtbDlng1p3b5JDZU/b0HvZsuArKUcg+aRedB9HvBoTWpE31YHH5itzLiywR+er /3LiVE5ZZ3KAmcuXhuwEsfLAwL+rczlO75M+JiIs= Message-ID: <53909383.50608@delphij.net> Date: Thu, 05 Jun 2014 08:57:55 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Jappe Reuling , freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtGw041955@freefall.freebsd.org> <53908845.20900@lowlife.org> In-Reply-To: <53908845.20900@lowlife.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:57:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/5/14, 8:09 AM, Jappe Reuling wrote: > Hi, > > One, my appologies if it's a stupid one, question: the advisory is > for DTLS, hence UDP TLS, right? DTLS should work with SCTP as well but most applications uses DTLS with UDP. Please note that this advisory have 4 issues and 2 of them were DTLS, 2 were TLS. > Normally you would run SSL (TLS a.o.) via TCP. So what would use > DTLS (in the base system) and could be vulnerable? A mailserver > using TLS and linked to the base system's openssl would be using > TCP...? The TLS ones are vulnerable to e.g. CVE-2014-0224 which allows MITM attack. Cheers, -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTkJODAAoJEJW2GBstM+nsMuMP/i9u5iZqW1t3zHJ+GOg+GVF0 64wqViaCtCDad0ibHQw5Mv0otxPN+J4P7QPRRGBs1lzR/yWkjZMcjqCr6qcA8wSs KGFprvoslVU67sP5A/WQGFNPhy4IkxhhpWE/+ELBvt0qkO1J8x6mctgxbHmIg45p U6YHdh2SsY/ph2HgBOcG6lsTE3AY2xSZgCVfbHxzsioX3CoaXjpup/aSQ/mfzRJU WEtEuEyrJMiIs+tolXfaQWiPBMoGuwq8B87JJgcRaHEquMsFPeYejpk4nhYAdUlm BKdrfUbZBryYIQmpIP3yws47qFgdboqwCv7HLpXqbqVwiebx5Ioz1o07ukAAe+H5 99I/8G7DYwLRccdi4blaJZhYksiEYVMagW86DRlC/Vi/i3mQPfNHZhTO88qOgtOZ drQZeQo/3ExhgHWRa2ERToyEGntPZh1rIDAIbYh6ht4LH6VpjIvIfOQgVSHVvJjA ePFUasbC64BSXvnPEVz7awyzLJSb42fJS4vGQ4/DTbmTOP8pHW14WcxTZeA/W2j2 OPkEtlcQt8OOQlyzp05mqq/wcEFNmw8OAX+LdVU+4XwzGVq4vA467LBtHnk/J1kb uqf76t4M/j05Z4UfRV4QpYmmTlFWXa1MzjvVi3i/K0oxjiNyX9bPBkd6MLAo+dfl eX0INg7phQp+cre+Sd4c =28Xl -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 17:02:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99C9CA7E for ; Thu, 5 Jun 2014 17:02:11 +0000 (UTC) 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)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EB5823AC for ; Thu, 5 Jun 2014 17:02:11 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s55H26ud095559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2014 10:02:08 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5390A288.90001@freebsd.org> Date: Fri, 06 Jun 2014 01:02:00 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Big Lebowski Subject: Re: New OpenSSL SA 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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 17:02:11 -0000 On 6/5/14, 8:28 PM, Big Lebowski wrote: > https://www.openssl.org/news/secadv_20140605.txt > > Debian and RHEL already published theirs: > > Debian advisory: > https://lists.debian.org/debian-security-announce/2014/msg00129.html > Red Hat 6 advisory: https://rhn.redhat.com/errata/RHSA-2014-0625.html > Red Hat 5 advisory: https://rhn.redhat.com/errata/RHSA-2014-0624.html > > I wonder when we'll get ours this time? ;) about 45 minutes after your email. > > Regards, > BL > _______________________________________________ > 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 Jun 5 18:43:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24C68EF4 for ; Thu, 5 Jun 2014 18:43:22 +0000 (UTC) Received: from mx1.rsle.net (mx1.rsle.net [IPv6:2607:ff40:b0b::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B71A32D66 for ; Thu, 5 Jun 2014 18:43:21 +0000 (UTC) Received: from prometheus.rsle.net (UNKNOWN [206.162.203.14] (may be forged)) (authenticated bits=0) by mx1.rsle.net (8.14.7/8.14.7) with ESMTP id s55IhGTg012939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jun 2014 14:43:16 -0400 (EDT) (envelope-from freebsd-security@rsle.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.3 at antivirus.rsle.net Message-ID: <5390BA3F.5060202@rsle.net> Date: Thu, 05 Jun 2014 14:43:11 -0400 From: "R. Scott Evans" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtwI041948@freefall.freebsd.org> In-Reply-To: <201406051316.s55DGtwI041948@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mx1.rsle.net [206.162.201.2]); Thu, 05 Jun 2014 14:43:16 -0400 (EDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:43:22 -0000 After updating via the binary patch method with freebsd-update, uname still reports 9.2-RELEASE-p7 even after reboot. An additional freebsd-update after this initial update however does not report anything new to update (aside from the ongoing persistent /boot/kernel/linker.hints). Same result on 3 amd64 systems so far. -scott On 06/05/14 09:16, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-SA-14:14.openssl Security Advisory > The FreeBSD Project > > Topic: OpenSSL multiple vulnerabilities > > Category: contrib > Module: openssl > Announced: 2014-06-05 > Affects: All supported versions of FreeBSD. > Corrected: 2014-06-05 12:32:38 UTC (stable/10, 10.0-STABLE) > 2014-06-05 12:33:23 UTC (releng/10.0, 10.0-RELEASE-p5) > 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1) > 2014-06-05 12:53:06 UTC (stable/9, 9.3-BETA1-p2) > 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) > 2014-06-05 12:33:23 UTC (releng/9.1, 9.1-RELEASE-p15) > 2014-06-05 12:32:38 UTC (stable/8, 8.4-STABLE) > 2014-06-05 12:33:23 UTC (releng/8.4, 8.4-RELEASE-p12) > CVE Name: CVE-2014-0195, CVE-2014-0221, CVE-2014-0224, CVE-2014-3470 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is > a collaborative effort to develop a robust, commercial-grade, full-featured > Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) > and Transport Layer Security (TLS v1) protocols as well as a full-strength > general purpose cryptography library. > > II. Problem Description > > Receipt of an invalid DTLS fragment on an OpenSSL DTLS client or server can > lead to a buffer overrun. [CVE-2014-0195] > > Receipt of an invalid DTLS handshake on an OpenSSL DTLS client can lead the > code to unnecessary recurse. [CVE-2014-0221] > > Carefully crafted handshake can force the use of weak keying material in > OpenSSL SSL/TLS clients and servers. [CVE-2014-0224] > > Carefully crafted packets can lead to a NULL pointer deference in OpenSSL > TLS client code if anonymous ECDH ciphersuites are enabled. [CVE-2014-3470] > > III. Impact > > A remote attacker may be able to run arbitrary code on a vulnerable client > or server by sending invalid DTLS fragments to an OpenSSL DTLS client or > server. [CVE-2014-0195] > > A remote attacker who can send an invalid DTLS handshake to an OpenSSL DTLS > client can crash the remote OpenSSL DTLS client. [CVE-2014-0221] > > A remote attacker who can send a carefully crafted handshake can force the > use of weak keying material between a vulnerable client and a vulnerable > server and decrypt and/or modify traffic from the attacked client and > server in a man-in-the-middle (MITM) attack. [CVE-2014-0224] > > A remote attacker who can send carefully crafted packets can cause OpenSSL > TLS client to crash. [CVE-2014-3470] > > 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 10.0] > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-10.patch.asc > # gpg --verify openssl-10.patch.asc > > [FreeBSD 9.x and 8.x] > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch > # fetch http://security.FreeBSD.org/patches/SA-14:14/openssl-9.patch.asc > # gpg --verify openssl-9.patch.asc > > b) Apply the patch. Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile the operating system using buildworld and installworld as > described in . > > Restart all deamons using the library, or reboot the system. > > 3) To update your vulnerable system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r267103 > releng/8.4/ r267104 > stable/9/ r267106 > releng/9.1/ r267104 > releng/9.2/ r267104 > stable/10/ r267103 > releng/10.0/ r267104 > - ------------------------------------------------------------------------- > > 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 v2.0.22 (FreeBSD) > > iQIcBAEBCgAGBQJTkGuTAAoJEO1n7NZdz2rnomEP/AzIur2b4KXcOJnPSq+Fgz2E > ThZnGpYaWGQXkBnPcARtLUN+98UQkdcVOpDXExdTP/mz+fRH5P14qBCwgFXfMX1a > Ins6M696pAyBE+SHjFMwX/pSA402Y2LFcfUgq1f9oBKPM77+X/9J4z4NPXB72qTp > ULLTBVtHiqwlcO6bD+YlpE5AfvoKoUI0MmmkuA4R1zmY/JBgDqN68oiTn7KwRp5m > v44uVuGF+gGMMkN5oZmXqn89+CbRjDkyk9gvHhe1VXZLfZi6GDlayNMpuBdj9laU > 3jpMMqwXGF45j524Ai03U/lAzO7Fn1Zl87dlElPk1BMaVmG8uGFipiULPQqsyUC9 > rchzXxtDM7VVA/p7G3Vn6RHbOPeNCxhuFonq1WxVBrXImIw23PRWDlYx+Kve5trH > gJvztI6CkD0f6NOf7HM7LYU1slvGFykFhoGeurxFVfKT2YlulL6HcRx4QPFE33c1 > W57wPHUvZ2w8hO0OU1zX1pz1qE6je+DoSTq7bob5ExXmDWCu2LElmKXW67N2tGYq > kNetRkTR9qwDlmexrcyAVgR45a/9oe/p9taTgm2/8ITzaHjexYcGn/tL7Mc9pYCa > Dj9FP0D52foKj3PjVfSZc/8kgJklKhtugDvbK74MmruA6vUELRrY84O2kfpgAzLj > KfE2eBuieG9+Pdpk011t > =/CUF > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Jun 5 18:47:07 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4E1515A for ; Thu, 5 Jun 2014 18:47:07 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id BE2702DAE for ; Thu, 5 Jun 2014 18:47:07 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id A1CA533C22; Thu, 5 Jun 2014 14:46:56 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id E517039813; Thu, 5 Jun 2014 14:46:54 -0400 (EDT) From: Lowell Gilbert To: "R. Scott Evans" Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtwI041948@freefall.freebsd.org> <5390BA3F.5060202@rsle.net> Date: Thu, 05 Jun 2014 14:46:53 -0400 In-Reply-To: <5390BA3F.5060202@rsle.net> (R. Scott Evans's message of "Thu, 05 Jun 2014 14:43:11 -0400") Message-ID: <44ha3zfb36.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 18:47:08 -0000 "R. Scott Evans" writes: > After updating via the binary patch method with freebsd-update, uname > still reports 9.2-RELEASE-p7 even after reboot. An additional > freebsd-update after this initial update however does not report > anything new to update (aside from the ongoing persistent > /boot/kernel/linker.hints). Makes sense. The kernel doesn't use SSL internally. From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 20:12:34 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B9CDDAB for ; Thu, 5 Jun 2014 20:12:34 +0000 (UTC) Received: from mx1.rsle.net (mx1.rsle.net [IPv6:2607:ff40:b0b::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34AE824C9 for ; Thu, 5 Jun 2014 20:12:34 +0000 (UTC) Received: from prometheus.rsle.net (UNKNOWN [206.162.203.14] (may be forged)) (authenticated bits=0) by mx1.rsle.net (8.14.7/8.14.7) with ESMTP id s55KCRBR044310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jun 2014 16:12:27 -0400 (EDT) (envelope-from freebsd-security@rsle.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.3 at antivirus.rsle.net Message-ID: <5390CF26.2050401@rsle.net> Date: Thu, 05 Jun 2014 16:12:22 -0400 From: "R. Scott Evans" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl References: <201406051316.s55DGtwI041948@freefall.freebsd.org> <5390BA3F.5060202@rsle.net> <44ha3zfb36.fsf@lowell-desk.lan> In-Reply-To: <44ha3zfb36.fsf@lowell-desk.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mx1.rsle.net [206.162.201.2]); Thu, 05 Jun 2014 16:12:27 -0400 (EDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:12:34 -0000 On 06/05/14 14:46, Lowell Gilbert wrote: > "R. Scott Evans" writes: > >> After updating via the binary patch method with freebsd-update, uname >> still reports 9.2-RELEASE-p7 even after reboot. An additional >> freebsd-update after this initial update however does not report >> anything new to update (aside from the ongoing persistent >> /boot/kernel/linker.hints). > > Makes sense. The kernel doesn't use SSL internally. I would agree except the advisory says this problem is corrected in 9.2-RELEASE-p8. Likewise, the freebsd-update explicitly says "The following files will be updated as part of updating to 9.2-RELEASE-p8". -scott From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 20:41:22 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C23001A0 for ; Thu, 5 Jun 2014 20:41:22 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5ACB12751 for ; Thu, 5 Jun 2014 20:41:22 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id z12so1804701wgg.12 for ; Thu, 05 Jun 2014 13:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=ckh9JOygdazbZ9o9Sa9FwlmKGZWbkzGed54vAxtCWjg=; b=f/+Azltd/suBzUFgojMzCwFhBBqiZzNt2mJfGshXpZSjp+ciGtVdGlsJq141NuPLBe RcMCQb94SKZY1qFjJ8Vo/5qmVWA/TFjaeMfPda96HsytWjY0jGdbZxSsw7OBo+fZOs2n EjuzbPKcz81QRcgOnLP/1JZnYd4giU7m8PvJpnUQhDTGZVwckqwZ8PJC5LJwSnEn22Gh SB3JsmpfTmhgXGMBRg/aEkfuF+/HG4JbPZJmQ8tyJrxz2kp22d2fsUiXp8CVp04jpE+X Xib9WhR5jat1S7eiKmPEhkq/9zpB3nmxJTvbmzdeqdsAXV35oCSbHvFLxubyOa7KY6Kw gjQw== X-Received: by 10.180.12.238 with SMTP id b14mr1745575wic.16.1402000880647; Thu, 05 Jun 2014 13:41:20 -0700 (PDT) Received: from gumby.homeunix.com (4e5670b2.skybroadband.com. [78.86.112.178]) by mx.google.com with ESMTPSA id cz8sm9451687wjc.11.2014.06.05.13.41.19 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:41:20 -0700 (PDT) Date: Thu, 5 Jun 2014 21:41:15 +0100 From: RW To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl Message-ID: <20140605214115.3797b3ee@gumby.homeunix.com> In-Reply-To: <5390CF26.2050401@rsle.net> References: <201406051316.s55DGtwI041948@freefall.freebsd.org> <5390BA3F.5060202@rsle.net> <44ha3zfb36.fsf@lowell-desk.lan> <5390CF26.2050401@rsle.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:41:22 -0000 On Thu, 05 Jun 2014 16:12:22 -0400 R. Scott Evans wrote: > On 06/05/14 14:46, Lowell Gilbert wrote: > > "R. Scott Evans" writes: > > > >> After updating via the binary patch method with freebsd-update, > >> uname still reports 9.2-RELEASE-p7 even after reboot. An > >> additional freebsd-update after this initial update however does > >> not report anything new to update (aside from the ongoing > >> persistent /boot/kernel/linker.hints). > > > > Makes sense. The kernel doesn't use SSL internally. > > I would agree except the advisory says this problem is corrected in > 9.2-RELEASE-p8. Likewise, the freebsd-update explicitly says "The > following files will be updated as part of updating to > 9.2-RELEASE-p8". The version is recorded in the kernel; freebsd-update doesn't update the kernel just to update the version. From owner-freebsd-security@FreeBSD.ORG Thu Jun 5 22:45:29 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBE81E92 for ; Thu, 5 Jun 2014 22:45:29 +0000 (UTC) Received: from mail.utahbroadband.com (mail.utahbroadband.com [204.14.20.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.utahbroadband.com", Issuer "mail.utahbroadband.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB679243B for ; Thu, 5 Jun 2014 22:45:29 +0000 (UTC) Received: (qmail 18877 invoked by uid 89); 5 Jun 2014 22:38:14 -0000 Received: from unknown (HELO ?192.168.0.8?) (danallen46@airwired.net@66.29.174.6) by mail.utahbroadband.com with ESMTPA; 5 Jun 2014 22:38:14 -0000 From: Dan Allen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: freebsd-update p5 is labeled p4 Message-Id: Date: Thu, 5 Jun 2014 16:38:44 -0600 To: freebsd-security@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Fri, 06 Jun 2014 00:10:27 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 22:45:30 -0000 I am not sure if this is the right forum, but since these binary updates = via freebsd-update are usually security oriented... I wanted to report that today's latest binary p5 update (June 5, 2014) = does not correctly update the boot line that says 10.0p5. Rather, it = reports p4, even after install p5 and rebooting. It is a nit, but it is = nice to have it correct. After installing p5 this is what I get just = before the login prompt: FreeBSD 10.0-RELEASE-p4 (GENERIC) #0: Tue Jun 3 12:52:18 UTC 2014 If somebody sees this and knows a better list to report this on, could = you please forward it appropriately? Thanks, Dan Allen Building FreeBSD since 2.15 From owner-freebsd-security@FreeBSD.ORG Fri Jun 6 00:27:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E84EBD07 for ; Fri, 6 Jun 2014 00:27:20 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7391F2C2B for ; Fri, 6 Jun 2014 00:27:20 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id mc6so1091900lab.30 for ; Thu, 05 Jun 2014 17:27:18 -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=73ps5vzsmytqwx7+Cs2Jb+ssfCkkPeuuOnxna9O2/LM=; b=LxJO4n5qrOyhJ70nfGBP3d1IexzWTmaDHR4N/sDN0VI2oJaRwFaY8pEwcfcvj0InOx 1TnbaPAd5Rjrhb/udof0y/UR1Fpg2Bm39FPLOe1BxARkx0NXnRDjh+9AVQ0mQHevbRGG EDohR9bfgV2RdD2R+AX1wvyWUJAbJSKg7gU+dMDR3Ljs+EvbiGCj/gojAgaBqpxw9y0G ljNh+eX12WeUrU756zFBxPWyLfMsSQZLkcLdhPfvRdDCwYNrtHImRX73r5yW+5uBccoF ACLaxK5MjTcKT61zxwy16jx7D6xKnuUGljdMywYV8mtiRer+7U9xoOJYnDc8ml5EipUz HGuw== MIME-Version: 1.0 X-Received: by 10.112.162.70 with SMTP id xy6mr814932lbb.40.1402014438358; Thu, 05 Jun 2014 17:27:18 -0700 (PDT) Received: by 10.112.137.202 with HTTP; Thu, 5 Jun 2014 17:27:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jun 2014 17:27:18 -0700 Message-ID: Subject: Re: freebsd-update p5 is labeled p4 From: Dzs Bsd To: Dan Allen Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 00:27:21 -0000 On Thu, Jun 5, 2014 at 3:38 PM, Dan Allen wrote: > I wanted to report that today's latest binary p5 update (June 5, 2014) does not correctly update the boot line that says 10.0p5. Rather, it reports p4, even after install p5 and rebooting. The kernel and userland can have different versions. For FreeBSD 10 and later, use "/bin/freebsd-version" [root@munich ~]# uname -a FreeBSD munich.fx.org 10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun 3 13:14:57 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [root@munich ~]# freebsd-version 10.0-RELEASE-p5 [root@munich ~]# freebsd-version -k 10.0-RELEASE-p4 From owner-freebsd-security@FreeBSD.ORG Fri Jun 6 00:54:12 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA71257D for ; Fri, 6 Jun 2014 00:54:12 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A2812E84 for ; Fri, 6 Jun 2014 00:54:12 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id w8so2558128qac.38 for ; Thu, 05 Jun 2014 17:54:11 -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=EBdEzTM3PJbFjWJLllvUaesNQb6ZnibRyRWWqJqaMh4=; b=JHSRHjaI/ESII7VGg/yhNTj/P5e6reM/bA1rxg60RkFTkamNL5+KgiqiKcejgBLnlZ HCg7Nc4Tf7IS8l3IHxtSj0aW0kh7vEgXnhG+1jRpYPZZRKLvjWkYA5c8Q0rLFqdDRopA WWKUYDOnw6nToRpt7vNcKAE1+FRaBzyCm/iKdN6pvX8YLF56rJLKy+9Pw/3uoON4n1gE B0fcPP85jnIXLc+fKtRhgWCHt0/s/8Ffw23tUjW34yXF8JKiGlRfSnN9d+HSZzxergsF GP2tkD4WfoTZc06XhNFs3uOslQfX8UMCkD5rrxCT/CXMjmgkwokUiaG6DRWhOMAIPf7J 8mOQ== MIME-Version: 1.0 X-Received: by 10.224.51.72 with SMTP id c8mr2230481qag.82.1402016051639; Thu, 05 Jun 2014 17:54:11 -0700 (PDT) Received: by 10.96.70.101 with HTTP; Thu, 5 Jun 2014 17:54:11 -0700 (PDT) Received: by 10.96.70.101 with HTTP; Thu, 5 Jun 2014 17:54:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 Jun 2014 19:54:11 -0500 Message-ID: Subject: Re: freebsd-update p5 is labeled p4 From: Matt Donovan To: Dan Allen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 00:54:13 -0000 Hello, This is a very common question the patch level will not change unless the kernel is updated however the patches are installed. On Jun 5, 2014 7:10 PM, "Dan Allen" wrote: > I am not sure if this is the right forum, but since these binary updates > via freebsd-update are usually security oriented... > > I wanted to report that today's latest binary p5 update (June 5, 2014) > does not correctly update the boot line that says 10.0p5. Rather, it > reports p4, even after install p5 and rebooting. It is a nit, but it is > nice to have it correct. After installing p5 this is what I get just > before the login prompt: > > FreeBSD 10.0-RELEASE-p4 (GENERIC) #0: Tue Jun 3 12:52:18 UTC 2014 > > If somebody sees this and knows a better list to report this on, could you > please forward it appropriately? > > Thanks, > > Dan Allen > Building FreeBSD since 2.15 > > _______________________________________________ > 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 Jun 6 04:34:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0250CB64 for ; Fri, 6 Jun 2014 04:34:10 +0000 (UTC) Received: from mta1.riverwillow.net.au (mta1.riverwillow.net.au [IPv6:2001:8000:1000:1801::36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mta1.riverwillow.net.au", Issuer "Riverwillow Root Certificate 2010-04-12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 515F82184 for ; Fri, 6 Jun 2014 04:34:08 +0000 (UTC) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [IPv6:2001:8000:1000:1801::46]) by mta1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s564Y2Gd088834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jun 2014 14:34:02 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=mta1002; t=1402029242; bh=cUEalJxvgap6kAW7vlaqk6ZiH8wdrXC2LDH8JCJaNac=; h=Date:From:To:Subject:References:In-Reply-To; b=GUqJW0rtjZBox4N93bZakz13Ll8BWqfVuxHTA+MtgbviGO6F7L8mkE/942JnIQto/ zrjQqDzF/Q07FIPE5uFD8fSNla2OVTEop57tn0FzJoMl7VwECM8wOKp4NHIrDvEm7Z Qr2m4oBu/UhmIburlqtHjnI5us/+cEKx5q5Rjh6g= Received: from rwpc15.gfn.riverwillow.net.au (rwpc15.gfn.riverwillow.net.au [IPv6:2001:8000:1000:18e1:20c:76ff:fe0a:2117]) (authenticated bits=56) by mail1.riverwillow.net.au (8.14.9/8.14.9) with ESMTP id s564XxrB088823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jun 2014 14:34:01 +1000 (AEST) Date: Fri, 6 Jun 2014 14:33:59 +1000 From: John Marshall To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl Message-ID: <20140606043359.GF16618@rwpc15.gfn.riverwillow.net.au> Mail-Followup-To: freebsd-security@freebsd.org References: <201406051316.s55DGtwI041948@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n+lFg1Zro7sl44OB" Content-Disposition: inline In-Reply-To: <201406051316.s55DGtwI041948@freefall.freebsd.org> OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 04:34:10 -0000 --n+lFg1Zro7sl44OB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 05 Jun 2014, 13:16 +0000, FreeBSD Security Advisories wrote: > Corrected: > 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) > VI. Correction details > Branch/path Revision > ------------------------------------------------------------------------- > releng/9.2/ r267104 I've just src-upgraded a system and expected to see OpenSSL version 0.9.8za at the end of it all. I checked the patches and the OpenSSL version number wasn't touched. Is this an expected outcome? rwsrv04> uname -v; openssl version FreeBSD 9.2-RELEASE-p8 #0 r267130: Fri Jun 6 12:43:09 AEST 2014... OpenSSL 0.9.8y 5 Feb 2013 rwsrv04> ls -l /usr/lib/libssl.so.6 -r--r--r-- 1 root wheel 304808 6 Jun 13:31 /usr/lib/libssl.so.6 I understand that it was the FreeBSD distribution that was patched and not the OpenSSL distribution, but having the operating system and applications reporting a "vulnerable" version of OpenSSL isn't reassuring to other folks. --=20 John Marshall --n+lFg1Zro7sl44OB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlORRLcACgkQw/tAaKKahKIhewCgsmZjvSAB8Irz7zySOuanv3Sc xFEAn0h+TQ5hmLldOcVtHmoV6A0buPup =+7zl -----END PGP SIGNATURE----- --n+lFg1Zro7sl44OB-- From owner-freebsd-security@FreeBSD.ORG Sun Jun 8 13:14:50 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9409FDD for ; Sun, 8 Jun 2014 13:14:50 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 570C72446 for ; Sun, 8 Jun 2014 13:14:50 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id EBB313592EC for ; Sun, 8 Jun 2014 15:14:46 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id CDF1D28497; Sun, 8 Jun 2014 15:14:46 +0200 (CEST) Date: Sun, 8 Jun 2014 15:14:46 +0200 From: Jilles Tjoelker To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl Message-ID: <20140608131446.GA4706@stack.nl> References: <201406051316.s55DGtwI041948@freefall.freebsd.org> <20140606043359.GF16618@rwpc15.gfn.riverwillow.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140606043359.GF16618@rwpc15.gfn.riverwillow.net.au> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 13:14:50 -0000 On Fri, Jun 06, 2014 at 02:33:59PM +1000, John Marshall wrote: > On Thu, 05 Jun 2014, 13:16 +0000, FreeBSD Security Advisories wrote: > > Corrected: > > 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) > > VI. Correction details > > Branch/path Revision > > ------------------------------------------------------------------------- > > releng/9.2/ r267104 > I've just src-upgraded a system and expected to see OpenSSL version > 0.9.8za at the end of it all. I checked the patches and the OpenSSL > version number wasn't touched. Is this an expected outcome? > rwsrv04> uname -v; openssl version > FreeBSD 9.2-RELEASE-p8 #0 r267130: Fri Jun 6 12:43:09 AEST 2014... > OpenSSL 0.9.8y 5 Feb 2013 > rwsrv04> ls -l /usr/lib/libssl.so.6 > -r--r--r-- 1 root wheel 304808 6 Jun 13:31 /usr/lib/libssl.so.6 > I understand that it was the FreeBSD distribution that was patched and > not the OpenSSL distribution, but having the operating system and > applications reporting a "vulnerable" version of OpenSSL isn't > reassuring to other folks. Yes, this is expected and common practice. Perhaps the version number should instead be removed in head given that it is not updated for security patches anyway. -- Jilles Tjoelker From owner-freebsd-security@FreeBSD.ORG Mon Jun 9 13:18:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0624DD8 for ; Mon, 9 Jun 2014 13:18:30 +0000 (UTC) Received: from fmailhost04.isp.att.net (fmailhost04.isp.att.net [207.115.11.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC949238C for ; Mon, 9 Jun 2014 13:18:30 +0000 (UTC) Received: from ace.nina.org (adsl-74-178-49-3.gnv.bellsouth.net[74.178.49.3]) by isp.att.net (frfwmhc04) with SMTP id <20140609131316H0400nnbm7e>; Mon, 9 Jun 2014 13:13:17 +0000 X-Originating-IP: [74.178.49.3] Date: Mon, 9 Jun 2014 09:13:15 -0400 (EDT) From: Frank Seltzer X-X-Sender: frank_s@Ace.nina.org To: freebsd-security@freebsd.org Subject: Re: r356789 breaks rkhunter (fwd) Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 09 Jun 2014 18:14:49 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 13:18:31 -0000 Adding -security to list. ---------- Forwarded message ---------- Date: Mon, 9 Jun 2014 08:00:25 -0400 (EDT) From: Frank Seltzer To: freebsd-ports@freebsd.org Subject: Re: r356789 breaks rkhunter On Sun, 8 Jun 2014, Frank Seltzer wrote: > I just upgraded rkhunter and the installer splatted the sample file over my > .conf file. > > Running 'rkhunter --propupd' now quits with the error message > > The SCRIPTDIR configuration option has not been set by the installer. > > This option is now commented out in the .conf and .conf.sample file. > > # > # This option specifies the script directory to use. > # > # The installer program will set the default directory. If this default is > # subsequently commented out or removed, then the program will not run. > # > #SCRIPTDIR=/usr/local/lib/rkhunter/scripts > > This the correct directory where the scripts are installed. > > Uncommenting this and re-running the command now quits with this error > message: > > Invalid INSTALLDIR configuration option - no installation directory > specified. > > I have searched around and have not found a file containing this option. > > Help, please. > > Frank Some additional info. I ran rkhunter -C on the default .conf file. -C Check the configuration file(s), then exit The SCRIPTDIR configuration option has not been set by the installer. Invalid INSTALLDIR configuration option - no installation directory specified. The default temporary directory will be used: /lib/rkhunter/tmp Temporary directory does not exist: /lib/rkhunter/tmp The default database directory will be used: /lib/rkhunter/db Database directory does not exist: /lib/rkhunter/db The internationalisation directory does not exist: /lib/rkhunter/db/i18n Invalid SCRIPTWHITELIST configuration option: Non-existent pathname: /usr/local/bin/GET Frank _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Mon Jun 9 20:07:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4CE6D74 for ; Mon, 9 Jun 2014 20:07:26 +0000 (UTC) Received: from st11p09mm-asmtp001.mac.com (st11p09mm-asmtp001.mac.com [17.164.24.96]) by mx1.freebsd.org (Postfix) with ESMTP id A889F2D1C for ; Mon, 9 Jun 2014 20:07:26 +0000 (UTC) MIME-version: 1.0 Received: from beat.rdnzl.info (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N6X0011113B0D20@st11p09mm-asmtp001.mac.com> for freebsd-security@freebsd.org; Mon, 09 Jun 2014 19:06:50 +0000 (GMT) Content-type: multipart/signed; boundary="Apple-Mail=_11668CD3-D231-46B0-86DE-1577F6CC0D88"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: FreeBSD Security Advisory FreeBSD-SA-14:14.openssl From: Kimmo Paasiala In-reply-to: <20140608131446.GA4706@stack.nl> Date: Mon, 09 Jun 2014 22:06:26 +0300 Message-id: <34FF30E8-E9F1-4691-B6EE-9E4E5DDA0AC7@icloud.com> References: <201406051316.s55DGtwI041948@freefall.freebsd.org> <20140606043359.GF16618@rwpc15.gfn.riverwillow.net.au> <20140608131446.GA4706@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1878.2) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGREKTEMXGx0EGx0YBBIZBBsdEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hjeREKQ04XSxsYGmJCH2lvHXV4GXhzB x8TGxMaHEUZEQpYXBcZBBoEGxsHTU4fGBgYGUsFGx0EGx0YBBIZBBsdEBseGh8bEQpeWRdhUxx aRhEKTEYXYmtrEQpDWhcSEgQbEx8EGxgSBBkZEQpCXhcbEQpEWBcYEQpESRcbEQpCRRdmfX8TT W9cYGUaEhEKQk4Xa0UaUlAeQ1xZXGgRCkJMF25NHXlZY2RofhhGEQpCbBdhQHxTbEsfGGR7fhE KQkAXYxh5HkNiGhtvSFgRCnBoF2RyZGZHeX1CGB14EQpwaBduQHxlQ1tTXXJFehEKcGgXYn9JG h5bS2kZaW8RCnBoF2FDXlh9emd7E0BcEQpwaBd6Umdga0ZcEnhNQhEKcGsXbkl5X1pYck0ZHFg RCnBLF2JpchNYXVxnbVNzEQpwaxdnbH9ZGGEYQUxhcBEKcGwXbWduBR9hTmEcWxsRCnBMF2NDZ XtzQEUFbUdbEQ== X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-06-09_03:2014-06-09,2014-06-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406090242 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 20:07:27 -0000 --Apple-Mail=_11668CD3-D231-46B0-86DE-1577F6CC0D88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 8.6.2014, at 16.14, Jilles Tjoelker wrote: > On Fri, Jun 06, 2014 at 02:33:59PM +1000, John Marshall wrote: >> On Thu, 05 Jun 2014, 13:16 +0000, FreeBSD Security Advisories wrote: >=20 >>> Corrected: >=20 >>> 2014-06-05 12:33:23 UTC (releng/9.2, 9.2-RELEASE-p8) >=20 >>> VI. Correction details >=20 >>> Branch/path = Revision >>> = ------------------------------------------------------------------------- >=20 >>> releng/9.2/ = r267104 >=20 >> I've just src-upgraded a system and expected to see OpenSSL version >> 0.9.8za at the end of it all. I checked the patches and the OpenSSL >> version number wasn't touched. Is this an expected outcome? >=20 >> rwsrv04> uname -v; openssl version >> FreeBSD 9.2-RELEASE-p8 #0 r267130: Fri Jun 6 12:43:09 AEST 2014... >> OpenSSL 0.9.8y 5 Feb 2013 >=20 >> rwsrv04> ls -l /usr/lib/libssl.so.6 >> -r--r--r-- 1 root wheel 304808 6 Jun 13:31 /usr/lib/libssl.so.6 >=20 >> I understand that it was the FreeBSD distribution that was patched = and >> not the OpenSSL distribution, but having the operating system and >> applications reporting a "vulnerable" version of OpenSSL isn't >> reassuring to other folks. >=20 > Yes, this is expected and common practice. >=20 > Perhaps the version number should instead be removed in head given = that > it is not updated for security patches anyway. >=20 > --=20 > Jilles Tjoelker I strongly disagree. There has to be a version number so that no one has = to guess what is base version of the software used. Instead I=92d look = into incorporating the patch level information that is now in =91uname = -r=92 (for example '10.0-RELEASE-p5=92) to various version strings in = the world binaries. -Kimmo --Apple-Mail=_11668CD3-D231-46B0-86DE-1577F6CC0D88 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTlgW2AAoJEFvLZC0FWRVpRX4H/2GnIfRfgLo8ybHKFzsD9VIt 5x0AxLOvIOCytSaOHDBSipgTNEL0dt37z3nD48WQzKoigFc/dnBo6Tf71cDO0Nss riQVELPtkk9nAqEj3I+9T9ljKzYhglH5Ni0Nhxw9NgA3wdYSt5IEuRZXXXRq7WGY CaQ4oGmDY2/Mpabq1n1PeHWt2JcP4Ca+Dqcc060qrncNxnAPljEg4kiG68n9JRlz XwGcP2o8fhtmzDlhx0lEfZCxz/5I9JwojGeYJVl/9C5IN9seMWSsnm/YUEyQXs3S QsB7EZTedF3Oc1z3zxbEkeDZBDKzk7xLfP19DDMxdtqedxmL0sv6kHORMWjM50Y= =5+CS -----END PGP SIGNATURE----- --Apple-Mail=_11668CD3-D231-46B0-86DE-1577F6CC0D88-- From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 09:32:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 380FE252 for ; Wed, 11 Jun 2014 09:32:55 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F17992132 for ; Wed, 11 Jun 2014 09:32:54 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id c9so4148207qcz.0 for ; Wed, 11 Jun 2014 02:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=G9NfCVL7SGlI6oKKNOADi2qE5G8FscQjfXxzJGa75/4=; b=i9hLmLXVrdj6pr/Q4itqykbMwPQpbHv3v4DkUMT7hr2QaRsA+emmMhPcSkDXQR08cr gOe91fKI3AJ5t37BUbIe5VDWWuDySaJ5NVwuaObq0TCySazlNtlKAxMZXETFcTExz9z+ EisqhrPT9Diifa27Ye6jJBOVaYLbNTCYoUtLRPM1Mrvdg3o8bdmhahi0u2VasFROZLmo sUMq8oXuSVN5S4xeOrWNE4KY3hBe22S61Wn2CmseTKV9C8oqSYUVOOF4p+D+PiYlqiO7 4sJ9WyLKBW/PDz8TquZbF734BAr6MPrRj3CoQtlWIWMdkfNLHctjRIMo3EB1ktxvHn35 J18Q== MIME-Version: 1.0 X-Received: by 10.224.95.9 with SMTP id b9mr50946701qan.11.1402479174140; Wed, 11 Jun 2014 02:32:54 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.222.168 with HTTP; Wed, 11 Jun 2014 02:32:54 -0700 (PDT) Date: Wed, 11 Jun 2014 10:32:54 +0100 X-Google-Sender-Auth: C4e2DPNvQQl9LtnmupTEronRbQk Message-ID: Subject: OpenSSL end of life From: Ben Laurie To: "freebsd-security@freebsd.org security" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 11 Jun 2014 11:37:05 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 09:32:55 -0000 We (the OpenSSL team) are considering a more aggressive EOL strategy. In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes out (currently in beta). Going forward we would only maintain two versions, so when 1.0.3 comes out, 1.0.1 would be EOL. What do people think about this? From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 12:14:49 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 868BE2A8 for ; Wed, 11 Jun 2014 12:14:49 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B8BC2FEE for ; Wed, 11 Jun 2014 12:14:48 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s5BCEbOn050036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 11 Jun 2014 14:14:45 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <5398482C.7020406@obluda.cz> Date: Wed, 11 Jun 2014 14:14:36 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ben Laurie Subject: Re: OpenSSL end of life References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 12:14:49 -0000 On 06/11/14 11:32, Ben Laurie: > Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL. So, the date of EOL of 1.0.1 will not be known. Just some day the 1.0.3 will be released and 1.0.1 become damned. Also, I consider its not so friendly to projects using the OpenSSL. Some of them wish to declare lifetime of particular version at the time of release. It will be possible no longer as embedded OpenSSL may become obsolete at any time. What about ongoing FreeBSD 9.3 release ? According tradition, it's EOL should occur two years past release. But what we will do if embedded version of OpenSSL become unsupported just this winter ? I need to make long term upgrade plans. Not happy with "as OpenSSL declared EOL, your version of FreeBSD has been EOLed as well. Upgrade NOW (or within two weeks - it's no substantial difference for me)" Just my $0.02 ... Dan From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 13:29:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 99D33681 for ; Wed, 11 Jun 2014 13:29:41 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 142DE275F for ; Wed, 11 Jun 2014 13:29:40 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s5BDTW60057784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 11 Jun 2014 15:29:38 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <539859BC.2050303@obluda.cz> Date: Wed, 11 Jun 2014 15:29:32 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ben Laurie Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 13:29:41 -0000 On 06/11/14 15:00, Ben Laurie: >> Some of them wish to declare lifetime of particular version at the time of >> release. It will be possible no longer as embedded OpenSSL may become >> obsolete at any time. > > This is already true, because of bugs. And, in practice, no version of > OpenSSL (or anything else, pretty much) has a lifetime such that you > can safely make a non-upgradeable product from it. Don't mix security patch and upgrade. With security patch the ABI doesn't change. So I can just replace the compiled library by the new one patched and restart the daemon (or system). With new version, the same approach is not possible. All application needs to be recompiled. And if API become changed as well, then all applications needs to be reevaluated at the source level - and modified, if necessary according API changes. We can't just blindly compile old sources against new OpenSSL wishing for security, isn't it ? Even if the source will compile against new API, it doesn't mean it will work as expected - and - it's still secure. > Alternatively, can 9.3 not upgrade to a newer OpenSSL? Upgraded ? Yes, but upgraded to another version than 9.3 9.3 can be patched during it's lifetime, but 9.3-pX and 9.3-pY needs to be binary compatible. If it is not compatible, then it's no 9.3 anymore. > One modification I'd be prepared to contemplate is that 1.0.1 (for > example) is supported for some known period of time, even if it should > be EOL according to the versioning scheme. The question is: how long? > Sounds like you'd want 2 years. Almost acceptable for me. I wish to save 2year lifetime period for FreeBSD. It take some time the release will be prepared for release. The (possible) new version of OpenSSL needs to be imported, all code that use them needs to be re-evaluated because of possible API changes, the resulting system needs to be tested. It take months. Check release process of any FreeBSD ... If you will declare 2year minimal lifetime for OpenSSL, it will be hard to reach even 1year lifetime for FreeBSD ... So I'm wishing for something about 3 years from OpenSSL ... Be sure I understand that any version supported require resources. I'm not picking numbers randomly just because it's simple to write a number here ... Dan From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 13:00:53 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 392D67A2 for ; Wed, 11 Jun 2014 13:00:53 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF5C22464 for ; Wed, 11 Jun 2014 13:00:52 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id c9so4448476qcz.28 for ; Wed, 11 Jun 2014 06:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Aj3AKs8QbrZsnY4wCNF/tT7vGQ9uqRK/zQ710eNvo1w=; b=zoLEaBjznciHyCpeKfpbJuy/5cSjqKrLRUsfsWgJQZsEPRZlIQIzjkEtzEDPLjt4WA CZ/72sK9UJ9fMyqyJJfqTh92j2fAUQnXbCVlKOuP1BIOcUmX32yfH14eU8G8Vh0F7mRA JslbeUJ0j45SQOgJCNJ8InXWHWoc2QYyYB2glNfWkwuj4GUicYUQ3kQtCHAsSN3zvTYR N6gmfQlV99F16vrs4Z+sN38UxrLr9twfSYvm3ruyR4jGWiBcFN9rqR1ha1Yb28fHGhKI T3GcxSzAGQ96j2ujcHcubNoBUUcyNgenGKhgFSiKICez22a+5QroVq26EtooqSfsHfHX dnDw== MIME-Version: 1.0 X-Received: by 10.224.0.70 with SMTP id 6mr22893308qaa.100.1402491651945; Wed, 11 Jun 2014 06:00:51 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.222.168 with HTTP; Wed, 11 Jun 2014 06:00:51 -0700 (PDT) In-Reply-To: <5398482C.7020406@obluda.cz> References: <5398482C.7020406@obluda.cz> Date: Wed, 11 Jun 2014 14:00:51 +0100 X-Google-Sender-Auth: 3OaNVM-pr7fJNGDqUXAA-zRL34g Message-ID: Subject: Re: OpenSSL end of life From: Ben Laurie To: Dan Lukes Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 11 Jun 2014 13:43:20 +0000 Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 13:00:53 -0000 On 11 June 2014 13:14, Dan Lukes wrote: > On 06/11/14 11:32, Ben Laurie: > >> Going forward we would only maintain two versions, so when 1.0.3 comes >> out, 1.0.1 would be EOL. > > > So, the date of EOL of 1.0.1 will not be known. Just some day the 1.0.3 will > be released and 1.0.1 become damned. It won't be a huge surprise, because we always have a series of betas. > Also, I consider its not so friendly to projects using the OpenSSL. > > Some of them wish to declare lifetime of particular version at the time of > release. It will be possible no longer as embedded OpenSSL may become > obsolete at any time. This is already true, because of bugs. And, in practice, no version of OpenSSL (or anything else, pretty much) has a lifetime such that you can safely make a non-upgradeable product from it. In other words, the idea that you can pre-declare a lifetime is fantasy. > What about ongoing FreeBSD 9.3 release ? According tradition, it's EOL > should occur two years past release. But what we will do if embedded version > of OpenSSL become unsupported just this winter ? I don't know - for a start, just because the OpenSSL team don't support it, that doesn't mean others can't backport fixes. Alternatively, can 9.3 not upgrade to a newer OpenSSL? > I need to make long term upgrade plans. Not happy with "as OpenSSL declared > EOL, your version of FreeBSD has been EOLed as well. Upgrade NOW (or within > two weeks - it's no substantial difference for me)" One modification I'd be prepared to contemplate is that 1.0.1 (for example) is supported for some known period of time, even if it should be EOL according to the versioning scheme. The question is: how long? Sounds like you'd want 2 years. According to that scheme, 1.0.1 was eligible for EOL in March 2014. > > > Just my $0.02 ... > > Dan > From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 13:56:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36FD33F3 for ; Wed, 11 Jun 2014 13:56:57 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC2EA2A65 for ; Wed, 11 Jun 2014 13:56:56 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s5BDupul062008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 11 Jun 2014 15:56:54 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <53986023.7050203@obluda.cz> Date: Wed, 11 Jun 2014 15:56:51 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ben Laurie Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 13:56:57 -0000 On 06/11/14 15:00, Ben Laurie: >> What about ongoing FreeBSD 9.3 release ? According tradition, it's EOL >> should occur two years past release. But what we will do if embedded version >> of OpenSSL become unsupported just this winter ? > > I don't know - for a start, just because the OpenSSL team don't > support it, that doesn't mean others can't backport fixes. Sorry, I missed this. Yes, it's solution as well. I'm familiar with it. I'm backporting newest FreeBSD's SA and EN into FreeBSD 8.3-R despite it's declared EOL. But such approach has big "marketing" drawback. If there are published announcements like OpenSSL version a.b.c is obsolete, unsupported, unsafe and dangerous, then it's hard to offer a system based on it, despite promises that YOURS particular incarnation of openssl a.b.c is patched and safe. But yes, it's solution. Dan From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 14:00:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFC08611 for ; Wed, 11 Jun 2014 14:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBDD92AB3; Wed, 11 Jun 2014 14:00:01 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5BDxxCJ057701; Wed, 11 Jun 2014 14:00:00 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <539860DE.9080609@FreeBSD.org> Date: Wed, 11 Jun 2014 11:29:58 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dan Lukes Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> <539859BC.2050303@obluda.cz> In-Reply-To: <539859BC.2050303@obluda.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security , Ben Laurie X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 14:00:02 -0000 Dan Lukes wrote: > 9.3 can be patched during it's lifetime, but 9.3-pX and 9.3-pY needs to be binary compatible. > > If it is not compatible, then it's no 9.3 anymore. > >> One modification I'd be prepared to contemplate is that 1.0.1 (for >> example) is supported for some known period of time, even if it should >> be EOL according to the versioning scheme. The question is: how long? >> Sounds like you'd want 2 years. > > Almost acceptable for me. > > I wish to save 2year lifetime period for FreeBSD. Once we officially move to the 5-year branch lifetime, even a 2-year OpenSSL lifetime becomes problematic. It seems to me that the only solution is to remove the ABI promise on OpenSSL: move the base system's libcrypt.so into /usr/lib/private. Installed packages would have to depend on (up-to-date) OpenSSL from the ports tree, where 2 years might be long enough to do the EOL dance. The problem with this approach is that pkg itself is a package and it needs to verify signatures to bootstrap itself before installing any OpenSSL package. Perhaps we can come up with a minimal API (ideally one function) whose ABI we can continue to support even as we change libcrypt versions under the hood. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 15:14:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FF792FD for ; Wed, 11 Jun 2014 15:14:25 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A403C2304 for ; Wed, 11 Jun 2014 15:14:24 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s5BFEGeM077608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Wed, 11 Jun 2014 17:14:22 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <53987248.5050103@obluda.cz> Date: Wed, 11 Jun 2014 17:14:16 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: freebsd-security Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> <539859BC.2050303@obluda.cz> <539860DE.9080609@FreeBSD.org> In-Reply-To: <539860DE.9080609@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 15:14:25 -0000 On 06/11/14 15:59, Jonathan Anderson: > Once we officially move to the 5-year branch lifetime 5-year ? In such case, the content of /usr/src/contrib needs to be reevaluated very carefully. The OpenSSL is not only external library here ... > It seems to me that the only solution is to remove the ABI promise on OpenSSL: move the base system's libcrypt.so into /usr/lib/private. You are proposing to change meaning of words "patch" and "upgrade". Sure, if we will call some upgrades as patches, then version number needs not to be bumped, so we can reach the 5-year lifetime magically. But it's just magic with the words. I prefer different approach. If we can't maintain 5-year lifetime, then we can't declare it just by tricks. OK, I have no problem with such kind of black magic. As long as I know the meaning of the words, I can understand the sentences. I will translate "5-year lifetime" label to something I will understand. Note - English is not my native language. The text above is not offense in any way. It explained how I understood the solution your mentioned. Despite I don't prefer this kind of solution, I can live with it if necessary. I prefer other solution mentioned in the thread. We need to support particular version of OpenSSL by self during lifetime of particular release. Despite of such self-support, I would like to recommend that OpenSSL releases have a lifetime declared at it's release time. It may be extended (by known amount of time) before expired if there will be no never release ready. Dan From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 16:45:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D44E563 for ; Wed, 11 Jun 2014 16:45:23 +0000 (UTC) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 242292B50 for ; Wed, 11 Jun 2014 16:45:23 +0000 (UTC) Received: by mail-yk0-f170.google.com with SMTP id q9so2238ykb.29 for ; Wed, 11 Jun 2014 09:45: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 :cc:content-type; bh=q0dxEMGQ7MEV4AsQs4tunYnOlR3LLwTYuCkgmO81dqU=; b=aGjJ2VysaOAfpGzFWkZUAe3CPk3Hx46d7BB14CSNM+pa5b6S4KyEfh+t2jI6Ir9Qih 6RLNGlbAKs0LiuTdmEQ0aOry6XSMXG7aNm2cbw0PBhMU4LTI5WvhDjIxrO6vFSvRM8U+ /h+IyqujeQhOEKolRBMgkvG5NZQw05m7omEiVX36D5iQyTqaqpiiHLPIqLUVbJFD3P/M CMuPSsCFDTqbaoehBa0bUPHsJs5Fd+GiZcQoPRt2E3R6BtWzWe1ChbPksjDT2YTTN5KI sF59ZPLjfqVrquiREoTZJg4FVnz8sGMn19/QLAqdR0nOVIYiEGiwC2qpeSGlN/KwS/DH zkNA== MIME-Version: 1.0 X-Received: by 10.236.129.43 with SMTP id g31mr7217756yhi.86.1402505122362; Wed, 11 Jun 2014 09:45:22 -0700 (PDT) Received: by 10.170.151.137 with HTTP; Wed, 11 Jun 2014 09:45:22 -0700 (PDT) In-Reply-To: <5398482C.7020406@obluda.cz> References: <5398482C.7020406@obluda.cz> Date: Wed, 11 Jun 2014 09:45:22 -0700 Message-ID: Subject: Re: OpenSSL end of life From: =?UTF-8?Q?Istv=C3=A1n?= To: Dan Lukes Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security , Ben Laurie X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 16:45:23 -0000 First I have read "OpenSSL end of life" and I started to get happy that this project goes away... :) From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 16:49:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD7B87DE for ; Wed, 11 Jun 2014 16:49:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B03552BA0; Wed, 11 Jun 2014 16:49:54 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5BGnrQa014445; Wed, 11 Jun 2014 16:49:54 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <539888B0.9090108@FreeBSD.org> Date: Wed, 11 Jun 2014 14:19:52 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dan Lukes Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> <539859BC.2050303@obluda.cz> <539860DE.9080609@FreeBSD.org> <53987248.5050103@obluda.cz> In-Reply-To: <53987248.5050103@obluda.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 16:49:54 -0000 Dan Lukes wrote: > In such case, the content of /usr/src/contrib needs to be reevaluated > very carefully. The OpenSSL is not only external library here ... OpenSSL is a bit special, though. The ABI for, e.g., jemalloc isn't likely to change very much upstream, nor are we likely to break it for security updates. If our version of OpenSSL goes EOL, however, that's very much a security concern. >> It seems to me that the only solution is to remove the ABI promise on >> OpenSSL: move the base system's libcrypt.so into /usr/lib/private. > > You are proposing to change meaning of words "patch" and "upgrade". > Sure, if we will call some upgrades as patches, then version number > needs not to be bumped > > But it's just magic with the words It's not just wordsmithing: right now, we promise not to break the x/stable ABI as long as there are x.y releases. That ABI includes things that, realistically, we aren't in a position to maintain. I propose that we be a bit more careful about the libraries that we're willing to commit to an ABI on, restricting ourselves to things that we are able to maintain internally as a project or where upstream changes don't break the ABI (e.g. an executable where the interface is the command line, so all we have to do is preserve existing arguments). > Note - English is not my native language. The text above is not offense > in any way. It explained how I understood the solution your mentioned. Perhaps I didn't explain myself very well: I hope my proposal is clearer now. > I prefer other solution mentioned in the thread. We need to support > particular version of OpenSSL by self during lifetime of particular > release. Sure, we could do point patches of old OpenSSL versions as vulnerabilities are discovered, but who's to say that we'll hear about them if the upstream vendor has stopped doing security advisories? If everybody else has moved on from 0.9.8, who in the FreeBSD project is willing to take ownership of such a large and complex code base? Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 18:11:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81C3B298 for ; Wed, 11 Jun 2014 18:11:10 +0000 (UTC) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5817723D8 for ; Wed, 11 Jun 2014 18:11:09 +0000 (UTC) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 0A.33.30831.DBB98935; Wed, 11 Jun 2014 11:11:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N7000DC2NUCJSE1@local.mail-out.apple.com> for freebsd-security@freebsd.org; Wed, 11 Jun 2014 11:11:09 -0700 (PDT) X-AuditID: 11973e16-f792a6d00000786f-81-53989bbd3800 Received: from [17.149.227.5] (Unknown_Domain [17.149.227.5]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 1C.AC.11638.EBB98935; Wed, 11 Jun 2014 11:11:10 -0700 (PDT) Subject: Re: OpenSSL end of life From: Charles Swiger In-reply-to: Date: Wed, 11 Jun 2014 11:11:09 -0700 Message-id: <9EE1267B-E571-4B5A-B59B-F87062DCB53E@mac.com> References: To: Ben Laurie X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUiON3OUHfv7BnBBnv6VSx6Nj1hc2D0mPFp PksAYxSXTUpqTmZZapG+XQJXRvO5bawFK7krJkz+x9TA2MvZxcjJISFgIjHp+SomCFtM4sK9 9WxdjFwcQgIzmSQetL9jBEnwCghK/Jh8j6WLkYODWUBe4uB5WZAws4CWxPdHrSwQ9UuYJM4f nsYEM/TarZmsILaQQDeTxJUXwiC9wgIKEkduK4OYbAJqEhMm8oBUcAoES7z+2cwCYrMIqEr8 +7iTFWK8l8SjxxOhLrCSWHu7jRFiYoDEqcYnYDUiAnISv29/YYHYKitx+txzsHMkBL6zSszb 9oV5AqPwLCQfzEL4YBaSDxYwMq9iFMpNzMzRzcwz10ssKMhJ1UvOz93ECAlgsR2MD1dZHWIU 4GBU4uFlqJ0RLMSaWFZcmXuIUZqDRUmcV33G9GAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jJU/Nwd+LH12T+SblawZw9zG8lqTXw9eTOXddfyj7hUXvftXY5jXsm2eccnzu/skztr4Uyse H+PQ2RA7U16zx984mVX6flLOjT9Tnk6q9zyTPceTea6H5nWTm6sLH3YfPHT/772tXlVabq1G ws1Gs+f+WO+yaWKhpE1W+lrWy5/XbjFybDf9babEUpyRaKjFXFScCACgmSHEQQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUiOPUxq+6+2TOCDU495bRYNJvTomfTEzYH Jo8Zn+azeGxumsMWwBTFZZOSmpNZllqkb5fAlXFl1UHmgsPcFYfPtrM2MM7n7GLk5JAQMJG4 dmsmK4QtJnHh3nq2LkYuDiGBbiaJ5o132EESzAJaEjf+vWTqYuTg4BXQk9j+Sw7EFBZQkDhy WxnEZBNQk5gwkQekmFMgUGLz7ENsIDaLgKrEv487WSGGeEk8ejyREcLWlli28DUziM0rYCXR dvUzmC0kECBxqvEJWL2IgJzE79tfWCAuk5U4fe45ywRG/llI7pmFcM8sJFMXMDKvYhQoSs1J rLTQSywoyEnVS87P3cQICrWGwrQdjE3LrQ4xCnAwKvHwMtTOCBZiTSwrrsw9xCjBwawkwhvR DBTiTUmsrEotyo8vKs1JLT7EKM3BoiTO+2n69GAhgfTEktTs1NSC1CKYLBMHp1QDo3LqdN5b c9Z82NJy9P9nw7DjJh+TTBfc/uCx6IFjfcD66NvHO29v28TjzJGkrOn0qDngwUlVUzOheqcf Ae/fHXQ9XPf74j33ue8PTK2+/Ctjnf8up6Vzri80u8e8vle82cn8zSl74eaahcqvv5hXVe3Z fX8Pg0lDHkefxstjSesfbbW/dmbhmcdKLMUZiYZazEXFiQBzAJ0bMQIAAA== Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 18:11:10 -0000 Hi, Ben-- Thanks for soliciting feedback. On Jun 11, 2014, at 2:32 AM, Ben Laurie wrote: > We (the OpenSSL team) are considering a more aggressive EOL strategy. > > In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes > out (currently in beta). > > Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL. > > What do people think about this? Most folks use the OpenSSL version provided by their OS vendor. OS vendors want to provide long-term support for at least some releases, because many users don't want to chase major version bumps too frequently. (This has strong implications towards ABI stability: even if you EOL 0.9.8 today, vendors will still need to support that for years down the road.) Some advanced users will be more willing to build, deploy, and validate "bleeding edge" versions. Other advanced users are using an OpenSSL version which is baked into the firmware of hardware load-balancers like F5's BIG-IP, Citrix Netscalers, Brocade's ADX, etc. The other group that comes to mind is software developers writing against OpenSSL. I don't want to generalize too far, but even fairly well-known projects like ClamAV who actively use SSL and check cert signing for their virus DB updates are just now starting to implement OpenSSL-0.9.8 functionality like CRL checks _after_ Heartbleed. Regards, -- -Chuck From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 20:38:01 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9078B273 for ; Wed, 11 Jun 2014 20:38:01 +0000 (UTC) Received: from mail.rootservice.org (devgate.rootservice.org [144.76.199.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F33CC2348 for ; Wed, 11 Jun 2014 20:37:59 +0000 (UTC) Received: from devnoip.rootservice.org (devnoip.rootservice.org [84.46.21.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rootservice.org (Postfix) with ESMTPSA id 3gpfx51H6bzdG3g for ; Wed, 11 Jun 2014 22:31:20 +0200 (CEST) Date: Wed, 11 Jun 2014 22:31:18 +0200 From: Joe User Reply-To: joeuser@rootservice.org Organization: RootService MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> <53986023.7050203@obluda.cz> In-Reply-To: <53986023.7050203@obluda.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-Id: <3gpfx36R85z62Yx@devnoip.rootservice.org> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 20:38:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11.06.2014 15:56, Dan Lukes wrote: > On 06/11/14 15:00, Ben Laurie: >>> What about ongoing FreeBSD 9.3 release ? According tradition, >>> it's EOL should occur two years past release. But what we will >>> do if embedded version of OpenSSL become unsupported just this >>> winter ? >> >> I don't know - for a start, just because the OpenSSL team don't >> support it, that doesn't mean others can't backport fixes. > > Sorry, I missed this. Yes, it's solution as well. > > I'm familiar with it. I'm backporting newest FreeBSD's SA and EN > into FreeBSD 8.3-R despite it's declared EOL. > > But such approach has big "marketing" drawback. If there are > published announcements like OpenSSL version a.b.c is obsolete, > unsupported, unsafe and dangerous, then it's hard to offer a system > based on it, despite promises that YOURS particular incarnation of > openssl a.b.c is patched and safe. How many libs/binaries in contrib (and even in the rest of base) of 9.x are eol or unsupported or whatever by their upstreams? So why should openssl not be one them? Take the outdated/unsupported/eol/whatever versions of openssh or zfs shipping with 9.x, which could lead to unsecure logins or dataloss/corruption because they are "eol"... If you're a vendor using freebsd (or any software in general) then you have to continously (sp?) follow the respective upstream and regularly ship updates/upgrades to your products/customers. If this means that you've to upgrade from 9.x to 10.x then do it now and not when it's too late. Nothing bothers me as an user more, than vendors not doing their work to deliver updates and upgrades asap. Even embedded devices can be upgraded, so don't try this argument. And even if that's realy not possible, then that device has to be replaced completly. Sorry, but i heard/read this kind of discussion since two decades now and nothing changed. That "Never change a running system" thing has always been wrong and today it's the worstest case of all. So, don't care about "marketing drawbacks", just do your job and provide up-to-date products and updates/upgrades. Release/Update early and often, not (too) late and fewer/never... FreeBSD is a rolling release, so the "relaeses" are in reality only simple snapshots of the codebase, not more and not less. Some parts roll faster than light while others need decades per bit. OK enough off-topic. I'm fine with two years (IMHO one year would be even better, aren't we in the post-Snowden era where crypto will be reinvented fast?) - -- Kind Regards, Mit freundlichen GrĆ¼ssen, Markus Kohlmeyer Markus Kohlmeyer PGP: 0xEBDF5E55 / 2A22 1F71 AA70 1AD1 231B 0178 759F 407C EBDF 5E55 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTmLySAAoJEHWfQHzr315V+MkQAKAU2vRaild/cWTObBZIgTGX uL5gyYn/9ICUDkPLyIxR8tTAb2sVNWfveO5X6FIiZCXqlld4fZ6SdhIDj83EW14B 38Wqei72G9OkbvH9/UVRf66Puy1UmCHeDcLz+GquLBbGe6POLDzWIEOKDiVGzr6z j5WwjD6FEa3ncsjtNIHsEqgdB3sJ0I1kmBFs1hQR2OPQDUow9R9hvF1WFoUpovtI cYCOYvUnZgCCChxdlL9SbXhR3vAdsnoQTuVbj1uipI1WAloUjXXm/eVRq6ukaIPm UwlUqfgo1Do134KbVmCZW1wrRd0i3ME/ZwVKXXT3s71iGMTezoY3Zfhgs/8yiJQ4 ZXBiikSSvOnioRSHQXtUttdlZtREEdqxp3SKWm4yHnMA6EPOZfPN6zVja1PTClsP sfXVJVzcTg/VwQaU/Klvp6SrvukqHy/vQz52m/JucPNU52i8A897Fle7YbAZDu1H NkXDupIUWCj1whZ/IB8a8w7n2aXQ2Z0s52sbpR5aaBiqe4TEG0Voq6frfprWBFYC jBD6GlCi3+zrvJkryLJPyhAgStXfC5Mq1fzCGbhBYrH6eduFUyYC7UU3wvTbfsd3 EL4aVT9YH7/l1o6EzxGn2ZF+e/MfCWLmne1q3f+EwACaZGwl4SvtRufjJbqBqW+V brmwEX9JJn9C6FoNUHdo =JcrF -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 22:43:19 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6BA8386; Wed, 11 Jun 2014 22:43:19 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0F42FC4; Wed, 11 Jun 2014 22:43:18 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s5BMh2eV042495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 12 Jun 2014 00:43:14 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <5398DB76.3040707@obluda.cz> Date: Thu, 12 Jun 2014 00:43:02 +0200 From: Dan Lukes Reply-To: freebsd-security User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Jonathan Anderson Subject: Re: OpenSSL end of life References: <5398482C.7020406@obluda.cz> <539859BC.2050303@obluda.cz> <539860DE.9080609@FreeBSD.org> <53987248.5050103@obluda.cz> <539888B0.9090108@FreeBSD.org> In-Reply-To: <539888B0.9090108@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 22:43:19 -0000 On 06/11/14 18:49, Jonathan Anderson: > I propose that we be a bit more careful about the libraries that we're > willing to commit to an ABI on, restricting ourselves to things that we > are able to maintain internally as a project or where upstream changes > don't break the ABI (e.g. an executable where the interface is the > command line, so all we have to do is preserve existing arguments). So your proposal is to make something like wrapper library around OpenSSL. Such wrapper library will offer stable ABI to the rest of system and will hide possible ABI changes of underlying native OpenSSL. If the underlying OpenSSL will be replaced by other one, the wrapper library will be modified accordingly, to maintain previous ABI. Right ? It sound plausible to me. I'm not sure it will take less resources that self-support of old OpenSSL version, but I can't estimate it right now. >> We need to support particular version of OpenSSL by self during lifetime of particular release. > > Sure, we could do point patches of old OpenSSL versions as > vulnerabilities are discovered, but who's to say that we'll hear about > them if the upstream vendor has stopped doing security advisories? If > everybody else has moved on from 0.9.8, who in the FreeBSD project is > willing to take ownership of such a large and complex code base? OpenSSL is considered part of base system. Either we can support the system for it's lifetime or not. If we have resources to maintain 5-years lifetime, then OK, I will welcome 5-year lifetime. If we have no such resources, then declared lifetime should to be shortened. Both solutions are OK for me. I have nothing against current 1y/2y system. > On 06/11/14 22:31, Joe User: >> Sorry, but i heard/read this kind of discussion since two decades now It can't be overlooked. You are claiming the arguments that are not mine, then you are responding to them. I'm sure you can continue without me even in the future ;-) Dan From owner-freebsd-security@FreeBSD.ORG Wed Jun 11 23:21:10 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB01761; Wed, 11 Jun 2014 23:21:10 +0000 (UTC) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32E4422ED; Wed, 11 Jun 2014 23:21:10 +0000 (UTC) Received: by mail-yh0-f43.google.com with SMTP id a41so379630yho.2 for ; Wed, 11 Jun 2014 16:21:09 -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=u9RGWzlKLiqUi2jS7zbaPW3j+hK8STnQUAAq7waCZLM=; b=orv6SqsTP8LZSKCQ87U2GvWnBZ28SAm68GgPnsjXWX4hmJYUtjI+GTE+c9FFfDOKpz rjN+eIGESpozgwZmpHv69dcDIS38NFn8BaVyCEBkeOGxVOq1NzpZNIL6GS11CzzMAhLQ SiR3ZZ7FAC1UXcl6cRRuVzJt+g9TkAZWjUzq2mwtJpE3IRwOXqy9NAj8Oj6rpAoZFHQS mE4REwp/it0pQptjytJRnmp1xMT4LQNAfaXElJUySJt9bMDzRPmC3Hi3dFgrpHCAbyWS MpgpC43ivfG+rqUWLXLVyTtmSExluNDbylTm2Ge/LHDfXh/TqDl4lstC9C/1ohi6sRda DEOA== MIME-Version: 1.0 X-Received: by 10.236.39.103 with SMTP id c67mr7625852yhb.139.1402528869203; Wed, 11 Jun 2014 16:21:09 -0700 (PDT) Received: by 10.170.154.136 with HTTP; Wed, 11 Jun 2014 16:21:09 -0700 (PDT) In-Reply-To: <539860DE.9080609@FreeBSD.org> References: <5398482C.7020406@obluda.cz> <539859BC.2050303@obluda.cz> <539860DE.9080609@FreeBSD.org> Date: Wed, 11 Jun 2014 16:21:09 -0700 Message-ID: Subject: Re: OpenSSL end of life From: "Constantine A. Murenin" To: Jonathan Anderson Content-Type: text/plain; charset=UTF-8 Cc: Dan Lukes , freebsd-security , Ben Laurie X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 23:21:10 -0000 On 11 June 2014 06:59, Jonathan Anderson wrote: > Dan Lukes wrote: >> 9.3 can be patched during it's lifetime, but 9.3-pX and 9.3-pY needs to be >> binary compatible. >> >> If it is not compatible, then it's no 9.3 anymore. >> >>> One modification I'd be prepared to contemplate is that 1.0.1 (for >>> example) is supported for some known period of time, even if it should >>> be EOL according to the versioning scheme. The question is: how long? >>> Sounds like you'd want 2 years. >> >> Almost acceptable for me. >> >> I wish to save 2year lifetime period for FreeBSD. > > > Once we officially move to the 5-year branch lifetime, even a 2-year OpenSSL > lifetime becomes problematic. It seems to me that the only solution is to > remove the ABI promise on OpenSSL: move the base system's libcrypt.so into > /usr/lib/private. Installed packages would have to depend on (up-to-date) > OpenSSL from the ports tree, where 2 years might be long enough to do the > EOL dance. > > The problem with this approach is that pkg itself is a package and it needs > to verify signatures to bootstrap itself before installing any OpenSSL > package. Perhaps we can come up with a minimal API (ideally one function) > whose ABI we can continue to support even as we change libcrypt versions > under the hood. BTW, this crypto bootstrapping problem has already been addressed by OpenBSD earlier this year through the development of a lightweight one-algorithm-fits-all signature utility called signify(1). http://mdoc.su/o/signify.1 http://bxr.su/o/usr.bin/signify/signify.c http://www.tedunangst.com/flak/post/signify http://bsd.slashdot.org/story/14/01/19/0124202/openbsd-moving-towards-signed-packages-based-on-d-j-bernstein-crypto C. From owner-freebsd-security@FreeBSD.ORG Thu Jun 12 18:07:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 034CE6F6 for ; Thu, 12 Jun 2014 18:07:15 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BCA5627E6 for ; Thu, 12 Jun 2014 18:07:14 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 19D7335930A; Thu, 12 Jun 2014 20:07:11 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 07F7128497; Thu, 12 Jun 2014 20:07:11 +0200 (CEST) Date: Thu, 12 Jun 2014 20:07:10 +0200 From: Jilles Tjoelker To: Ben Laurie Subject: Re: OpenSSL end of life Message-ID: <20140612180710.GA98525@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 18:07:15 -0000 On Wed, Jun 11, 2014 at 10:32:54AM +0100, Ben Laurie wrote: > We (the OpenSSL team) are considering a more aggressive EOL strategy. > In particular, we may EOL 0.9.8 right now, and 1.0.0 when 1.0.2 comes > out (currently in beta). > Going forward we would only maintain two versions, so when 1.0.3 comes > out, 1.0.1 would be EOL. > What do people think about this? I appreciate that the OpenSSL team is short on time, but such a change would be rather inconvenient for users. In particular, not only are new OpenSSL versions (like 0.9.8 and 1.0.0) ABI-incompatible, but it is unwise to even install more than one version of OpenSSL on a machine. Because different versions of libcrypto.so and libssl.so provide the same symbols, loading multiple versions into one process may cause a mixture of the versions to be used, which may lead to crashes and other nastiness. To be specific, various libraries and PAM modules in the FreeBSD base such as libarchive, libfetch, pam_krb5 and pam_ssh depend on OpenSSL libraries. Linking an executable to both one of these libraries and ports OpenSSL is a bad idea and may lead to strange combinations like using a 0.9.8 libcrypto with a 1.0.1 libssl and using a 1.0.1 libcrypto from code that wants 0.9.8 except for the symbols that were removed between 0.9.8 and 1.0.1. There are various possible solutions to at least allow installing multiple versions of OpenSSL safely, for easier migration, but none of them in FreeBSD or OpenSSL upstream. This situation is unfortunate, also because OpenSSL is otherwise so close (SSL_CTX object allows multiple independent clients within a process). Various Linux distributions are using a symbol versioning hack submitted in http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest but ignored. FreeBSD supports these ELF features as well. A more portable alternative is renaming all symbols, for example using a huge header file containing lines like: #define SSL_new openssl101_SSL_new #define SSL_free openssl101_SSL_free Yet another alternative is an option for ld to store the DSO ld found a symbol in and have rtld look only in that DSO (and explicit interposers). For the longer term, a stable ABI across versions for the OpenSSL libraries seems an interesting idea (even if only for platforms like FreeBSD and glibc with GNU-style symbol versioning that allows multiple versions of the same symbol). -- Jilles Tjoelker From owner-freebsd-security@FreeBSD.ORG Tue Jun 17 22:56:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0411F5B for ; Tue, 17 Jun 2014 22:56:56 +0000 (UTC) Received: from mx.morhold.ru (master.morhold.ru [89.188.102.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA90282C for ; Tue, 17 Jun 2014 22:56:54 +0000 (UTC) Received: from [127.0.0.1] (mx [192.168.0.3] (may be forged)) by mx.morhold.ru (8.14.5/8.14.5) with ESMTP id s5HMbSan023565 for ; Wed, 18 Jun 2014 02:37:29 +0400 (MSK) (envelope-from freebsd-security@morhold.ru) Message-ID: <53A0C324.20200@morhold.ru> Date: Wed, 18 Jun 2014 02:37:24 +0400 From: Morhold User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working References: <5382A982.6090304@calorieking.com> <86vbssr665.fsf@nine.des.no> <538494E8.2060302@rsle.net> <5386957E.2070000@calorieking.com> In-Reply-To: <5386957E.2070000@calorieking.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:56:56 -0000 29.05.2014 6:03, Gregory Orange ŠæŠøшŠµŃ‚: > On 27/05/14 21:36, R. Scott Evans wrote: >> On 05/26/14 10:00, Dag-Erling SmĆørgrav wrote: >>> This was supposed to be fixed by the following errata notice: >>> http://www.freebsd.org/security/advisories/FreeBSD-EN-14:04.kldxref.asc >> >> Well it is still broken after the 9.2-RELEASE-p6 also in that errata. >> >> The relevant thread in freebsd-questions: >> http://lists.freebsd.org/pipermail/freebsd-questions/2014-May/258238.html >> > > I'm left wondering what to do next: > * Should I simply delete linker.hints - would that cause unwanted > behaviour? > * Should I instead move linker.hints aside before freebsd-update cron > & freebsd-update install, then move it back again? That seems to work > on a manual test, but seems ugly. > * Should I post an official PR somewhere? > > Greg. > _______________________________________________ > 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" > Same here with 9.1-RELEASE-p14: # freebsd-update fetch ... The following files will be updated as part of updating to 9.1-RELEASE-p15: /boot/kernel/linker.hints # So I just did like this: - copied /usr/sbin/freebsd-update to /usr/sbin/freebsd-update,my - applied to /usr/sbin/freebsd-update,my the following patch: --- /usr/sbin/freebsd-update 2014-06-18 02:04:54.000000000 +0400 +++ /usr/sbin/freebsd-update,my 2014-06-18 02:08:12.000000000 +0400 @@ -2078,6 +2078,13 @@ # Fetch files. fetch_files || return 1 + mv INDEX-PRESENT INDEX-PRESENT,orig + grep -v '/boot/kernel/linker.hints' INDEX-PRESENT,orig > INDEX-PRESENT + rm INDEX-PRESENT,orig + mv INDEX-NEW INDEX-NEW,orig + grep -v '/boot/kernel/linker.hints' INDEX-NEW,orig > INDEX-NEW + rm INDEX-NEW,orig + # Create and populate install manifest directory; and report what # updates are available. fetch_create_manifest || return 1 - in /etc/crontab replaced "freebsd-update cron" to "freebsd-update,my cron" Now waiting what will happen after. From owner-freebsd-security@FreeBSD.ORG Wed Jun 18 01:43:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06CF5DD4 for ; Wed, 18 Jun 2014 01:43:11 +0000 (UTC) Received: from pandora.au.calorieking.net (114.179.70.115.static.exetel.com.au [115.70.179.114]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A06652533 for ; Wed, 18 Jun 2014 01:43:09 +0000 (UTC) Received: from pandora.internal (localhost [127.0.0.1]) by pandora.au.calorieking.net (Postfix) with ESMTP id C639C33CF2; Wed, 18 Jun 2014 09:43:00 +0800 (WST) X-Virus-Scanned: amavisd-new at calorieking.com Received: from pandora.au.calorieking.net ([127.0.0.1]) by pandora.internal (pandora.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFD8d4uCJE2y; Wed, 18 Jun 2014 09:42:50 +0800 (WST) Received: from egeria.internal (egeria.internal [192.168.2.111]) by pandora.au.calorieking.net (Postfix) with ESMTPSA id DD0F333CF5; Wed, 18 Jun 2014 09:42:50 +0800 (WST) Message-ID: <53A0EE9A.5000603@calorieking.com> Date: Wed, 18 Jun 2014 09:42:50 +0800 From: Gregory Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Morhold , freebsd-security@freebsd.org Subject: Re: freebsd-update.conf IgnorePaths linker.hints not working References: <5382A982.6090304@calorieking.com> <86vbssr665.fsf@nine.des.no> <538494E8.2060302@rsle.net> <5386957E.2070000@calorieking.com> <53A0C324.20200@morhold.ru> In-Reply-To: <53A0C324.20200@morhold.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 01:43:11 -0000 On 18/06/14 06:37, Morhold wrote: > Same here with 9.1-RELEASE-p14: Since I've had no further instruction or advice here (or on -questions), I've solved it myself for now. > So I just did like this: > - copied /usr/sbin/freebsd-update to /usr/sbin/freebsd-update,my > - applied to /usr/sbin/freebsd-update,my the following patch: I'm doing something similar, the difference being I'm introducing a simple script rather than patching a file which might be changed in an update: $ sudo crontab -l 0 3 * * * /usr/local/scripts/freebsd-update-cron $ cat freebsd-update-cron #!/bin/sh mv /boot/kernel/linker.hints /boot/kernel/linker.hints.bk /usr/sbin/freebsd-update cron mv /boot/kernel/linker.hints.bk /boot/kernel/linker.hints From owner-freebsd-security@FreeBSD.ORG Sun Jun 22 12:31:54 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B93870F; Sun, 22 Jun 2014 12:31:54 +0000 (UTC) Received: from mail.openmailbox.org (62-210-83-87.rev.poneytelecom.eu [62.210.83.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19CAA2211; Sun, 22 Jun 2014 12:31:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.openmailbox.org (Postfix) with ESMTP id 4FEB62E0945; Sun, 22 Jun 2014 14:31:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=openmailbox.org; h=user-agent:message-id:subject:subject:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version:received:received; s=openmailbox; t=1403440310; bh=Z+YaUAvC7G48P3ogZ301dEi3d2jf50X46AthadRK0pY=; b=LOTDvMOmspxa V1PThTKuqBJb1kMEbgIo9pQaDbHR0NVLjptbbfAbAINCZ14tWs671sYWlU48IGkx kVJ8zW1Ig1Z2axX4AMbxJQcmCtDtDXd428JvGLxLxI/OJIVTG/rsPi7uztUFIkS+ ij72et8SyTq0p+A8j6NzbU+UfnpZZHw= X-Virus-Scanned: at openmailbox.org Received: from mail.openmailbox.org ([127.0.0.1]) by localhost (mail.openmailbox.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OCKxY3Bnhig; Sun, 22 Jun 2014 14:31:50 +0200 (CEST) Received: from www.openmailbox.org (localhost [127.0.0.1]) by mail.openmailbox.org (Postfix) with ESMTP id 66D802E03A3; Sun, 22 Jun 2014 14:31:50 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 22 Jun 2014 22:31:50 +1000 From: philj@openmailbox.org To: freebsd-security@freebsd.org, freebsd-ports@freebsd.org Subject: Ports tree insecure because of IGNOREFILES+IGNORE Message-ID: X-Sender: philj@openmailbox.org User-Agent: Roundcube Webmail/1.0.0 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 12:31:54 -0000 The IGNOREFILES+IGNORE mechanism allows port maintainers to disable checksum checks. I feel that this mechanism is a stain on an otherwise fantastic ports system. It reduces user confidence in security and makes us all sitting ducks for sophisticated adversaries. Possible changes: (i) removing the IGNOREFILES+IGNORE mechanism entirely if practical. (ii) centralizing the mechanism with a vetting process involving a (highly paranoid) security officer. (iii) requiring users to add a switch to /etc/make.conf or otherwise to OK installation of ports with checksum-disabled components. Awareness and choice breed confidence. =================================== CATEGORY 1: PROBLEMATIC EXECUTABLES =================================== biology/platon ----------------------------------------------------------------------------- # This port only has snapshot archive IGNOREFILES= platon.tar.gz SHA256 (platon.tar.gz) = IGNORE ----------------------------------------------------------------------------- Notes: executable. games/xroach ----------------------------------------------------------------------------- IGNOREFILES= ${DISTFILES} SHA256 (xroach.tar.gz) = IGNORE ----------------------------------------------------------------------------- Notes: executable. net/bindtest ----------------------------------------------------------------------------- IGNOREFILES= ${DISTNAME}${EXTRACT_SUFX} SHA256 (bindtest.tgz) = IGNORE ----------------------------------------------------------------------------- Notes: executable. print/lgrind ----------------------------------------------------------------------------- IGNOREFILES= ${PORTNAME}.tar.gz SHA256 (lgrind/lgrind.tar.gz) = IGNORE ----------------------------------------------------------------------------- Notes: executable. It doesn't checksum the distfile, but it *does* checksum the distfile's contents. This offers less resistance for a maliciously corrupted tarball. Checksumming the distfile itself guards access to the archiver programs and libraries, among other things. Another problem with this checksum-the-contents approach is that there appears to be no protection against extraneous contents, which could be a problem if wildcards are used somewhere in the build/install process. www/lifetype ----------------------------------------------------------------------------- IGNOREFILES= ${CONTRIBE_VERSION}__all_plugins.zip \ ${CONTRIBE_VERSION}__all_templates.zip SHA256 (1.2__all_plugins.zip) = IGNORE SHA256 (1.2__all_templates.zip) = IGNORE ----------------------------------------------------------------------------- Notes: executable (PHP files, etc.). ======================================= CATEGORY 2: PROBLEMATIC NON-EXECUTABLES ======================================= These include documentation files and program data files. Malicious corruption would target any code on the system that processes the files (see japanese/edict below for an example of how a program can be targeted during the build process). A lot of the time, the risk is no doubt negligible, to the point where it's more of a risk to use the ports system itself, with fetch(1) and other helper programs as potential targets. devel/root-doc ----------------------------------------------------------------------------- IGNOREFILES= ${DISTFILES} SHA256 (html502.tar.gz) = IGNORE ----------------------------------------------------------------------------- Notes: intended to be documentation only, but effectively an opaque tarball crafted in an unknown manner and containing unknown contents that gets a free ride beyond the checksum point. games/ftjava ----------------------------------------------------------------------------- IGNOREFILES= FTJava_Documentation.html faq.html FTJava_Linux.html SHA256 (ftjava/FTJava_Documentation.html) = IGNORE SHA256 (ftjava/faq.html) = IGNORE SHA256 (ftjava/FTJava_Linux.html) = IGNORE ----------------------------------------------------------------------------- Notes: documentation. japanese/edict ----------------------------------------------------------------------------- # # These change too often and are not made into executables. # IGNOREFILES= ${DICTFILES} ${DOCFILES} SHA256 (edict/edict.gz) = IGNORE SHA256 (edict/edicth) = IGNORE SHA256 (edict/enamdict.gz) = IGNORE SHA256 (edict/compdic.gz) = IGNORE SHA256 (edict/j_places.gz) = IGNORE SHA256 (edict/ediclsd3.zip) = IGNORE SHA256 (edict/kanjidic.gz) = IGNORE SHA256 (edict/kanjd212.gz) = IGNORE SHA256 (edict/lawgledt.zip) = IGNORE SHA256 (edict/lingdic.zip) = IGNORE SHA256 (edict/geodic.gz) = IGNORE SHA256 (edict/pandpdic.zip) = IGNORE SHA256 (edict/aviation.zip) = IGNORE SHA256 (edict/findic.zip) = IGNORE SHA256 (edict/mktdic.zip) = IGNORE SHA256 (edict/4jword3_edict.zip) = IGNORE SHA256 (edict/concrete.zip) = IGNORE SHA256 (edict/edict_doc.html) = IGNORE SHA256 (edict/edicth.doc) = IGNORE SHA256 (edict/enamdict_doc.txt) = IGNORE SHA256 (edict/enamdict_doc.html) = IGNORE SHA256 (edict/j_places.inf) = IGNORE SHA256 (edict/kanjidic.doc) = IGNORE SHA256 (edict/kanjd212.doc) = IGNORE SHA256 (edict/ediclsd3.rme) = IGNORE SHA256 (edict/lawgldoc.new) = IGNORE SHA256 (edict/lingdic.txt) = IGNORE SHA256 (edict/geodic.doc) = IGNORE SHA256 (edict/aviation.txt) = IGNORE SHA256 (edict/findic.doc) = IGNORE SHA256 (edict/mktdic.doc) = IGNORE SHA256 (edict/4jword3_inf.txt) = IGNORE SHA256 (edict/concrete.doc) = IGNORE ----------------------------------------------------------------------------- Notes: program data files that get a free ride beyond the checksum point, including having the port Makefile run the dictionaries through xjdxgen, a EUC-JP index generator last updated in 1998 that can easily be forced to overflow malloc'd memory with sizeof(long) bytes of data because of an off-by- one index calculation: jindex = (unsigned long *)malloc(indlen); // ... if (indptr > indlen/sizeof(long))) { printf("Index table overflow. Dictionary too large?\n"); exit(1); } Here we write sizeof(long) bytes past a 12-byte buffer: 157 indlen = (diclen * 3*(sizeof(long)/4))/4; (gdb) 158 jindex = (unsigned long *)malloc(indlen); (gdb) 159 if(jindex == NULL) (gdb) p indlen $1 = 12 (gdb) x/16b jindex 0x28210030: 0 0 0 0 0 0 0 0 0x28210038: 0 0 0 0 0 0 0 0 (gdb) b 255 if indptr == 3 Breakpoint 3 at 0x8048fa7: file xjdxgen.c, line 255. (gdb) c Continuing. 255 jindex[indptr] = schi; (gdb) p indptr $2 = 3 (gdb) x/16b jindex 0x28210030: 0 0 0 0 1 0 0 0 0x28210038: 4 0 0 0 0 0 0 0 (gdb) n 256 cstrp = 1; (gdb) x/16b jindex 0x28210030: 0 0 0 0 1 0 0 0 0x28210038: 4 0 0 0 7 0 0 0 (gdb) There are potentially more severe problems that would require significantly more time to examine. This port is relatively inconsequential. The above is purely to illustrate a wider point. mail/spambnc ----------------------------------------------------------------------------- IGNOREFILES= quickstart.shtml IGNOREFILES+= upgrading.shtml SHA256 (spambnc-20060416/quickstart.shtml) = IGNORE SHA256 (spambnc-20060416/upgrading.shtml) = IGNORE ----------------------------------------------------------------------------- Notes: documentation. math/libflame ----------------------------------------------------------------------------- IGNOREFILES= libflame.pdf SHA256 (libflame.pdf) = IGNORE ----------------------------------------------------------------------------- Notes: documentation. net-mgmt/kismet ----------------------------------------------------------------------------- IGNOREFILES= manuf SHA256 (kismet/manuf) = IGNORE ----------------------------------------------------------------------------- Notes: documentation. net/ntopng ----------------------------------------------------------------------------- IGNOREFILES= GeoLiteCity.dat.gz GeoLiteCityv6.dat.gz \ GeoIPASNum.dat.gz GeoIPASNumv6.dat.gz SHA256 (GeoLiteCity.dat.gz) = IGNORE SHA256 (GeoLiteCityv6.dat.gz) = IGNORE SHA256 (GeoIPASNum.dat.gz) = IGNORE SHA256 (GeoIPASNumv6.dat.gz) = IGNORE ----------------------------------------------------------------------------- Notes: program data files with uninvestigated impact. sysutils/apcupsd ----------------------------------------------------------------------------- IGNOREFILES= ${PORTNAME}.pdf SHA256 (apcupsd.pdf) = IGNORE ----------------------------------------------------------------------------- Notes: documentation. www/dillo2 ----------------------------------------------------------------------------- IGNOREFILES+= hyph-${_l}.pat.txt SHA256 (dillo/hyph-af.pat.txt) = IGNORE SHA256 (dillo/hyph-as.pat.txt) = IGNORE SHA256 (dillo/hyph-bg.pat.txt) = IGNORE SHA256 (dillo/hyph-bn.pat.txt) = IGNORE SHA256 (dillo/hyph-ca.pat.txt) = IGNORE SHA256 (dillo/hyph-cop.pat.txt) = IGNORE SHA256 (dillo/hyph-cs.pat.txt) = IGNORE SHA256 (dillo/hyph-cy.pat.txt) = IGNORE SHA256 (dillo/hyph-da.pat.txt) = IGNORE SHA256 (dillo/hyph-de-1901.pat.txt) = IGNORE SHA256 (dillo/hyph-de-1996.pat.txt) = IGNORE SHA256 (dillo/hyph-de-ch-1901.pat.txt) = IGNORE SHA256 (dillo/hyph-el-monoton.pat.txt) = IGNORE SHA256 (dillo/hyph-el-polyton.pat.txt) = IGNORE SHA256 (dillo/hyph-en-gb.pat.txt) = IGNORE SHA256 (dillo/hyph-en-us.pat.txt) = IGNORE SHA256 (dillo/hyph-eo.pat.txt) = IGNORE SHA256 (dillo/hyph-es.pat.txt) = IGNORE SHA256 (dillo/hyph-et.pat.txt) = IGNORE SHA256 (dillo/hyph-eu.pat.txt) = IGNORE SHA256 (dillo/hyph-fi.pat.txt) = IGNORE SHA256 (dillo/hyph-fr.pat.txt) = IGNORE SHA256 (dillo/hyph-fur.pat.txt) = IGNORE SHA256 (dillo/hyph-ga.pat.txt) = IGNORE SHA256 (dillo/hyph-gl.pat.txt) = IGNORE SHA256 (dillo/hyph-grc.pat.txt) = IGNORE SHA256 (dillo/hyph-gu.pat.txt) = IGNORE SHA256 (dillo/hyph-hi.pat.txt) = IGNORE SHA256 (dillo/hyph-hr.pat.txt) = IGNORE SHA256 (dillo/hyph-hsb.pat.txt) = IGNORE SHA256 (dillo/hyph-hu.pat.txt) = IGNORE SHA256 (dillo/hyph-hy.pat.txt) = IGNORE SHA256 (dillo/hyph-ia.pat.txt) = IGNORE SHA256 (dillo/hyph-id.pat.txt) = IGNORE SHA256 (dillo/hyph-is.pat.txt) = IGNORE SHA256 (dillo/hyph-it.pat.txt) = IGNORE SHA256 (dillo/hyph-kmr.pat.txt) = IGNORE SHA256 (dillo/hyph-kn.pat.txt) = IGNORE SHA256 (dillo/hyph-la.pat.txt) = IGNORE SHA256 (dillo/hyph-lt.pat.txt) = IGNORE SHA256 (dillo/hyph-lv.pat.txt) = IGNORE SHA256 (dillo/hyph-ml.pat.txt) = IGNORE SHA256 (dillo/hyph-mn-cyrl.pat.txt) = IGNORE SHA256 (dillo/hyph-mr.pat.txt) = IGNORE SHA256 (dillo/hyph-mul-ethi.pat.txt) = IGNORE SHA256 (dillo/hyph-nb.pat.txt) = IGNORE SHA256 (dillo/hyph-nl.pat.txt) = IGNORE SHA256 (dillo/hyph-nn.pat.txt) = IGNORE SHA256 (dillo/hyph-or.pat.txt) = IGNORE SHA256 (dillo/hyph-pa.pat.txt) = IGNORE SHA256 (dillo/hyph-pl.pat.txt) = IGNORE SHA256 (dillo/hyph-pms.pat.txt) = IGNORE SHA256 (dillo/hyph-pt.pat.txt) = IGNORE SHA256 (dillo/hyph-rm.pat.txt) = IGNORE SHA256 (dillo/hyph-ro.pat.txt) = IGNORE SHA256 (dillo/hyph-ru.pat.txt) = IGNORE SHA256 (dillo/hyph-sa.pat.txt) = IGNORE SHA256 (dillo/hyph-sh-cyrl.pat.txt) = IGNORE SHA256 (dillo/hyph-sh-latn.pat.txt) = IGNORE SHA256 (dillo/hyph-sk.pat.txt) = IGNORE SHA256 (dillo/hyph-sl.pat.txt) = IGNORE SHA256 (dillo/hyph-sr-cyrl.pat.txt) = IGNORE SHA256 (dillo/hyph-sv.pat.txt) = IGNORE SHA256 (dillo/hyph-ta.pat.txt) = IGNORE SHA256 (dillo/hyph-te.pat.txt) = IGNORE SHA256 (dillo/hyph-tk.pat.txt) = IGNORE SHA256 (dillo/hyph-tr.pat.txt) = IGNORE SHA256 (dillo/hyph-uk.pat.txt) = IGNORE SHA256 (dillo/hyph-zh-latn-pinyin.pat.txt) = IGNORE ----------------------------------------------------------------------------- Notes: program data files with uninvestigated impact. www/thttpd ----------------------------------------------------------------------------- IGNOREFILES= notes.html SHA256 (thttpd/notes.html) = IGNORE ----------------------------------------------------------------------------- Notes: documentation. ========================= CATEGORY 3: OK... FOR NOW ========================= "OK" here means the user is at least making a conscious decision. biology/blast ----------------------------------------------------------------------------- # Distfiles change rapidly, but since they can only be downloaded from # the author, this is not a problem. IGNOREFILES= ${DISTFILES} SHA256 (blast2.freebsd-6.x-i686.tar.Z) = IGNORE SHA256 (blast2.freebsd-6.x-x64.tar.Z) = IGNORE ----------------------------------------------------------------------------- Notes: executable code, but port asks user to download distfile manually. chinese/msttf ----------------------------------------------------------------------------- IGNOREFILES= ${MSTTF_SIMHEI} ${MSTTF_SIMSUN} ${MSTTF_TAHOMA} SHA256 (msttf/simhei.ttf) = IGNORE SHA256 (msttf/simsun.ttc) = IGNORE SHA256 (msttf/tahoma.ttf) = IGNORE ----------------------------------------------------------------------------- Notes: port asks user to grab three font files from Windows computer. multimedia/pvr250 ----------------------------------------------------------------------------- IGNOREFILES= hcwPVRP2.sys # Varies from month to month SHA256 (hcwPVRP2.sys) = IGNORE ----------------------------------------------------------------------------- Notes: binary driver, but port asks user to grab it from the product CD. multimedia/pvrxxx ----------------------------------------------------------------------------- IGNOREFILES= hcwPVRP2.sys # Varies from month to month SHA256 (hcwPVRP2.sys) = IGNORE ----------------------------------------------------------------------------- Notes: binary driver, but port asks user to grab it from the product CD. From owner-freebsd-security@FreeBSD.ORG Sun Jun 22 12:40:51 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5267EA74 for ; Sun, 22 Jun 2014 12:40:51 +0000 (UTC) Received: from smtp.pobox.com (smtp.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1D8230F for ; Sun, 22 Jun 2014 12:40:50 +0000 (UTC) Received: from smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id F32611964B for ; Sun, 22 Jun 2014 08:40:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:date:message-id:in-reply-to:references:mime-version :content-type:sender; s=sasl; bh=EboNd9ZMUAmS/vX0+YcsVfruHy8=; b= A3IFI5byWQ43ukwUAxkFiojDBGc1lgq8WT8vK6LVEa1HB+z19KUrBBDJlzN1zEkQ qrOU6Ulyos9PIyL5/vJIwcGzhs8g81NQsJmlAugSw/QpY/x6SOzJ5DJZAQZcboSG U2CFFmvbd6UWDmfNS5tYVD5Ge0hiSeub4k4JmKWrOTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :date:message-id:in-reply-to:references:mime-version :content-type:sender; q=dns; s=sasl; b=qoOYR5lTvOXzXHxq66hxDMAmM UgzfJdQaZkm9qrGnGENnKPNlPCzm5numVzpyvIfEHKuJG2DhRzbXP0Nu5jr5pT/M 5DOuxkfL4eh2fJPPICWJTjH/QDxYbmgFtiGPKV5eDtFi86xms1qzFZ/1gvOjKjU5 mT4RR9cZ+mAse/qBV4= Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id E98141964A for ; Sun, 22 Jun 2014 08:40:39 -0400 (EDT) Received: from behemoth.localnet (unknown [50.90.2.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id 967BD19649 for ; Sun, 22 Jun 2014 08:40:35 -0400 (EDT) From: Chris Nehren To: freebsd-security@freebsd.org Subject: Re: Ports tree insecure because of IGNOREFILES+IGNORE Date: Sun, 22 Jun 2014 08:40:03 -0400 Message-ID: <5004359.PqOTrjIgg6@behemoth> User-Agent: KMail/4.12.5 (FreeBSD/10.0-STABLE; KDE/4.12.5; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9024034.TGMyTBnSM8"; micalg="pgp-sha1"; protocol="application/pgp-signature" Sender: Chris Nehren X-Pobox-Relay-ID: 68365AC2-FA0A-11E3-A1F9-9903E9FBB39C-49531120!pb-smtp0.pobox.com X-Mailman-Approved-At: Sun, 22 Jun 2014 13:42:20 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 12:40:51 -0000 --nextPart9024034.TGMyTBnSM8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sunday, June 22, 2014 22:31:50 philj@openmailbox.org wrote: > The IGNOREFILES+IGNORE mechanism allows port maintainers to > disable checksum checks. I feel that this mechanism is a stain=20 > on an otherwise fantastic ports system. It reduces user > confidence in security and makes us all sitting ducks for=20 > sophisticated adversaries. Er. There's nothing stopping a port maintainer from saying=20 "Sorry, the distfiles aren't fetchable from the master sites any=20 more, I can host a copy" and then host a malicious distfile. Or=20 doing any number of simpler things to cause a problem. The=20 Project doesn't have the resources to audit every single=20 distfile's code. If you're that paranoid, you're welcome to do=20 so yourself. =2D-=20 Chris Nehren --nextPart9024034.TGMyTBnSM8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJTps7BAAoJEBHA+GJAM0vPW9MP/1qS+NfB5B21L0n+g9CtG+U7 STG+r5uADq7qWW2+m5As0dTGOyrjYueDkt0AlWXAYxWZAhye0vs9oSgeCgMNSg7V WGkeHT5BxxLKq3rpobracXVA0C7zKbm0Sd40ra36551++CuAlqpjciy0vH85GtnK V/dNOw5ZmU3AD/fV1Zh1oDIpEvzgBzg1OkL2GOOzHTY6aC6iovfINhiaSGJR2Dhw 41AJE/YdaxI3e9ki6kNIzWwYYBXBdvreSI5s8jmSwFE6rxqh6EY+96YIx0rj3tj/ b9R13h9vCsjtmKvjfhXO/S7uIoYhFd7A4TdjaCzUOMMQU3FYlay7huz36PYIFTYO nDa+nOnHzcI3sxy7S9Z1yR1zB/1/ExCHdjzHhlp7dgRg4MKZru4sBmkJSakgdKic 4fvLgBrMe043TI15/z5Moy9RRd1RU5BbqY5be/o+piSDow4wzUOyupH/CZ5lDU6/ UCXz9yM0rOBQAeDLGslJbnurGA5z10fA3ed0+PG91xDSAMucFzRhJ5jT7vP7uCoY JLWLzorOJaaAd1p0RPljQp1tykSuSsIqyqql8lNeL/zbmsmkaSW4H7ZiexUH3oyb mPDZ3pxTBDsPecl6sWer72iaLXB3G8UoIuI8w1NxZ5jYQke+FowS9Rb5tfGWMq5t 9vEC2OQHlylnFhpNQnVi =hte2 -----END PGP SIGNATURE----- --nextPart9024034.TGMyTBnSM8-- From owner-freebsd-security@FreeBSD.ORG Sun Jun 22 23:16:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E470F93; Sun, 22 Jun 2014 23:16:25 +0000 (UTC) Received: from mail.openmailbox.org (62-210-83-87.rev.poneytelecom.eu [62.210.83.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA5F2F6F; Sun, 22 Jun 2014 23:16:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.openmailbox.org (Postfix) with ESMTP id D2CFB2E0977; Mon, 23 Jun 2014 01:16:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=openmailbox.org; h=user-agent:message-id:references:in-reply-to:subject:subject :from:from:date:date:content-transfer-encoding:content-type :content-type:mime-version:received:received; s=openmailbox; t= 1403478980; bh=wou4f6B3Sv+J+4l3Lpp3/IPLxwD0QsIrPcZ0kWAnzBM=; b=W 74I5Z8szoAMnVCiVfyUDOxJBdpjF6pimTYVRvDwQdZ/FUGV6a++vPQId1Hd9tlah 11jzhioEGbDs9syXEp1TLU1lAcxnavchc88fnmdisOFjiGl9W4SOiR5cQ8OtU5DE KrVMfPPCUfdtpUlqv338wg+ImjnNaTxIfpX9s+ojTw= X-Virus-Scanned: at openmailbox.org Received: from mail.openmailbox.org ([127.0.0.1]) by localhost (mail.openmailbox.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_xYT-PxvGUi; Mon, 23 Jun 2014 01:16:20 +0200 (CEST) Received: from www.openmailbox.org (localhost [127.0.0.1]) by mail.openmailbox.org (Postfix) with ESMTP id 3F1172E0976; Mon, 23 Jun 2014 01:16:20 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 23 Jun 2014 09:16:20 +1000 From: philj@openmailbox.org To: Chris Nehren Subject: Re: Ports tree insecure because of IGNOREFILES+IGNORE In-Reply-To: <5004359.PqOTrjIgg6@behemoth> References: <5004359.PqOTrjIgg6@behemoth> Message-ID: X-Sender: philj@openmailbox.org User-Agent: Roundcube Webmail/1.0.0 Cc: freebsd-security@freebsd.org, owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 23:16:25 -0000 On 2014-06-22 22:40, Chris Nehren wrote: > On Sunday, June 22, 2014 22:31:50 philj@openmailbox.org wrote: >> The IGNOREFILES+IGNORE mechanism allows port maintainers to >> disable checksum checks. I feel that this mechanism is a stain >> on an otherwise fantastic ports system. It reduces user >> confidence in security and makes us all sitting ducks for >> sophisticated adversaries. > > Er. There's nothing stopping a port maintainer from saying > "Sorry, the distfiles aren't fetchable from the master sites any > more, I can host a copy" and then host a malicious distfile. Or > doing any number of simpler things to cause a problem. The > Project doesn't have the resources to audit every single > distfile's code. If you're that paranoid, you're welcome to do > so yourself. Chris, You have a valid point, of course, though in this case I was assuming the port maintainers themselves are trustworthy (just in case you got the impression from my first paragraph that I was painting the port maintainers black). We've seen in the news, at least for Windows, that sophisticated adversaries with man-in-the-middle capabilities are making use of cleartext crash-dump logs, hash collisions (so far only MD5), and weaknesses in the system's update mechanism. I believe the Project does take these threats very seriously, even though superhuman auditing ability is an impractical goal. That's why freebsd-update and portsnap use keys. It's why the vast majority of distinfo files have SHA256 hashes. It's why the /usr/sbin/pkg bootstrapper got blacklisted in versions of FreeBSD that can't verify the signatures. The good news for those who are worried is that all the ports I've mentioned have been marked broken, and the IGNOREFILES+ IGNORE mechanism is now pending removal. Here's a copy of a reply from Baptiste Daroussin (bapt at FreeBSD.org) for those who aren't subscribed to freebsd-ports: ------------------------------------------------------------ All the said port has been marked as broken, the "feature" removal is pending for reviews Thanks for the heads up, I wasn't aware of this "feature" regards, Bapt ------------------------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Tue Jun 24 19:33:53 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2468669B; Tue, 24 Jun 2014 19:33:53 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0529D2066; Tue, 24 Jun 2014 19:33:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5OJXqPF035136; Tue, 24 Jun 2014 19:33:52 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s5OJXqo5035134; Tue, 24 Jun 2014 19:33:52 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 24 Jun 2014 19:33:52 GMT Message-Id: <201406241933.s5OJXqo5035134@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:15.iconv Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:33:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:15.iconv Security Advisory The FreeBSD Project Topic: iconv(3) NULL pointer dereference and out-of-bounds array access Category: core Module: libc/iconv Announced: 2014-06-24 Credits: Manuel Mausz, Tijl Coosemans Affects: FreeBSD 10.0 Corrected: 2014-03-04 12:43:10 UTC (stable/10, 10.0-STABLE) 2014-06-24 19:05:08 UTC (releng/10.0, 10.0-RELEASE-p6) CVE Name: CVE-2014-3951 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The iconv(3) API allows converting text data from one character set encoding to another. Applications first open a converter between two encodings using iconv_open(3) and then convert text using iconv(3). HZ is an encoding of the GB2312 character set used for simplified Chinese characters. VIQR is an encoding for Vietnamese characters. II. Problem Description A NULL pointer dereference in the initialization code of the HZ module and an out of bounds array access in the initialization code of the VIQR module make iconv_open(3) calls involving HZ or VIQR result in an application crash. III. Impact Services where an attacker can control the arguments of an iconv_open(3) call can be caused to crash resulting in a denial-of-service. For example, an email encoded in HZ may cause an email delivery service to crash if it converts emails to a more generic encoding like UTF-8 before applying filtering rules. IV. Workaround No workaround is available, but systems that do not process untrusted Chinese or Vietnamese input are not affected by this vulnerability. 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 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:15/iconv.patch # fetch http://security.FreeBSD.org/patches/SA-14:15/iconv.patch.asc # gpg --verify iconv.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r262731 releng/10.0/ r267829 - ------------------------------------------------------------------------- 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 v2 iQIcBAEBCgAGBQJTqc+KAAoJEO1n7NZdz2rnmqsP/1VXkGjjBB34Qh43HGxmVofB 8Zfkc19nQtHvQaS+wAUfm10Onu2QJUPPm5OZL+kYYxJs1G4/VLTDTl/7cHBkCoA0 abdDpRbtG6CMHfnaARpMOAkg+uvHl41pjHgr+mi4TRYivzSNp+qfw8BsPJ21DAS6 Om6H6m+ggHjTXrtniBtQ+os2wfxbGGMJQzL94QC+tyzzFTEknIt8lgn6hboh99eV pQb8WnSRCPuyiw+hKHdOOS7er7ZCIy9l0VWWfyJzcZP3/W5q6qSNCdnMUNZsTk0L ruiUrhRjookK6/3VKb+9/YMfpB8xuQad2fk2mbQZkaxdSVJyFIfOI6Y9PJYbx9BP Z7Bp0qyEGs+5/CZhiSwr2E/3k7kNe+30dvbPE0SBw9JNS4T0FyzlRUM4Y8s843Lf GUcacSLcgCv8DUU517GmTL+UvnE+dajppr/vueRTC2T0mj8OX1qukq1Rjs9RpZkc l2ajo3TbMZjwwivEsJEI2706tqv2v7+xON6WrZbUvbXlp4Kw7v01pS2Z3DFIeK8d D9H80XuBIM6ZvMUd3NZHBGBjcxYEHvB5hM26ceCAP/ZvOSa4jp8vVQcPVONwj55n RvX+K66t3yGiRznjhUUL+/8T9ulcI8TomgKL+U3UXasinYU9F4v55yXRugYvgnig jh8e1kgmRt2rt5ZLthe5 =Wr8S -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jun 24 19:33:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3F6C6A2; Tue, 24 Jun 2014 19:33:54 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF48C206C; Tue, 24 Jun 2014 19:33:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s5OJXsi8035177; Tue, 24 Jun 2014 19:33:54 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s5OJXsMF035175; Tue, 24 Jun 2014 19:33:54 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 24 Jun 2014 19:33:54 GMT Message-Id: <201406241933.s5OJXsMF035175@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:16.file Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:33:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:16.file Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities in file(1) and libmagic(3) Category: contrib Module: file Announced: 2014-06-24 Affects: All supported versions of FreeBSD. Corrected: 2014-06-24 19:04:55 UTC (stable/10, 10.0-STABLE) 2014-06-24 19:05:08 UTC (releng/10.0, 10.0-RELEASE-p6) 2014-06-24 19:04:55 UTC (stable/9, 9.3-PRERELEASE) 2014-06-24 19:05:19 UTC (releng/9.3, 9.3-RC2) 2014-06-24 19:05:36 UTC (releng/9.2, 9.2-RELEASE-p9) 2014-06-24 19:05:36 UTC (releng/9.1, 9.1-RELEASE-p16) 2014-06-24 19:04:55 UTC (stable/8, 8.4-STABLE) 2014-06-24 19:05:47 UTC (releng/8.4, 8.4-RELEASE-p13) CVE Name: CVE-2012-1571, CVE-2013-7345, CVE-2014-1943, CVE-2014-2270 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The file(1) utility attempts to classify file system objects based on filesystem, magic number and language tests. The libmagic(3) library provides most of the functionality of file(1) and may be used by other applications. II. Problem Description A specifically crafted Composite Document File (CDF) file can trigger an out-of-bounds read or an invalid pointer dereference. [CVE-2012-1571] A flaw in regular expression in the awk script detector makes use of multiple wildcards with unlimited repetitions. [CVE-2013-7345] A malicious input file could trigger infinite recursion in libmagic(3). [CVE-2014-1943] A specifically crafted Portable Executable (PE) can trigger out-of-bounds read. [CVE-2014-2270] III. Impact An attacker who can cause file(1) or any other applications using the libmagic(3) library to be run on a maliciously constructed input can the application to crash or consume excessive CPU resources, resulting in a denial-of-service. IV. Workaround No workaround is available, but systems where file(1) and other libmagic(3)-using applications are never run on untrusted input are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 9.1, 9.2, 9.3, 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:16/file.patch # fetch http://security.FreeBSD.org/patches/SA-14:16/file.patch.asc # gpg --verify file.patch.asc [FreeBSD 8.4] # fetch http://security.FreeBSD.org/patches/SA-14:16/file-8.4.patch # fetch http://security.FreeBSD.org/patches/SA-14:16/file-8.4.patch.asc # gpg --verify file.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r267828 releng/8.4/ r267832 stable/9/ r267828 releng/9.1/ r267831 releng/9.2/ r267831 releng/9.3/ r267830 stable/10/ r267828 releng/10.0/ r267829 - ------------------------------------------------------------------------- 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 v2 iQIcBAEBCgAGBQJTqc+KAAoJEO1n7NZdz2rnaLsP/jwrr5b1qZ9tObnN3FXwzEjD jNHa3AJKHXgrYGzF8yNrZElhE48f02sr9dEXqIw/E5eElcVhi38RBEkwblE8Nj2H M5bzEwVS7kWPcAl1vBno1rFTHutUTOSSopBGgwlNAlWSFnr1iFIIU9dQ6kcGCnBj LvMx5kTSyZ707kArRrFjrDeYlPLSE/vSBOC00TqReS+3Q9By1IH5kUWesDWr+3Gk lvW/JzSTcyOicrGR6vRHiLn9+NKojd6pV3hqV/uxuth1OxRtiGPeodL6CyvkipMo rKjTgXEY2KluBGV9ff+rbeARLfUh2PDJ9Z5BfF7O8ZyMZpKkcw6MFRRfJ0xgtUZK vpF0u8NVMIZhHLSJ9q1Roij2POxeOETNXG2bGKtVu8pqhJ14DvMfPgamsQLhzKRX vBN1Gw+3RctJrQpF9HvYFOsKlfzcWyka82lw5GSsDYGH2TamU00CTQmx/5PW+WVo xV3C17Wj8AkmRYWeC4IzkTiZ8avVOZ+TMyJKRhL6EGBT3ramu8BFdV8oZOcHHpR/ rAI6eZcFtNuwKuvfqHZmh84GicHDkMHXy6OiyCYUW9uNdWl7nUPMMxp/zEA6gtay ozVedGIIrhYkfQAJRcRAcnEBYqcBVkCD/rKXJtdALl3RDQrediRaz0nWE2bJ/qs3 bHjS6vu9VS/3z0+pEYri =5Ihe -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Jun 26 01:22:27 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC517DEF for ; Thu, 26 Jun 2014 01:22:27 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B1D22A6A for ; Thu, 26 Jun 2014 01:22:27 +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 s5Q1MQ5U048902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jun 2014 18:22:26 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5Q1MQ7f048901 for freebsd-security@FreeBSD.org; Wed, 25 Jun 2014 18:22:26 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Jun 2014 18:22:26 -0700 From: John-Mark Gurney To: freebsd-security@FreeBSD.org Subject: fast or slow crypto? Message-ID: <20140626012226.GX1560@funkthat.com> Mail-Followup-To: freebsd-security@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 25 Jun 2014 18:22:26 -0700 (PDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 01:22:27 -0000 Subj is more limited by your attack profile, than purely fast crypto.. In some cases the crypto can be made reasonably fast while being secure against side channel analysis, but in other cases (GHASH) it's pretty much one (slow and secure) or the other (fast and insecure)... The question I have is what attack profile are we going for? Do we want to make this an option? The reason I ask is that I'm working on adding AES-GCM to FreeBSD, but the speed difference between the two is significant... We are looking at 35MB/sec for slow, vs. 234MB/sec for fast, almost 7x faster, for running the GHASH part of GCM... The fast one does help use tricks to try to prevent cache line snooping, but it turns out that you can snoop even on intra-cache line accesses (the first word of a cache line is accessed significantly faster than others on amd64 machines)... So, even the fast one isn't 100% secure... So, how do we address this? One idea I have had is to have both in the kernel, and then via a tuneable/sysctl/kernel compile option select which one gets used... This is both good and bad.. Choice is good, the bad part is that which ever choice we make be the default will be the wrong choice for a non-small group of our users... Hopefully now that side channel is well appreciated, that future crypto designs will not have this issue (here's looking at you ChaCha20/Poly1305) and this won't have to last that long... But till then, we still need to make the choice... Comments? -- 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 Jun 26 01:44:31 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E031C8E6 for ; Thu, 26 Jun 2014 01:44:31 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F9812CB6 for ; Thu, 26 Jun 2014 01:44:31 +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 s5Q1iUl6049242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jun 2014 18:44:30 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5Q1iUkU049241 for freebsd-security@FreeBSD.org; Wed, 25 Jun 2014 18:44:30 -0700 (PDT) (envelope-from jmg) Date: Wed, 25 Jun 2014 18:44:30 -0700 From: John-Mark Gurney To: freebsd-security@FreeBSD.org Subject: Re: fast or slow crypto? Message-ID: <20140626014430.GY1560@funkthat.com> Mail-Followup-To: freebsd-security@FreeBSD.org References: <20140626012226.GX1560@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140626012226.GX1560@funkthat.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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 25 Jun 2014 18:44:31 -0700 (PDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 01:44:31 -0000 John-Mark Gurney wrote this message on Wed, Jun 25, 2014 at 18:22 -0700: > Subj is more limited by your attack profile, than purely fast crypto.. > In some cases the crypto can be made reasonably fast while being > secure against side channel analysis, but in other cases (GHASH) it's > pretty much one (slow and secure) or the other (fast and insecure)... > > The question I have is what attack profile are we going for? Do we > want to make this an option? I forgot to say, in many (most?) cases, the side channel leaks to another process on the local system... So, this may be more of a, do you have untrusted user accounts on your system or not question.. > The reason I ask is that I'm working on adding AES-GCM to FreeBSD, > but the speed difference between the two is significant... We are > looking at 35MB/sec for slow, vs. 234MB/sec for fast, almost 7x > faster, for running the GHASH part of GCM... The fast one does help > use tricks to try to prevent cache line snooping, but it turns out that > you can snoop even on intra-cache line accesses (the first word of a > cache line is accessed significantly faster than others on amd64 > machines)... So, even the fast one isn't 100% secure... > > So, how do we address this? > > One idea I have had is to have both in the kernel, and then via a > tuneable/sysctl/kernel compile option select which one gets used... > > This is both good and bad.. Choice is good, the bad part is that > which ever choice we make be the default will be the wrong choice > for a non-small group of our users... > > Hopefully now that side channel is well appreciated, that future > crypto designs will not have this issue (here's looking at you > ChaCha20/Poly1305) and this won't have to last that long... > > But till then, we still need to make the choice... -- 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 Jun 26 03:20:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30978D7A for ; Thu, 26 Jun 2014 03:20:20 +0000 (UTC) Received: from nschwmtas04p.mx.bigpond.com (nschwmtas04p.mx.bigpond.com [61.9.189.146]) by mx1.freebsd.org (Postfix) with ESMTP id BC996250C for ; Thu, 26 Jun 2014 03:20:19 +0000 (UTC) Received: from nschwcmgw08p ([61.9.190.168]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20140626032011.OEUD8665.nschwmtas04p.mx.bigpond.com@nschwcmgw08p> for ; Thu, 26 Jun 2014 03:20:11 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nschwcmgw08p with BigPond Outbound id JrLB1o00p29zwdD01rLBDk; Thu, 26 Jun 2014 03:20:11 +0000 X-Authority-Analysis: v=2.0 cv=F6HVh9dN c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=7g03L6PLeuXXRPqoltEA:9 a=wPNLvfGTeEIA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s5Q3K1df011002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Jun 2014 13:20:03 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <53AB9161.1000202@heuristicsystems.com.au> Date: Thu, 26 Jun 2014 13:20:01 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org Subject: Re: fast or slow crypto? References: <20140626012226.GX1560@funkthat.com> <20140626014430.GY1560@funkthat.com> In-Reply-To: <20140626014430.GY1560@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 03:20:20 -0000 Thank-you for engaging us John-Mark. If you're referring to: geli: In our case, there are no-local users, and we provide customers with jailed environments where the disks are stratified, so only those elements that need encryption get it, and the algorithm is chosen depending on the criticality of the data in concert with the client. For these fast would be fine. Side-channel attacks should (and are) considered in our solution, should there be a backdoor or other nefarious scenario via the application; this is somewhat mitigated by tedious (monitoring, hacking, source review) processes (notwithstanding coding obscurity). So they shouldn't be entirely discounted ;) ipsec: Less of an issue as some of the ikev2 clients (eg Windows, badly) constrain the options. And between FreeBSD machines aes-xts is adequate. gssd: Unfortunately we don't use nfs on client servers. --- If the granularity of choice is via a global sysctl, then, in our scenario fast with the knowledge that side-channel may occur is preferable to slow and risking the loss of clients, who are always benchmarking us, which we welcome, and hence FreeBSD. My $0.02 Dewayne. From owner-freebsd-security@FreeBSD.ORG Fri Jun 27 00:06:25 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B0AC28C; Fri, 27 Jun 2014 00:06:25 +0000 (UTC) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6A702788; Fri, 27 Jun 2014 00:06:24 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jw12so4559214veb.11 for ; Thu, 26 Jun 2014 17:06:24 -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=gjX70HQmike0Uwf48vLilPNrbQPCd+rwWKbDLMdvWAg=; b=o/Yu9bLfqgXjwxhtwanZoWFkdIqj62rlW11WPgJ9vCMlyS+/0hMcFmw55O1nz5Xsy/ p4l1Kgvmuf0YfzsYZeV/tuepXUwK0+n5ByrX6nfKcRln2hfrF25cc/jr4PSZd1blgaBa B6PgWitZNGfl1xeHcxygHtJewHZv7Lk6HduK9UTmET6O83Nw81QAdsTOE+Ql4QPZGPys /BUVXDvQfu9ku/OWJxDEWY1IL2OXrH7/E+OzeOZk91u2Nk9pSZGyJE5e33DCSkKid+ln pwS5JI5DpI2REYXsstHjeAJ1JFmuWwv4Q8OssC37CA/Xz8yN9JxuQ0mqcy4T1aqo7kla FW1g== MIME-Version: 1.0 X-Received: by 10.52.29.236 with SMTP id n12mr13934395vdh.38.1403827583825; Thu, 26 Jun 2014 17:06:23 -0700 (PDT) Received: by 10.221.65.198 with HTTP; Thu, 26 Jun 2014 17:06:23 -0700 (PDT) In-Reply-To: References: <53A25FC7.5040105@connotech.com> <53A2E91B.8060802@av8n.com> <20140619134829.5d7bd14a@jabberwock.cb.piermont.com> <1403207567.1908.23.camel@excessive.dsl.static.sonic.net> <20140619170644.34e6ddf0@jabberwock.cb.piermont.com> <20140620090421.0cb08f1a@jabberwock.cb.piermont.com> Date: Thu, 26 Jun 2014 20:06:23 -0400 Message-ID: Subject: Fwd: [Cryptography] hardware vs software FDE (was Re: Shredding a file on a flash-based file system?) From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 27 Jun 2014 01:22:32 +0000 Cc: freebsd-security@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 00:06:25 -0000 Links regarding fde implementations, relevant re geli / gbde. ---------- Forwarded message ---------- From: Darren Lasko Date: Thu, Jun 26, 2014 at 6:03 PM Subject: Re: [Cryptography] hardware vs software FDE (was Re: Shredding a file on a flash-based file system?) To: "Perry E. Metzger" Cc: cryptography@metzdowd.com Hi Perry, Sorry for the very slow reply; I was away on vacation. On Fri, Jun 20, 2014 at 9:04 AM, Perry E. Metzger wrote: > > On Thu, 19 Jun 2014 23:37:04 -0400 Darren Lasko > wrote: > > On Thu, Jun 19, 2014 at 5:06 PM, Perry E. Metzger > > wrote: > > > > > It is different in a vital respect -- in the software > > > implementation, you can more or less check that everything is > > > working as expected, and you don't have to trust that the drive > > > isn't sabotaging you. That's quite different -- vitally so, I > > > think. > [...] > > However, to your point that "in the software implementation, you > > can more or less check that everything is working as expected," > > this only holds true if it's open-source (and as we have found > > recently, this is still no guarantee against nasty security > > "flaws"), or if you're willing to reverse-engineer a closed-source > > product (which you could also do with a hardware-based product, > > though likely at a greater expense). > > No. You are missing a very vital point. > I really don't think I missed your point. I even acknowledged that point in my previous post. My counter-point is merely that the actual media encryption part, while vitally important, is only a small part of the overall FDE solution. The other parts of the solution are equally important, much harder to get right, and not readily verifiable in *either* a hardware solution or a closed-source software solution. I would argue that if you don't trust hard drives with built-in encryption, then you also shouldn't trust closed-source software drive encryption products (and maybe you don't). In fact, even the actual media encryption part is probably much harder to verify in a closed-source software implementation than you might be thinking... > If the sectors on the drive are encrypted with some particular > algorithm using some particular key, I can check, in a software only > solution, that the sectors are indeed encrypted in that key using > that algorithm. Getting "that key" out of a closed-source software FDE product will require reverse-engineering the product or employing something like the techniques used in the Princeton "cold boot attack". And once you have the key, you also need to know the encryption algorithm and cipher mode being used (which is usually specified in the product documentation) *plus* the product's algorithm for generating IVs/tweaks for the cipher mode (probably only discoverable by reverse-engineering, since I've never seen a closed-source implementation give this level of detail in its documentation). This is why I said in my previous post, "you can take a look at the ciphertext and verify that you see random-looking bits, and maybe verify through experimentation that it's not using a poor choice of cipher mode like ECB." Anything more than that will require you to dive deep into the inner workings of the product. [...] > > It is actually much worse than that since the hardware implementation > could be doing things like stashing keys in hidden sectors, but one > need not go so far as to worry about that because even the most basic > audit is impossible. > Software-only products are capable of implementing equivalent levels of malfeasance, for example by obfuscating the plaintext media encryption key and stashing it in the area of the drive they reserve for their pre-boot code and metadata. They could even encrypt the media key using a public key to which the developers (or their "partners") hold the private key. > > > While it's true that even with a closed-source product you can take > > a look at the ciphertext and verify that you see random-looking > > bits, > > No, if they say "this is using AES-256 GCM" I can do more than that. > Again, not without the key. > > If your closed source vendor is not telling you what algorithm and > mode they are using, they are of course also doing something > unacceptable and should be excluded from your purchases. It is > acceptable (though not even remotely optimal) if the encryption > implementation is closed source, but it is utterly unacceptable if > its method of operation is not fully disclosed. > Your original comment was about "checking/verifying", not "disclosure". If you look at the datasheets for self-encrypting drives from just about any respectable manufacturer, they disclose the encryption algorithm/mode: http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-pro-1500-series-sata-specification.pdf (XTS-AES-256, FIPS 197 certified) http://www.micron.com/-/media/documents/products/data%20sheet/ssd/m550_2_5_ssd.pdf (AES-256 CBC) Seagate has FIPS 140-2 certification on various models, so even more information can be gleaned from their public security policies (e.g. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2119.pdf) and CAVP certifications (e.g. AES cert #1974 for XTS, CBC, and EBC) Just to reiterate, checking that the actual media encryption is implemented correctly in a closed-source software product is not a straightforward task (even though you can easily "see" the ciphertext). We haven't even discussed how you would verify the other (and trickier, IMO) bits of the product, such as entropy source & RNG for generating media keys, how passwords are "strengthened", how the media key(s) are cryptographically protected with the "strengthened" authentication credentials, how the "key blobs" are sanitized from the drive (especially on flash-based storage devices), etc. I think it's fair to say that hardware-based FDE solutions aren't any more "untrustworthy" than their closed-source software counterparts, and I think one could even argue that open-sourced isn't a silver bullet (http://underhanded.xcott.com/). Even in software implementations, there are a variety of components that are just as difficult to verify everything is working as expected; and as such a high level of faith is required that the software isn't sabotaging you. Regards, Darren _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography From owner-freebsd-security@FreeBSD.ORG Sat Jun 28 11:10:39 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 294EBF91 for ; Sat, 28 Jun 2014 11:10:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0938D2D1D for ; Sat, 28 Jun 2014 11:10:38 +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 s5SBAbwM094013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Jun 2014 04:10:37 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5SBAbCV094012 for freebsd-security@FreeBSD.org; Sat, 28 Jun 2014 04:10:37 -0700 (PDT) (envelope-from jmg) Date: Sat, 28 Jun 2014 04:10:37 -0700 From: John-Mark Gurney To: freebsd-security@FreeBSD.org Subject: Re: fast or slow crypto? Message-ID: <20140628111037.GJ1560@funkthat.com> Mail-Followup-To: freebsd-security@FreeBSD.org References: <20140626012226.GX1560@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140626012226.GX1560@funkthat.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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Sat, 28 Jun 2014 04:10:37 -0700 (PDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 11:10:39 -0000 John-Mark Gurney wrote this message on Wed, Jun 25, 2014 at 18:22 -0700: > Subj is more limited by your attack profile, than purely fast crypto.. > In some cases the crypto can be made reasonably fast while being > secure against side channel analysis, but in other cases (GHASH) it's > pretty much one (slow and secure) or the other (fast and insecure)... So, one point I somewhat forget in this is that the version of software AES in the kernel (that this new GHASH would go with) is vulnerable to side-channel attacks... So, we are already in the fast and less secure side of the equation.. There are lots of interesting optimizations that can made, including a version of AES that uses SSE registers, is constant time, and faster than the Sbox lookup version... -- 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 Wed Jul 2 15:21:00 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4643E412 for ; Wed, 2 Jul 2014 15:21:00 +0000 (UTC) Received: from pps02.cites.illinois.edu (pps02.cites.illinois.edu [192.17.82.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1EB72121 for ; Wed, 2 Jul 2014 15:20:59 +0000 (UTC) Received: from citesht3.cites.illinois.edu (citesht3.cites.illinois.edu [128.174.34.208]) by pps02.cites.illinois.edu (8.14.5/8.14.5) with ESMTP id s62EqeIw025220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Jul 2014 09:52:41 -0500 Received: from CITESMBX1.ad.uillinois.edu ([169.254.3.145]) by CITESHT3.ad.uillinois.edu ([128.174.34.208]) with mapi id 14.03.0181.006; Wed, 2 Jul 2014 09:52:40 -0500 From: "Dautenhahn, Nathan Daniel" To: "freebsd-security@freebsd.org" Subject: Kernel Privilege Separation Policy Thread-Topic: Kernel Privilege Separation Policy Thread-Index: AQHPlgVF9aaCdqlomkW2r7q1+fjp2A== Date: Wed, 2 Jul 2014 14:52:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.22.177.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5ED4744480A83E438ECD8A703812A275@mx.uillinois.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407020167 X-Spam-OrigSender: dautenh1@illinois.edu X-Spam-Bar: X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:21:00 -0000 Hi All- I am a graduate student at UIUC and am currently working on a system that isolates the MMU from the rest of the FreeBSD kernel. For the purpose of enabling privilege separtion within the kernel. - This code is approximately 3k lines. - This base system also provides kernel code integrity (write protection = in memory) as one of its base properties. - This is somewhat follow up work on previous publications VirtualGhost (ASPLOS '14) and KCoFI (IEEE SP '14). The new system uses similar MMU policies to create the isolation within the kernel. Controlling the MMU enables read/write protection policies (for memory page= s) to be enforced within the kernel itself. I am interested in thoughts from the community on how to best use an intra-kernel isolation and mediation mechanism? One example policy or use of this mechanism would be to place critical func= tion pointers into a write protected region of memory and apply a policy where function pointers (such as a system call function pointer) are only allowed= to be set once (a write-once policy). Some initial ideas I have include: - Protecting against common root kit behaviors such as system call hookin= g, character device hooking (protect function pointers), DKOM (modifying process lists to hide data), kernel object hooking, etc. - Protecting capabilty enforcement - Mandatory Access Control Mechanism enforcement - Auditing mechansims (to ensure integrity of audit logs) Does anyone have insight into these or other important uses of this type of system? What would be a "killer app" type use in the kernel? I can be available on IRC if a real time discussion seems like a better pla= ce for discussion. Thanks, ::nathan:: [I have posted this to both freebsd-hackers and freebsd-security lists =97 = I wasn=92t sure what was best]= From owner-freebsd-security@FreeBSD.ORG Wed Jul 2 23:45:59 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95D0D5BD; Wed, 2 Jul 2014 23:45:59 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 708682042; Wed, 2 Jul 2014 23:45:56 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id D6E3B37F7; Wed, 2 Jul 2014 16:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1404344755; bh=td34HVQTpld9yu7XXsJbibRmxzAQpcPDtGs9biRRBhk=; h=Date:From:Reply-To:To:CC:Subject; b=WaoGB7bIqhr48K1U3i6SMbrQeW55i2A2knvPqZDcP6jOMQlL+UiKTPqmQ5EM0noRn oqW6X3ceIYL9dwHc0Mp5UhIu6HROvBVVJv77yDpFI5J6Sq0dqPytgxHZO8XuLuRbXi 5bqrBtq7kWr49TL7nryoL6HrSDeFuhu9rOcfKz2g= Message-ID: <53B499B1.4090003@delphij.net> Date: Wed, 02 Jul 2014 16:45:53 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: RFC: Proposal: Install a /etc/ssl/cert.pem by default? X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie , gecko@FreeBSD.org, re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 23:45:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Currently, FreeBSD does not install a default /etc/ssl/cert.pem because we do not maintain one ourselves. We do, however, provide a port, security/ca_root_nss, which have an option to install a symbolic link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt, which is not the default option. This become a problem when applications, e.g. fetch(8), have grown the support of doing certificate validation. I think now it makes sense to have a default cert.pem installed with the base system. So my proposal would be: 1. Import a set of trusted root certificates, and install if MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem; 2. In src/etc/Makefile, automatically create a symbolic link if it's not already present in ${DESTDIR}/etc/ssl; 3. Teach mergemaster(8) and other similar applications to create the symbolic link on demand; 4. Change the install/deinstall behavior of security/ca_root_nss: ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on install then overwrite with new symlink, and restore on deinstall. ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist, install new a symlink; on deinstall, if /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a symlink to there, or remove if the file does not exist. Comments/objections? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJTtJmxAAoJEJW2GBstM+nsGoQQAJ8Ntso43Lz5YiwVVoar4BsZ 2d5YCv9ODyIVTHQMqz1lOP51NxzgvNPY4Ycdez0CEK8Az4VSSdouQJoBHRp70nCR 1ulMlZ06SXp8EcvPkDHFJC+1CbYu7ezSwgXLndj+7nOtXqr2t12/EccT40+YRNMN zCUTHDWSdiuwNL9TLzDmyEO1oCcgej+zY5rSbVHiUWLQPUPG2ffvaddKCggJoRpp rV/35H7aYNB1LzBpUp0/wisXvNrkXQh4YcH0e2Z7ILwn6GImE8gWex1hi0yndDeW 7wg+0e4HnwrjZrvNCqeggO+7owCYjE4mnb1qexBTrjvkeAKSjTvkiJzrS14S7yO2 Zj2d9S6504M/28i7+QdzANTrqD6yig6HHT5uL6MiSCnaW6G9+mjVB0OljXHCBARg hFtKUxuVJFDANrbs5AmMwA3euLVHUuPtBL/t+yLSoobdVdvTcukftl7i6l86GDlw rVyl57KLSwInAWZLox0+oPXacEwBYk/K0W1VdmbanLO8q2rdNDD5sKJP2I278LjT wYGgjBOWuNfQTAKK13NMrat8DyvMM6lj5fhKkTDrKU6gEwoDeWsOsc5zKF2+lEGU 9nBi0Ll8jaQ3DBlOJcYa6VZMrgBe6dMRxhus0fVQYX8VKpezTwGGWh7Mdb+AJJxx DN4UDkFEYreAP4szDYHC =zwfk -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 00:26:57 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C255DD7; Thu, 3 Jul 2014 00:26:57 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D3932488; Thu, 3 Jul 2014 00:26:56 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s630QV4F007165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 3 Jul 2014 02:26:37 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <53B4A337.3010907@obluda.cz> Date: Thu, 03 Jul 2014 02:26:31 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: d@delphij.net, freebsd-security@FreeBSD.ORG Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> In-Reply-To: <53B499B1.4090003@delphij.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: gecko@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 00:26:57 -0000 On 07/03/14 01:45, Xin Li: > 1. Import a set of trusted root certificates Question is imminent ... Trusted by whom ? Trust is matter of personal decision, local law and law that apply to particular CA. If I consider a CA to be trustworthy, I will insert it's certificate to trusted store. No one is welcomed to make such decision in behalf of me. Just my $0.02 Dan From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 01:48:09 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4618BF90 for ; Thu, 3 Jul 2014 01:48:09 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0133A2AF9 for ; Thu, 3 Jul 2014 01:48:08 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id j15so9819917qaq.12 for ; Wed, 02 Jul 2014 18:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LdqQ9vLWK3ZQUFQprmYsf5ECABeRtmNbiyQxSbRWAYc=; b=EqSOJzAFkY5bKHQlimLQDiSVHYuCJcPT7gwTRXwMyUG1B+xmjFSyHMPUaxfINo6jWK hy1XEpjYEQxviYx58QOmSDYH0SM+2jeUIzFC9GP9ZKYreI5hxHHLUrowIrXoUUJ/pou8 XSySfr+OFvSFrU7V9EU0cRjSrolKF6hdG6eCk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LdqQ9vLWK3ZQUFQprmYsf5ECABeRtmNbiyQxSbRWAYc=; b=Nq5O5mzdxcpKdsO2t3Eps5s5fO+v9grhGFP/NCWGkZh+GVqq5K54VmjHfP7aaWzz2K nk6e9opERyTvlSf6GOfGAKXdsm3GiEowf7hxbb4NsO6s+FIi5MuWJvhB84r93PE2c4OX wZqgRp4vy7FEtkqnG5q0paf4wMttfKvMdJ2eHH8NGnhN3QcjQTIaF55TmtpJ2Gir0tMA 9jFXeAFNNbzWF3SE322zALAy/UDTimkekxwdyrbt/2j+pcQ7nUkvOFZgEuyQVjhnGkl8 9zYHAAxWYuXMAzH2sOTCRzuB/zWUnNF+iz1lQJr5H0Evex+c6uiI9yCRKe3/82fCgLJM SdyQ== X-Gm-Message-State: ALoCoQkFuW16D0b8Nf6delzINVN391rUSmgDBXdRw2WdB6vgeCkjJwUqJ34rtmTENNg6mEkoiK86 X-Received: by 10.224.171.195 with SMTP id i3mr2677128qaz.44.1404352087847; Wed, 02 Jul 2014 18:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.88.132 with HTTP; Wed, 2 Jul 2014 18:47:37 -0700 (PDT) In-Reply-To: <53B4A337.3010907@obluda.cz> References: <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> From: Eitan Adler Date: Wed, 2 Jul 2014 18:47:37 -0700 Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? To: Dan Lukes Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, d@delphij.net, gecko@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 01:48:09 -0000 On 2 July 2014 17:26, Dan Lukes wrote: > On 07/03/14 01:45, Xin Li: > >> 1. Import a set of trusted root certificates > > > > Question is imminent ... > > Trusted by whom ? IMHO, it is sane to follow the same policy that Mozilla follows and to use their root store by default. > If I consider a CA to be trustworthy, I will insert it's certificate to > trusted store. No one is welcomed to make such decision in behalf of me. So remove or edit the defaults. As for #4: I'm not sure I like the port touching the base system (even with an option) but I don't see a real alternative. -- Eitan Adler From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 01:55:17 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC270243 for ; Thu, 3 Jul 2014 01:55:17 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C5F42BC5 for ; Thu, 3 Jul 2014 01:55:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s631tHwE041434 for ; Thu, 3 Jul 2014 01:55:17 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s631tHd8041426 for freebsd-security@FreeBSD.ORG; Thu, 3 Jul 2014 01:55:17 GMT (envelope-from bdrewery) Received: (qmail 88354 invoked from network); 2 Jul 2014 20:55:14 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 2 Jul 2014 20:55:14 -0500 Message-ID: <53B4B7FB.6070407@FreeBSD.org> Date: Wed, 02 Jul 2014 20:55:07 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: d@delphij.net, freebsd-security@FreeBSD.ORG Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> In-Reply-To: <53B499B1.4090003@delphij.net> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RvD1hUEl80fDRN1pdv53OEAOjgUNvbS38" X-Mailman-Approved-At: Thu, 03 Jul 2014 01:57:43 +0000 Cc: Ben Laurie , gecko@FreeBSD.org, re , Jung-uk Kim , FreeBSD Ports Management Team X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 01:55:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RvD1hUEl80fDRN1pdv53OEAOjgUNvbS38 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +portmgr On 7/2/2014 6:45 PM, Xin Li wrote: > Hi, >=20 > Currently, FreeBSD does not install a default /etc/ssl/cert.pem > because we do not maintain one ourselves. We do, however, provide a > port, security/ca_root_nss, which have an option to install a symbolic > link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt, > which is not the default option. >=20 > This become a problem when applications, e.g. fetch(8), have grown the > support of doing certificate validation. I think now it makes sense > to have a default cert.pem installed with the base system. >=20 > So my proposal would be: >=20 > 1. Import a set of trusted root certificates, and install if > MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem; >=20 > 2. In src/etc/Makefile, automatically create a symbolic link if it's > not already present in ${DESTDIR}/etc/ssl; >=20 > 3. Teach mergemaster(8) and other similar applications to create the > symbolic link on demand; >=20 > 4. Change the install/deinstall behavior of security/ca_root_nss: > ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on > install then overwrite with new symlink, and restore on deinstall. > ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist, > install new a symlink; on deinstall, if > /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a > symlink to there, or remove if the file does not exist. >=20 > Comments/objections? >=20 > Cheers, Please see r266291. libfetch will now look in /usr/local/etc/ssl/ before /etc/ssl. The next step was to have the port always install the symlink there. It's fallen through the cracks though. This only allows fixing applications that use libfetch though and not other applications that expect a /etc/ssl/cert.pem like curl. I have no qualms about making security/ca_root_nss *always* install a symlink into /usr/local/etc/ssl, but touching base system is not usually proper for a port. There is this vague idea floating around that for package building, ports should never touch the base system (except /var/db or /var/games or /etc/*passwd*) and / should otherwise be read-only. This has not become a reality or had much discussion yet, though we do frown on overwriting base and touching base already. For example, the perl symlink in /usr/bin is phased out. I like the idea of the base system installing a symlink from /etc/ssl/cert.pem to *somewhere*. I like the idea of secteam maintaining a ca-root-freebsd.pem even better, as long as you are willing to. IMHO always install it, don't depend on MK_OPENSSL. Is the file actually specific to OpenSSL? Ports would love to have it be available all the time regardless of SSL library choices. --=20 Regards, Bryan Drewery --RvD1hUEl80fDRN1pdv53OEAOjgUNvbS38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTtLf7AAoJEDXXcbtuRpfPjAsIAJKt4BxhLrrlgH5CWwo6rDPb hacMSak86hxnu3xF4xcaAWB5QktrdRI+pvPShDznD5cEXX4MRLbeyCaNUFW9ie+y zt02sZxyuD4KGkHPlkHEUhHBl/YviS7K08h4sW0YnTyjhvfTCz0EzHOvio2Qtmfp C7UInmOhRIa1HHsRdZUmD/4MeT8HsXqWq/5Ep1v40I0/fWNYQUrdClYmwAbCAvUZ iJHljEQ1uyns1mPJWTEk+FHIqretyqmCYPQeHIwLCg6eAn2wjoRELH2TFQyCiE0r 8MIDh9wUVl6FvqfHXO2u8tWYLnRxrhUMobJFpj+Q8m1u2/Jzx4msg1IuEXuEa9E= =9Ckg -----END PGP SIGNATURE----- --RvD1hUEl80fDRN1pdv53OEAOjgUNvbS38-- From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 02:28:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00A36A55; Thu, 3 Jul 2014 02:28:47 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 861902E3F; Thu, 3 Jul 2014 02:28:47 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s632SZ5n014444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 3 Jul 2014 04:28:42 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <53B4BFD2.2060903@obluda.cz> Date: Thu, 03 Jul 2014 04:28:34 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: gecko@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 02:28:48 -0000 On 07/03/14 03:47, Eitan Adler: > IMHO, it is sane to follow the same policy that Mozilla follows and to > use their root store by default. It's policy define very generic requirements only. Almost anyone can apply. But I'm not going to discuss Mozila's policy here beyond my opinion that it's definition of "trusted" is near to meaningless. >> If I consider a CA to be trustworthy, I will insert it's certificate to >> trusted store. No one is welcomed to make such decision in behalf of me. > > So remove or edit the defaults. Be sure I'm doing it already with browsers stores. But I wish system/program shall be safe by default because not all users are experts that can recognize dangerous defaults. Are you ready to recommend a CA as trustworthy and take responsibility for such advice ? OK, I expressed my personal opinion in full and I'm not wishing to start a flame war here ;-) Cheers Dan From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 03:29:38 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EFD752D; Thu, 3 Jul 2014 03:29:37 +0000 (UTC) Date: Wed, 2 Jul 2014 23:29:33 -0400 From: Glen Barber To: d@delphij.net Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140703032933.GC1214@hub.FreeBSD.org> References: <53B499B1.4090003@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ" Content-Disposition: inline In-Reply-To: <53B499B1.4090003@delphij.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Ben Laurie , freebsd-security@FreeBSD.ORG, re , Jung-uk Kim , gecko@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 03:29:38 -0000 --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 02, 2014 at 04:45:53PM -0700, Xin Li wrote: > Hi, >=20 > Currently, FreeBSD does not install a default /etc/ssl/cert.pem > because we do not maintain one ourselves. We do, however, provide a > port, security/ca_root_nss, which have an option to install a symbolic > link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt, > which is not the default option. >=20 > This become a problem when applications, e.g. fetch(8), have grown the > support of doing certificate validation. I think now it makes sense > to have a default cert.pem installed with the base system. >=20 > So my proposal would be: >=20 > 1. Import a set of trusted root certificates, and install if > MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem; >=20 > 2. In src/etc/Makefile, automatically create a symbolic link if it's > not already present in ${DESTDIR}/etc/ssl; >=20 > 3. Teach mergemaster(8) and other similar applications to create the > symbolic link on demand; >=20 > 4. Change the install/deinstall behavior of security/ca_root_nss: > ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on > install then overwrite with new symlink, and restore on deinstall. > ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist, > install new a symlink; on deinstall, if > /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a > symlink to there, or remove if the file does not exist. >=20 > Comments/objections? >=20 No objection from me, personally, on the re@ side. In the longer term, it would avoid needing to install the security/ca_root_nss port explicitly for a few things for which they will be needed for 10.1 and 11.0 releases. I do not, however, believe this is suitable to target for 9.3-RELEASE. Glen With hat: re@ --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJTtM4dAAoJELls3eqvi17QlMcP/RrNr/GZ0ujbPzrqaYdOhsln XwvbyH2skfFmVSxxA9VQ8EG0YcAKmRjofiQMmxTuS4aM+IcQ3OayKU78Wwz5RUJM V/mqx9jeICRJuBMjapxGQf2kz9WQWIlf55tw1GfOOQIV83Xu3eN0CK03g6TeZ64f fy6XvJuFsmdNNXEM5m384KMgaQXY+0iFoP6jJyOLs+y+Oodl+UCz4FwjITDFuIRK 0NGP/OHKxJy6pRi0OPo7tLJX82/bn9giqUUUKcCI97o6x0Y+s3AJiMTSdkDofl6N TTLMp/mI2jmSfrrA5dwSr1mfEn6zehu4pymT7xS1StqfN4Z92izNnsP3do+fk2cY +pLSCINyVNcaMrCFGCeG7TCQKa5UE5gtae9WyaLoxw5dLYGtNQ30yy1nLTVxmasi pEsOsNpo4p3J3L5up819QTl6f5OcqshNCUsM9DEQySoxTCxXR+YvsqeB5KRV51G5 2mTsFIlbW+3UR74jSyGyySTGTGupobjvSX/sHp1OABDSwTG8btN5C679jchLArEK Gm1X36PzwfUaXDe26IbHxLbTchM/DWtnks58VveoJmo5imf7jp4HPcJ1evcyOud2 y6AdbS1HAA2cR/5yVMG4AckpR7drP5q9WN3sBjkGgrFqP1VHVEwbdsqa0v/mlJSK hd7xO7x9rA8dO+fK2YX6 =Uuzo -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 03:42:08 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8573C888 for ; Thu, 3 Jul 2014 03:42:08 +0000 (UTC) Received: from nschwmtas02p.mx.bigpond.com (nschwmtas02p.mx.bigpond.com [61.9.189.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA2D2548 for ; Thu, 3 Jul 2014 03:42:07 +0000 (UTC) Received: from nschwcmgw05p ([61.9.190.165]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20140703034205.KKDU12338.nschwmtas02p.mx.bigpond.com@nschwcmgw05p> for ; Thu, 3 Jul 2014 03:42:05 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nschwcmgw05p with BigPond Outbound id Mfi41o00c29zwdD01fi4K7; Thu, 03 Jul 2014 03:42:05 +0000 X-Authority-Analysis: v=2.0 cv=XNWyuHdE c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=2OfI0AduAGkA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=39wWl6jLcRxyP4-43fkA:9 a=wPNLvfGTeEIA:10 a=bh-MhJfyHOEA:10 a=aQ_K02EvcRsA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s633haOD001555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 3 Jul 2014 13:43:37 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <53B4D106.2000009@heuristicsystems.com.au> Date: Thu, 03 Jul 2014 13:41:58 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> <53B4BFD2.2060903@obluda.cz> In-Reply-To: <53B4BFD2.2060903@obluda.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 03:42:08 -0000 I agree with Dan's comments as I don't really see the value in divesting blanket "trust" to another party. But I appreciate the heads-up from Xin Li, so I have the opportunity of moving my certs/CA/keys to a different location. From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 14:16:35 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94072FE1 for ; Thu, 3 Jul 2014 14:16:35 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 275A72D90 for ; Thu, 3 Jul 2014 14:16:34 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id c0f8e22d; for ; Thu, 3 Jul 2014 09:16:26 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :date:content-type:content-transfer-encoding:message-id:from :subject:to:in-reply-to:references:sender; s=blargle2; bh=gUKdmZ QrsJ9RIpfEsMVkmxRNYAY=; b=lUzme9CH920XxLYQQKsg+3/ELQ4dzJv6LruFO+ 8BjSlva7VWSJazDHwlhD7sAid9RMCyG02sX2fjkYn7YjIedY54VnUxDQ06MvMtw1 S479rKpAYzXHOowD1o1TzSe7iJgxRhWcXEgQYlOIFrAjLsqORHQEFMUayjNdAoU+ tGY34Qd0eujiubCzHr+3b4rI7crQaNa10ymf457FtQsXWlTQhclpq4Qj3TOX/INP sa9tkW6YjOK21VyReY+CAeiC/xBU9su4yqefI2pHDpwSOTkuP/P9On0+mX2qihkI I86Mccdwm0G5UBSjQu5VraFxh7jO0Un+AN/0e3p9ZLewv6TQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version:date :content-type:content-transfer-encoding:message-id:from:subject :to:in-reply-to:references:sender; q=dns; s=blargle2; b=yn8ZG+hu oit/XrXHG3ztxd905BCZeupfDseL8xhsXpr7Wm96wNwTLlRhPFAbx4u5V0FSXIhp xp7HmufxWekcjjuKnLli0K3etiXS9JeKtyvWGV6EHOTbDokmhAGd213S+TKdw/ri DGAAg15oBgkfROllgP57jtUfJQNVCuyJ/WdN0+4Ny9+s1nWvmh1zOiVcX/T+xitG jWpwHoMdF3hdLpWzY6rW9lZLTJnOLopKtWutAotzDMjSxxnLnOPVUhK3iPGV6qzA x1KsscEOx1AA6VsOka2k9q5RBDMxXNkqzaAOql3PoOZSDvH4Cx4QCr+eJH3CfqRG jE+xm+N0LHG0rw== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 983cadf0; for ; Thu, 3 Jul 2014 09:16:26 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1404396985-4187-4185/5/12; Thu, 3 Jul 2014 14:16:25 +0000 Mime-Version: 1.0 Date: Thu, 3 Jul 2014 14:16:25 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5c02fe3098089bf6d58834a66f2eeba7@mail.feld.me> X-Mailer: RainLoop/1.6.7.132 From: Mark Felder Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? To: freebsd-security@freebsd.org In-Reply-To: <53B499B1.4090003@delphij.net> References: <53B499B1.4090003@delphij.net> Sender: feld@feld.me X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:16:35 -0000 There is always going to be skepticism about who to trust by default. = The CA system is out of control and it worries me as well. However, if = we do not make an effort to provide a default trust store why do we = enforce verification by default? I feel it would be more consistent to = disable verification requiring those who know what they're doing to = create their own trust store and pass --verify-peer to fetch manually. = I'm on the verge of breaking my keyboard every time I jump onto a random = FreeBSD server and try to fetch something over https. --no-verify-peer is now muscle memory; that isn't a good sign. I eagerly = await verification through DNSSEC to take off. -2c From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 14:23:12 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE5792FA for ; Thu, 3 Jul 2014 14:23:12 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A42C2E5D for ; Thu, 3 Jul 2014 14:23:11 +0000 (UTC) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s63EN3ON025518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2014 07:23:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: multipart/signed; boundary="Apple-Mail=_55949E73-66F1-46BC-8F9D-ACBDA1677AD7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? From: Paul Hoffman In-Reply-To: <53B499B1.4090003@delphij.net> Date: Thu, 3 Jul 2014 07:22:58 -0700 Message-Id: <0C0E9D45-1E4E-4672-A19D-83D9E4A094D0@vpnc.org> References: <53B499B1.4090003@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Thu, 03 Jul 2014 14:46:53 +0000 Cc: freebsd-security@FreeBSD.ORG X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:23:12 -0000 --Apple-Mail=_55949E73-66F1-46BC-8F9D-ACBDA1677AD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2014, at 4:45 PM, Xin Li wrote: > Currently, FreeBSD does not install a default /etc/ssl/cert.pem > because we do not maintain one ourselves. We do, however, provide a > port, security/ca_root_nss, which have an option to install a symbolic > link as /etc/ssl/cert.pem -> /usr/local/share/certs/ca-root-nss.crt, > which is not the default option. >=20 > This become a problem when applications, e.g. fetch(8), have grown the > support of doing certificate validation. I think now it makes sense > to have a default cert.pem installed with the base system. >=20 > So my proposal would be: >=20 > 1. Import a set of trusted root certificates, and install if > MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem; >=20 > 2. In src/etc/Makefile, automatically create a symbolic link if it's > not already present in ${DESTDIR}/etc/ssl; >=20 > 3. Teach mergemaster(8) and other similar applications to create the > symbolic link on demand; >=20 > 4. Change the install/deinstall behavior of security/ca_root_nss: > ETCSYMLINK checked: If /etc/ssl/cert.pem exists, back it up on > install then overwrite with new symlink, and restore on deinstall. > ETCSYMLINK unchecked: If /etc/ssl/cert.pem do not pre-exist, > install new a symlink; on deinstall, if > /usr/share/misc/ca-root-freebsd.pem exists, replace the symlink with a > symlink to there, or remove if the file does not exist. >=20 > Comments/objections? It seems like a good plan. As long as people who have a different trust = list than Mozilla can easily implement their own trust plan, it's fine, = and this brings a lot of ease-of-use to the ports, particularly to = common ones like wget. --Paul Hoffman --Apple-Mail=_55949E73-66F1-46BC-8F9D-ACBDA1677AD7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTtWdGAAoJEJz/fXByZmLZFQ0IAK4+FHvjCfb9UhkgpRHEwmGC U+098qOaEG0A6OHEjmzBRzaNQhV/zdQPyN2eTeJendbfir547ctzFlqsoFWXRi3i O9JsmMaXU+lJLy0lKoZABn8sVqUFVekq47BKhti4VOjH5VCnZcR+m/xxapA5Jq// 6iZjz1hOlkBWo6MV4QfWQv5BmDA4afSD83GJcd7lI3ie2rErzBVhXy3CyecZgoEx ulO2EiqepKwkx2bEOxvxbFIOLdNUN6tQ5JXOnmuB2Eh43p5jXY1cDjpxCL5RFh4E vIBjqVzB7zUatOB1NedG0M8KiPwATB8XrkoJxorCLGVsuG3NUyNfKKP7g8nbcoI= =LYck -----END PGP SIGNATURE----- --Apple-Mail=_55949E73-66F1-46BC-8F9D-ACBDA1677AD7-- From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 14:55:21 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A72AD60 for ; Thu, 3 Jul 2014 14:55:21 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E661721B2 for ; Thu, 3 Jul 2014 14:55:20 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s63Et5wV039556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Thu, 3 Jul 2014 16:55:15 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <53B56EC9.2020107@obluda.cz> Date: Thu, 03 Jul 2014 16:55:05 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <5c02fe3098089bf6d58834a66f2eeba7@mail.feld.me> In-Reply-To: <5c02fe3098089bf6d58834a66f2eeba7@mail.feld.me> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:55:21 -0000 On 07/03/14 16:16, Mark Felder: > if we do not make an effort to provide a default trust store why do we enforce verification by default? Well, there is a CA recognized trustworthy for the purpose of FreeBSD components download. It's a CA maintained by FreeBSD's security officer or other core commiter. I trust source codes under it's control already, so I can trust it's own CA that's verify such code transfers. Of course, such CA is not considered trusted for others purposes. It is acceptable to use pre-installed CA for the purpose of system maintenance, but it must not be used by any generic system utility/library by default. I mean that maintenance tools like portmaster, pkg or so may "trust" such default CA, but generic system tools like fetch or ftp as well as system libraries like libfetch must not considered a CA trusted without explicit administrators/users decision. Dan From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 14:57:16 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1079E6D; Thu, 3 Jul 2014 14:57:15 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB58821E6; Thu, 3 Jul 2014 14:57:15 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s63EvEan012348; Thu, 3 Jul 2014 14:57:14 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <53B56F49.7030109@FreeBSD.org> Date: Thu, 03 Jul 2014 12:27:13 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Bryan Drewery Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> In-Reply-To: <53B4B7FB.6070407@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: d@delphij.net, Ben Laurie , gecko@FreeBSD.org, freebsd-security@FreeBSD.ORG, FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:57:16 -0000 Bryan Drewery wrote: > libfetch will now look in /usr/local/etc/ssl/ before /etc/ssl. How very sensible! > I like the idea of secteam maintaining a ca-root-freebsd.pem even > better, as long as you are willing to. Just my $.02, but if the FreeBSD project is to maintain a ca-root-freebsd.pem, I think it should have one certificate in it: the root FreeBSD Project cert. Beyond that, I'm not willing to vouch for the trustworthiness of any CA, and I don't think the Project should either. Let people install CA bundles from packages, even give admins the choice of "the Mozilla bundle" vs "Dr Guru's paranoid bundle" vs whatever, but I don't think the Project should be in the business of endorsing any particular CA in the base system. > IMHO always install it, don't depend on MK_OPENSSL. Is the file actually > specific to OpenSSL? Ports would love to have it be available all the > time regardless of SSL library choices. Or we could patch the OpenSSL port to use /usr/local/etc/ssl too? Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 15:21:24 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 733917F3 for ; Thu, 3 Jul 2014 15:21:24 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D66B2498 for ; Thu, 3 Jul 2014 15:21:24 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id j15so309479qaq.40 for ; Thu, 03 Jul 2014 08:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7AQkGioBSLPirfXIJ/Nol2WCdgmkxtM2mlC+xdVQQXQ=; b=uqmi3Gxh+Pw+LLgqqZVoyzNzc6K8Ska3db6WLf9FGLqbVY5bpek1lmzmg/ufSNEj8O j9C73nB8o0tkKhyOqgKuAK0YGE9u7ZiY7PNZiWz8UiLY54f3a/faVcfGm57dQOVKk48N znAMtaN9fRcSa7aRWd9Or66Q77NfGU1u6uIb4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7AQkGioBSLPirfXIJ/Nol2WCdgmkxtM2mlC+xdVQQXQ=; b=GQxJs1kKGJA5t5Ot0Ac0/Gua5iZxXLC7W7mHSWsQ5eE8bmFcuA0aj+rI90bms31z3p 1vPvhvYLcOAsrdUfvIpzN2BRIofm0tMXbT1UYhuTXAvyJHDP3K2OXVVuKHb+MmUZAPu1 4uZx7gUG5Zn8+fejnUxCAk55upeZREJzpiSu8VoRxph9VJpelOwAk9RiNJqMLSqLPEka roycVshnIMBRSopFDXPWPFIjXUcQhkhhPt45O8a6ItFiiG+4s5qIERIUmVWOL6scHEnG KWAW58zcdNw3fYxmevNjEACeaQWN9guE2EaETykz3xVI30A1ZlZtO2fodUC8LiynN/Ff 8eNA== X-Gm-Message-State: ALoCoQmhHwx2C3cZq75xbbZy5R/wXTmEP1hlLHJq4m+cRcpSYb6JkJBH9pz54qOyLMcXe08hrrh2 X-Received: by 10.224.7.202 with SMTP id e10mr8477761qae.15.1404400883034; Thu, 03 Jul 2014 08:21:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.88.132 with HTTP; Thu, 3 Jul 2014 08:20:51 -0700 (PDT) In-Reply-To: <53B56F49.7030109@FreeBSD.org> References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> From: Eitan Adler Date: Thu, 3 Jul 2014 08:20:51 -0700 Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? To: Jonathan Anderson Content-Type: text/plain; charset=UTF-8 Cc: d@delphij.net, Ben Laurie , gecko@freebsd.org, Bryan Drewery , freebsd-security@freebsd.org, FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:21:24 -0000 On 3 July 2014 07:57, Jonathan Anderson wrote: > Just my $.02, but if the FreeBSD project is to maintain a > ca-root-freebsd.pem, I think it should have one certificate in it: the root > FreeBSD Project cert. Beyond that, I'm not willing to vouch for the > trustworthiness of any CA, and I don't think the Project should either. Perhaps we should remove HTTPS support from libfetch and require the user to install wget or curl if they want to use SSL? Having a *default* certificate bundle (that could be removed / edited, of course) is not necessarily even making a trust claim about a particular cert. [0] IMHO the position where the majority of SSL on the internet is broken by default is not tenable. We support HTTP. We don't support HTTPS. The browsers spend a lot of time on this problem. We don't. I am not asserting that the Mozilla set is perfect. I am asserting that we should have *functional* SSL in the base system, and that using the Mozilla set is a good way to obtain that with a good enough policy. [0] It might be, but doesn't have to be [1] See https://wiki.mozilla.org/CA:How_to_apply and https://groups.google.com/forum/#!forum/mozilla.dev.security.policy -- Eitan Adler From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 16:07:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CE31D7; Thu, 3 Jul 2014 16:07:41 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BBF62914; Thu, 3 Jul 2014 16:07:41 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s63G7c7O036433; Thu, 3 Jul 2014 16:07:39 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <53B57FC9.4080302@FreeBSD.org> Date: Thu, 03 Jul 2014 13:37:37 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Eitan Adler Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: d@delphij.net, Ben Laurie , gecko@freebsd.org, Bryan Drewery , freebsd-security@freebsd.org, FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:07:41 -0000 Eitan Adler wrote: > Perhaps we should remove HTTPS support from libfetch and require the > user to install wget or curl if they want to use SSL? Having a > *default* certificate bundle (that could be removed / edited, of > course) is not necessarily even making a trust claim about a > particular cert. [0] IMHO the position where the majority of SSL on > the internet is broken by default is not tenable. > > We support HTTP. We don't support HTTPS. The browsers spend a lot of > time on this problem. We don't. I am not asserting that the Mozilla > set is perfect. I am asserting that we should have *functional* SSL > in the base system, and that using the Mozilla set is a good way to > obtain that with a good enough policy. I think it's useful to provide the *mechanism* (libfetch does validation of whatever certs you put in /usr/local/etc/ssl), I'm just saying that we should be very conservative about *policy*: we can vouch for exactly one certificate, and that's the one we control. Vendors who base their products on FreeBSD might choose to pre-populate /etc/ssl with ca-freebsd.pem and ca-vendor.pem, while people who install FreeBSD boxes can choose to install a CA bundle package to /usr/local/etc/ssl. I do see a couple of potential solutions to the "I can't fetch anything on my clean install" problem. First, we can make sure that CA bundles are in the set of packages we put on the install media, so the person installing the OS can choose to adopt the "accept whatever CAs Mozilla likes" policy (or the "accept CAs that Dr Paranoid likes" policy). Second, we could let interactive 'fetch' warn users about unrecognized CAs (different from validation failures) and prompt as to whether or not they want to continue with the fetching. That behaviour would be no worse than manually specifying --no-verify-peer, which is the logical next step when you see a missing CA error today. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 15:36:30 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96E15CA8; Thu, 3 Jul 2014 15:36:30 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 541C525F5; Thu, 3 Jul 2014 15:36:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C6C3F16D0; Thu, 3 Jul 2014 15:30:17 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s63FUGgi099545; Thu, 3 Jul 2014 15:30:16 GMT (envelope-from phk@phk.freebsd.dk) To: Eitan Adler Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? In-reply-to: From: "Poul-Henning Kamp" References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99543.1404401416.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 03 Jul 2014 15:30:16 +0000 Message-ID: <99544.1404401416@critter.freebsd.dk> X-Mailman-Approved-At: Thu, 03 Jul 2014 17:13:57 +0000 Cc: d@delphij.net, Ben Laurie , gecko@freebsd.org, Bryan Drewery , freebsd-security@freebsd.org, Jung-uk Kim , FreeBSD Ports Management Team , re , Jonathan Anderson X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:36:30 -0000 In message , Eitan Adler writes: >On 3 July 2014 07:57, Jonathan Anderson wrote: >> Just my $.02, but if the FreeBSD project is to maintain a >> ca-root-freebsd.pem, I think it should have one certificate in it: the = root >> FreeBSD Project cert. Beyond that, I'm not willing to vouch for the >> trustworthiness of any CA, and I don't think the Project should either. I think this makes a lot of sense: FreeBSD is not in the trust-business and have no benefit from trying to enter it. -- = 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 Thu Jul 3 22:14:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8155E1E7 for ; Thu, 3 Jul 2014 22:14:57 +0000 (UTC) Received: from calvin.ustdmz.roe.ch (calvin.ustdmz.roe.ch [IPv6:2001:1620:98f:face::26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00A332AA1 for ; Thu, 3 Jul 2014 22:14:56 +0000 (UTC) Received: from roe (ssh-from [213.144.130.143]) by calvin.ustdmz.roe.ch (envelope-from ) with LOCAL id 1X2pHE-0000H8-Df for freebsd-security@freebsd.org; Fri, 04 Jul 2014 00:14:48 +0200 Date: Fri, 4 Jul 2014 00:14:48 +0200 From: Daniel Roethlisberger To: freebsd-security@freebsd.org Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140703221448.GA99094@calvin.ustdmz.roe.ch> Mail-Followup-To: freebsd-security@freebsd.org References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:14:57 -0000 Eitan Adler 2014-07-03: > On 3 July 2014 07:57, Jonathan Anderson wrote: > > Just my $.02, but if the FreeBSD project is to maintain a > > ca-root-freebsd.pem, I think it should have one certificate in it: the root > > FreeBSD Project cert. Beyond that, I'm not willing to vouch for the > > trustworthiness of any CA, and I don't think the Project should either. > > Perhaps we should remove HTTPS support from libfetch and require the > user to install wget or curl if they want to use SSL? Having a > *default* certificate bundle (that could be removed / edited, of > course) is not necessarily even making a trust claim about a > particular cert. [0] IMHO the position where the majority of SSL on > the internet is broken by default is not tenable. > > We support HTTP. We don't support HTTPS. [...] I share your view that there should be functional HTTPS capability in a base install. It boggles my mind how it should be better to not support HTTPS at all or only unauthenticated HTTPS, than having to ship a not perfect CA bundle [1] which, while putting trust in some CAs that don't deserve that trust, is still magnitudes more secure in any sense of the word. If you compare the risk between HTTP only or unauthenticated HTTPS, versus HTTPS with a browser's CA bundle, HTTPS with a CA bundle wins whichever way you look at it. I do agree that FreeBSD should not start maintaining its own CA bundle; but personally I don't think it matters whether we use Mozilla's, Google's or even Microsoft's CA bundle, as long as there is one included in a base install and HTTPS is functional by default. [1] There is no such thing as a perfect CA bundle (i.e. both secure *and* usable) given how broken the whole CA system is these days. -- Daniel Roethlisberger http://daniel.roe.ch/ From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 01:03:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59F03A9F for ; Fri, 4 Jul 2014 01:03:15 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4556D294C for ; Fri, 4 Jul 2014 01:03:15 +0000 (UTC) Received: from joe-2.local (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s6413Eh5048266 for ; Fri, 4 Jul 2014 01:03:14 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <53B5FD51.4050309@FreeBSD.org> Date: Thu, 03 Jul 2014 22:33:13 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <20140703221448.GA99094@calvin.ustdmz.roe.ch> In-Reply-To: <20140703221448.GA99094@calvin.ustdmz.roe.ch> 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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 01:03:15 -0000 Daniel Roethlisberger wrote: > I share your view that there should be functional HTTPS capability in > a base install. I think we're all agreed on that, my point is that the statement "a base install should have a CA bundle by default" does not have to imply "every FreeBSD system must accept a the same CAs". A "base install" is something that's been customized by the installer: we don't all have the same keyboard, we don't all extract a ports tree at install time, so why not make CA bundles part of the install-time customization? Put another way, /etc/ssl and /usr/local/etc/ssl are additive, not subtractive: we can make it easy for users to install whatever CA bundles they like, but if you put a bad CA cert in the base system, I have to manually patch the base system, even in environments where I'd rather use binary releases and freebsd-update. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 01:13:15 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04526E50 for ; Fri, 4 Jul 2014 01:13:15 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B205C2A52 for ; Fri, 4 Jul 2014 01:13:14 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id hw13so836427qab.17 for ; Thu, 03 Jul 2014 18:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5D/O2pGPv7r1T05qYGzvo7XwovnNjeUMzggXxz4DccA=; b=i5+vI6iH96FVZiA7GxzD96oBt2h3yv5NjbLy0ZpwVUIa31LRyECoJUvwemejRjDvRH /aEQsTjCgyV2gGZyKLV6f1cyt08oq7LdnlgB++6D+FIY2MZa5yTRoVDU4ln4P+hfDhXY 5ergkjE1aplxVqTzr+vcnw77tI5r3vC9yQQCs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5D/O2pGPv7r1T05qYGzvo7XwovnNjeUMzggXxz4DccA=; b=f98qJmpMCsG5cHtuCjsgNB1EzlVOzZOCksBO5DHuxFERecAURWiW9Jk8hOacEeyk0A E2+J7y2fRHbNzNZ7F6reNu1TcyNonnURURTj0cEKIzkeqsZPuMD96HmjA9A9K0I27Pi2 bIY904SjR3uT0UTkYIkTWUJFYy9ZFlNgjgqICcU1Fwc7HhYymbYTcpySD7ONf0zKWBaE xihShjVqUtBlxURyInHLUspRoEMAHK7FBdmp6z8A2TyEdgXHJxmGZfpYXr1dHLL9MdwN WXVQ9Xn1uq3FAlnG58ziQYQU4IlxoNb6vxDFHDVGC5GJ+9aT6Jg8+M5qqRXCErKvSD0p 8mqw== X-Gm-Message-State: ALoCoQnu3etfTh9rEB6qBHGs3iufYo/0sTIu1UPDKUB4ORRejPSa1xI/IR3JiZ8wF+HSc3ypshsG X-Received: by 10.229.90.196 with SMTP id j4mr13221389qcm.11.1404436393861; Thu, 03 Jul 2014 18:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.88.132 with HTTP; Thu, 3 Jul 2014 18:12:43 -0700 (PDT) In-Reply-To: <53B5FD51.4050309@FreeBSD.org> References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <20140703221448.GA99094@calvin.ustdmz.roe.ch> <53B5FD51.4050309@FreeBSD.org> From: Eitan Adler Date: Thu, 3 Jul 2014 18:12:43 -0700 Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? To: Jonathan Anderson Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 01:13:15 -0000 On 3 July 2014 18:03, Jonathan Anderson wrote: > Put another way, /etc/ssl and /usr/local/etc/ssl are additive, not > subtractive: we can make it easy for users to install whatever CA bundles > they like, but if you put a bad CA cert in the base system, I have to > manually patch the base system, even in environments where I'd rather use > binary releases and freebsd-update. Lets turn it into a config file then? Why does this have to happen at install time? We are just dealing with defaults here. In general, the default system should Just Work. -- Eitan Adler From owner-freebsd-security@FreeBSD.ORG Thu Jul 3 22:25:26 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CF3C818 for ; Thu, 3 Jul 2014 22:25:26 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA8FB2B90 for ; Thu, 3 Jul 2014 22:25:25 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s63MPNRl002392; Thu, 3 Jul 2014 18:25:23 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s63MPNmd002389; Thu, 3 Jul 2014 18:25:23 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21429.55379.293697.133423@hergotha.csail.mit.edu> Date: Thu, 3 Jul 2014 18:25:23 -0400 From: Garrett Wollman To: Daniel Roethlisberger Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? In-Reply-To: <20140703221448.GA99094@calvin.ustdmz.roe.ch> References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <20140703221448.GA99094@calvin.ustdmz.roe.ch> 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]); Thu, 03 Jul 2014 18:25:23 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu X-Mailman-Approved-At: Fri, 04 Jul 2014 01:47:03 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 22:25:26 -0000 < said: > [1] There is no such thing as a perfect CA bundle (i.e. both > secure *and* usable) given how broken the whole CA system is > these days. So is anyone working on DANE support in libfetch and other base-system utilities? Let's lead on this rather than just flaming about how CAs suck.... -GAWollman From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 02:36:04 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF2243FB; Fri, 4 Jul 2014 02:36:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA615215F; Fri, 4 Jul 2014 02:36:04 +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 s642ZtPl098263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 19:35:55 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s642ZtN7098262; Thu, 3 Jul 2014 19:35:55 -0700 (PDT) (envelope-from jmg) Date: Thu, 3 Jul 2014 19:35:55 -0700 From: John-Mark Gurney To: d@delphij.net Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140704023555.GT45513@funkthat.com> Mail-Followup-To: d@delphij.net, freebsd-security@freebsd.org, Ben Laurie , gecko@freebsd.org, re , Jung-uk Kim References: <53B499B1.4090003@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B499B1.4090003@delphij.net> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 03 Jul 2014 19:35:55 -0700 (PDT) Cc: Ben Laurie , freebsd-security@freebsd.org, re , Jung-uk Kim , gecko@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:36:05 -0000 Xin Li wrote this message on Wed, Jul 02, 2014 at 16:45 -0700: > 1. Import a set of trusted root certificates, and install if > MK_OPENSSL is yes, to /usr/share/misc/ca-root-freebsd.pem; My only comment on this is that we (committers) or -core needs to decide how certs are added/removed... If it's mirror mozzila's cert repo, then that's fine, but if we don't have a policy, what will we do when other CA's contact someone at FreeBSD wanting to get their cert included by default? -- 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 Jul 4 02:44:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE1FF6AC; Fri, 4 Jul 2014 02:44:55 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CAE5A2235; Fri, 4 Jul 2014 02:44:55 +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 s642iq20098391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 19:44:52 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s642ipEo098390; Thu, 3 Jul 2014 19:44:51 -0700 (PDT) (envelope-from jmg) Date: Thu, 3 Jul 2014 19:44:51 -0700 From: John-Mark Gurney To: Dan Lukes Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140704024451.GU45513@funkthat.com> Mail-Followup-To: Dan Lukes , d@delphij.net, freebsd-security@freebsd.org, gecko@freebsd.org References: <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> <53B4BFD2.2060903@obluda.cz> <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B4BFD2.2060903@obluda.cz> <53B4A337.3010907@obluda.cz> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 03 Jul 2014 19:44:52 -0700 (PDT) Cc: freebsd-security@freebsd.org, d@delphij.net, gecko@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:44:56 -0000 Dan Lukes wrote this message on Thu, Jul 03, 2014 at 02:26 +0200: > On 07/03/14 01:45, Xin Li: > >1. Import a set of trusted root certificates > > Question is imminent ... > > Trusted by whom ? > > Trust is matter of personal decision, local law and law that apply to > particular CA. > > If I consider a CA to be trustworthy, I will insert it's certificate to > trusted store. No one is welcomed to make such decision in behalf of me. As others have said, you can customize FreeBSD how you want.. There is no, we will uninstall FreeBSD if you uninstall (or set WITHOUT_xxx) on your FreeBSD system... Dan Lukes wrote this message on Thu, Jul 03, 2014 at 04:28 +0200: > On 07/03/14 03:47, Eitan Adler: > >IMHO, it is sane to follow the same policy that Mozilla follows and to > >use their root store by default. > > It's policy define very generic requirements only. Almost anyone can apply. I agree that the FreeBSD project needs a policy on how CA's are selected, just like other countries may not trust USA's CA's, people should always be more aware of this, but sadly, many do not... This is partly why things like TACK and other cert mechanisms are being investigated... When I first heard of how certs were issued almost 20 years ago, I was like, are they stupid? Sadly, we realized too late how stupid it was... > But I'm not going to discuss Mozila's policy here beyond my opinion that > it's definition of "trusted" is near to meaningless. > > >>If I consider a CA to be trustworthy, I will insert it's certificate to > >>trusted store. No one is welcomed to make such decision in behalf of me. > > > >So remove or edit the defaults. > > Be sure I'm doing it already with browsers stores. But I wish > system/program shall be safe by default because not all users are > experts that can recognize dangerous defaults. Per my email to phk, certs can/should have different trust metrics associated with them... I always laugh when I see people post md5/sha1 sums to their http website but not sign them... What's the point? If someone can MITM or hack the server, you can replace the md5/sha1 sum too... There needs to be a proper train of trust if you go that far, and I doubt most people are willing to do that... > Are you ready to recommend a CA as trustworthy and take responsibility > for such advice ? > > OK, I expressed my personal opinion in full and I'm not wishing to start > a flame war here ;-) It's good to know the conserns of our users.. :) Even if we may think some of them are crazy, though I've been happy to find out that I wasn't paranoid over the last few years, they really were listening.. :) -- 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 Jul 4 02:33:45 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9604F3B6; Fri, 4 Jul 2014 02:33:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CA822157; Fri, 4 Jul 2014 02:33:45 +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 s642XdHe098208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2014 19:33:39 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s642XcZa098207; Thu, 3 Jul 2014 19:33:38 -0700 (PDT) (envelope-from jmg) Date: Thu, 3 Jul 2014 19:33:38 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140704023338.GS45513@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , Eitan Adler , d@delphij.net, Ben Laurie , gecko@freebsd.org, Bryan Drewery , freebsd-security@freebsd.org, Jung-uk Kim , FreeBSD Ports Management Team , re , Jonathan Anderson References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <99544.1404401416@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99544.1404401416@critter.freebsd.dk> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 03 Jul 2014 19:33:39 -0700 (PDT) X-Mailman-Approved-At: Fri, 04 Jul 2014 04:25:54 +0000 Cc: d@delphij.net, freebsd-security@freebsd.org, Ben Laurie , gecko@freebsd.org, Bryan Drewery , Eitan Adler , Jonathan Anderson , FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:33:45 -0000 Poul-Henning Kamp wrote this message on Thu, Jul 03, 2014 at 15:30 +0000: > In message , Eitan Adler writes: > >On 3 July 2014 07:57, Jonathan Anderson wrote: > >> Just my $.02, but if the FreeBSD project is to maintain a > >> ca-root-freebsd.pem, I think it should have one certificate in it: the root > >> FreeBSD Project cert. Beyond that, I'm not willing to vouch for the > >> trustworthiness of any CA, and I don't think the Project should either. > > I think this makes a lot of sense: FreeBSD is not in the trust-business > and have no benefit from trying to enter it. Using a CA bundle for downloads is VERY different than pushing banking data across it... Yes, they are used for the same thing, but any CA cert is more trusted than using --no-verify-peer which is more trusted than using http... So, of course if we install a CA bundle, this does mean someone who uses lynx or other text based browser might now not get warnings about untrusted banking sites, but again, the CA bundle is primarily to increase the usability/reliability of fetch, not protecting banking sites... -- 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 Jul 4 07:04:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B71D69F; Fri, 4 Jul 2014 07:04:48 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3776F26F6; Fri, 4 Jul 2014 07:04:47 +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 s6474j7K002767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2014 00:04:46 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6474jDU002766; Fri, 4 Jul 2014 00:04:45 -0700 (PDT) (envelope-from jmg) Date: Fri, 4 Jul 2014 00:04:45 -0700 From: John-Mark Gurney To: Mark Felder Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140704070445.GY45513@funkthat.com> Mail-Followup-To: Mark Felder , freebsd-security@freebsd.org References: <53B499B1.4090003@delphij.net> <5c02fe3098089bf6d58834a66f2eeba7@mail.feld.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c02fe3098089bf6d58834a66f2eeba7@mail.feld.me> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 04 Jul 2014 00:04:46 -0700 (PDT) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 07:04:48 -0000 Mark Felder wrote this message on Thu, Jul 03, 2014 at 14:16 +0000: > There is always going to be skepticism about who to trust by default. The CA system is out of control and it worries me as well. However, if we do not make an effort to provide a default trust store why do we enforce verification by default? I feel it would be more consistent to disable verification requiring those who know what they're doing to create their own trust store and pass --verify-peer to fetch manually. I'm on the verge of breaking my keyboard every time I jump onto a random FreeBSD server and try to fetch something over https. > > --no-verify-peer is now muscle memory; that isn't a good sign. I eagerly await verification through DNSSEC to take off. Maybe an interesting compromise is if there is no symlink/root of trust cert(s) is to issue a warning, but go ahead anyways as if --no-verify-peer is specified? That is assuming we don't install one by default... I normally use wget which has the same issue, so I usually spell it --no-check-certificate... -- 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 Jul 4 09:11:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CC8B303; Fri, 4 Jul 2014 09:11:11 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B88F21EA; Fri, 4 Jul 2014 09:11:10 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id z60so1248433qgd.10 for ; Fri, 04 Jul 2014 02:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E4br/D52iCuYMDohgp4u6JGr2gha5COH+dEQXhWRtts=; b=EC64YpF+aq4aOPH+msWYIlnaMwmGTxezkBJDvyu1am7TMAy5F4PqS2L8Mqu1qJU0nH Y/WhhHQTF0Jaw4Gm23txS6dhLRMv/8sw3SPjufn/FdrjsBEVV6zauxrU4Oa5oN+yaxxW Vbd0EKaAf/ZCG2YvfxIvoKiIeVidqLEb0uGCtC1HLujwWqWHK5I5zVtJTJsioH75Y9WV uN6oCyipvJzNx1W4KC1PWJ+KDMfYXCG1Ukl1tumoxgAnEzo3VbukvMeoCJ3M6xNw1tAY Nf0sN5BuNNjfRD6ztcY48blW//uWJReip7DJKbZfphPmFByxrS6+TPOvoZK6GyqxPeuo sQ4A== MIME-Version: 1.0 X-Received: by 10.140.43.118 with SMTP id d109mr15621218qga.10.1404465069706; Fri, 04 Jul 2014 02:11:09 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.222.168 with HTTP; Fri, 4 Jul 2014 02:11:09 -0700 (PDT) In-Reply-To: <53B57FC9.4080302@FreeBSD.org> References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <53B57FC9.4080302@FreeBSD.org> Date: Fri, 4 Jul 2014 10:11:09 +0100 X-Google-Sender-Auth: A4KjhhtT0fbirSXNunH7pXzekSs Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? From: Ben Laurie To: Jonathan Anderson Content-Type: text/plain; charset=UTF-8 Cc: Xin LI , Eitan Adler , gecko@freebsd.org, Bryan Drewery , "freebsd-security@freebsd.org security" , FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:11:11 -0000 On 3 July 2014 17:07, Jonathan Anderson wrote: > Eitan Adler wrote: >> >> Perhaps we should remove HTTPS support from libfetch and require the >> user to install wget or curl if they want to use SSL? Having a >> *default* certificate bundle (that could be removed / edited, of >> course) is not necessarily even making a trust claim about a >> particular cert. [0] IMHO the position where the majority of SSL on >> the internet is broken by default is not tenable. >> >> We support HTTP. We don't support HTTPS. The browsers spend a lot of >> time on this problem. We don't. I am not asserting that the Mozilla >> set is perfect. I am asserting that we should have *functional* SSL >> in the base system, and that using the Mozilla set is a good way to >> obtain that with a good enough policy. > > > I think it's useful to provide the *mechanism* (libfetch does validation of > whatever certs you put in /usr/local/etc/ssl), I'm just saying that we > should be very conservative about *policy*: we can vouch for exactly one > certificate, and that's the one we control. Vendors who base their products > on FreeBSD might choose to pre-populate /etc/ssl with ca-freebsd.pem and > ca-vendor.pem, while people who install FreeBSD boxes can choose to install > a CA bundle package to /usr/local/etc/ssl. > > I do see a couple of potential solutions to the "I can't fetch anything on > my clean install" problem. First, we can make sure that CA bundles are in > the set of packages we put on the install media, so the person installing > the OS can choose to adopt the "accept whatever CAs Mozilla likes" policy > (or the "accept CAs that Dr Paranoid likes" policy). Second, we could let > interactive 'fetch' warn users about unrecognized CAs (different from > validation failures) and prompt as to whether or not they want to continue > with the fetching. That behaviour would be no worse than manually specifying > --no-verify-peer, which is the logical next step when you see a missing CA > error today. +1. I agree that not making policy decisions on behalf of the user is the right thing to do, but likewise, leaving them entirely to their own devices will just lead to further fail, so a port or ports that will allow users to adopt someone else's policy seems like a necessary part of the equation. From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 09:44:14 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8DD6A47; Fri, 4 Jul 2014 09:44:14 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 879F225A6; Fri, 4 Jul 2014 09:44:14 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id CA9737C0A; Fri, 4 Jul 2014 09:44:13 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 3D1D234524; Fri, 4 Jul 2014 11:44:16 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bryan Drewery Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> Date: Fri, 04 Jul 2014 11:44:16 +0200 In-Reply-To: <53B4B7FB.6070407@FreeBSD.org> (Bryan Drewery's message of "Wed, 02 Jul 2014 20:55:07 -0500") Message-ID: <86fvih5uhb.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: d@delphij.net, Ben Laurie , gecko@FreeBSD.org, freebsd-security@FreeBSD.ORG, FreeBSD Ports Management Team , re , Jung-uk Kim X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:44:14 -0000 Bryan Drewery writes: > This only allows fixing applications that use libfetch though and not > other applications that expect a /etc/ssl/cert.pem like curl. so patch curl... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 10:03:34 2014 Return-Path: Delivered-To: freebsd-security@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A50E1277 for ; Fri, 4 Jul 2014 10:03:34 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62F632781 for ; Fri, 4 Jul 2014 10:03:34 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X30L6-000FMj-9X for freebsd-security@FreeBSD.ORG; Fri, 04 Jul 2014 14:03:32 +0400 Date: Fri, 4 Jul 2014 14:03:32 +0400 From: Slawa Olhovchenkov To: freebsd-security@FreeBSD.ORG Subject: (sshd), uid 0: exited on signal 11 Message-ID: <20140704100332.GA58753@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:03:34 -0000 FreeBSD 10.0-STABLE #5 r265949M: Tue May 13 19:52:37 MSK 2014 Jun 16 14:06:07 srv3 kernel: pid 95261 (sshd), uid 0: exited on signal 11 Jun 24 06:03:25 srv3 kernel: pid 59497 (sshd), uid 0: exited on signal 11 Jun 24 06:03:31 srv3 kernel: pid 59500 (sshd), uid 0: exited on signal 11 Jun 24 06:04:15 srv3 kernel: pid 59535 (sshd), uid 0: exited on signal 11 Jun 24 06:05:56 srv3 kernel: pid 59582 (sshd), uid 0: exited on signal 11 Jun 24 06:09:50 srv3 kernel: pid 59641 (sshd), uid 0: exited on signal 11 Jun 24 06:13:21 srv3 kernel: pid 59721 (sshd), uid 0: exited on signal 11 Jun 24 06:18:47 srv3 kernel: pid 59808 (sshd), uid 0: exited on signal 11 Jun 24 06:22:48 srv3 kernel: pid 59878 (sshd), uid 0: exited on signal 11 Jul 1 15:53:53 srv3 kernel: pid 19659 (sshd), uid 0: exited on signal 11 Jul 1 15:55:33 srv3 kernel: pid 19747 (sshd), uid 0: exited on signal 11 Jul 1 15:57:25 srv3 kernel: pid 19838 (sshd), uid 0: exited on signal 11 Jul 1 16:03:10 srv3 kernel: pid 20156 (sshd), uid 0: exited on signal 11 Jul 1 16:07:16 srv3 kernel: pid 20330 (sshd), uid 0: exited on signal 11 Jul 2 14:41:15 srv3 kernel: pid 42669 (sshd), uid 0: exited on signal 11 Jul 2 14:41:58 srv3 kernel: pid 42696 (sshd), uid 0: exited on signal 11 Jul 2 14:42:12 srv3 kernel: pid 42712 (sshd), uid 0: exited on signal 11 Jul 2 14:43:12 srv3 kernel: pid 42758 (sshd), uid 0: exited on signal 11 Jul 2 14:43:15 srv3 kernel: pid 42763 (sshd), uid 0: exited on signal 11 Jul 2 14:43:19 srv3 kernel: pid 42766 (sshd), uid 0: exited on signal 11 Jul 2 14:43:49 srv3 kernel: pid 42793 (sshd), uid 0: exited on signal 11 Jul 2 14:43:59 srv3 kernel: pid 42803 (sshd), uid 0: exited on signal 11 Jul 2 14:45:17 srv3 kernel: pid 42891 (sshd), uid 0: exited on signal 11 Jul 2 14:45:31 srv3 kernel: pid 42906 (sshd), uid 0: exited on signal 11 Jul 2 14:46:04 srv3 kernel: pid 42944 (sshd), uid 0: exited on signal 11 Jul 2 14:46:07 srv3 kernel: pid 42947 (sshd), uid 0: exited on signal 11 Jul 2 14:46:26 srv3 kernel: pid 42965 (sshd), uid 0: exited on signal 11 Jul 2 14:46:29 srv3 kernel: pid 42968 (sshd), uid 0: exited on signal 11 Jul 2 14:49:19 srv3 kernel: pid 43128 (sshd), uid 0: exited on signal 11 Jul 2 14:49:55 srv3 kernel: pid 43164 (sshd), uid 0: exited on signal 11 Jul 2 14:52:50 srv3 kernel: pid 43296 (sshd), uid 0: exited on signal 11 Jul 2 14:53:22 srv3 kernel: pid 43317 (sshd), uid 0: exited on signal 11 Jul 2 14:55:00 srv3 kernel: pid 43397 (sshd), uid 0: exited on signal 11 Jul 2 14:55:20 srv3 kernel: pid 43428 (sshd), uid 0: exited on signal 11 Jul 2 14:56:21 srv3 kernel: pid 43473 (sshd), uid 0: exited on signal 11 Jul 2 14:56:32 srv3 kernel: pid 43482 (sshd), uid 0: exited on signal 11 Jul 2 15:01:47 srv3 kernel: pid 43732 (sshd), uid 0: exited on signal 11 Jul 2 15:04:01 srv3 kernel: pid 43836 (sshd), uid 0: exited on signal 11 Jul 2 15:06:34 srv3 kernel: pid 43937 (sshd), uid 0: exited on signal 11 Jul 2 15:09:37 srv3 kernel: pid 44083 (sshd), uid 0: exited on signal 11 Jul 3 11:43:32 srv3 kernel: pid 66662 (sshd), uid 0: exited on signal 11 Jul 3 11:44:23 srv3 kernel: pid 66709 (sshd), uid 0: exited on signal 11 Jul 3 11:45:20 srv3 kernel: pid 66747 (sshd), uid 0: exited on signal 11 Jul 3 11:45:47 srv3 kernel: pid 66775 (sshd), uid 0: exited on signal 11 What is this? New exploit in sshd? From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 12:30:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4788F14A; Fri, 4 Jul 2014 12:30:33 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21CE82530; Fri, 4 Jul 2014 12:30:33 +0000 (UTC) Received: from janderson.engr.mun.ca (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s64CUUl3095493; Fri, 4 Jul 2014 12:30:32 GMT (envelope-from jonathan@FreeBSD.org) Message-ID: <53B69E65.7020507@FreeBSD.org> Date: Fri, 04 Jul 2014 10:00:29 -0230 From: Jonathan Anderson User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dan Lukes , d@delphij.net, freebsd-security@freebsd.org, gecko@freebsd.org Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? References: <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> <53B4BFD2.2060903@obluda.cz> <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> <20140704024451.GU45513@funkthat.com> In-Reply-To: <20140704024451.GU45513@funkthat.com> 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.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:30:33 -0000 John-Mark Gurney wrote: > Dan Lukes wrote this message on Thu, Jul 03, 2014 at 02:26 +0200: >> If I consider a CA to be trustworthy, I will insert it's certificate to >> trusted store. No one is welcomed to make such decision in behalf of me. > > As others have said, you can customize FreeBSD how you want.. There > is no, we will uninstall FreeBSD if you uninstall (or set WITHOUT_xxx) > on your FreeBSD system... So we agree that customization is required, the question is what a user has to do to effect this customization: 1. install a package (possibly included on the install media), or 2. set WITHOUT_MOZILLA_CA_BUNDLE and rebuild FreeBSD. To me, the approach that doesn't require "rebuild FreeBSD" is the simpler one. It also doesn't require a Security Advisory every time a CA gets dropped from Mozilla's bundle (which ought to happen a lot). Ports get updated, people get that. I don't think we should introduce things in the base system that we *know* will require SAs, freebsd-update, etc. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Fri Jul 4 15:40:23 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 824894E9; Fri, 4 Jul 2014 15:40:23 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 40FF525AC; Fri, 4 Jul 2014 15:40:22 +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 s64FdwVH010290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2014 08:39:58 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s64FdvMQ010289; Fri, 4 Jul 2014 08:39:57 -0700 (PDT) (envelope-from jmg) Date: Fri, 4 Jul 2014 08:39:57 -0700 From: John-Mark Gurney To: Jonathan Anderson Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140704153957.GA45513@funkthat.com> Mail-Followup-To: Jonathan Anderson , Dan Lukes , d@delphij.net, freebsd-security@freebsd.org, gecko@freebsd.org References: <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> <53B4BFD2.2060903@obluda.cz> <53B499B1.4090003@delphij.net> <53B4A337.3010907@obluda.cz> <20140704024451.GU45513@funkthat.com> <53B69E65.7020507@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B69E65.7020507@FreeBSD.org> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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, 04 Jul 2014 08:39:58 -0700 (PDT) Cc: Dan Lukes , freebsd-security@freebsd.org, d@delphij.net, gecko@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:40:23 -0000 Jonathan Anderson wrote this message on Fri, Jul 04, 2014 at 10:00 -0230: > John-Mark Gurney wrote: > >Dan Lukes wrote this message on Thu, Jul 03, 2014 at 02:26 +0200: > >>If I consider a CA to be trustworthy, I will insert it's certificate to > >>trusted store. No one is welcomed to make such decision in behalf of me. > > > >As others have said, you can customize FreeBSD how you want.. There > >is no, we will uninstall FreeBSD if you uninstall (or set WITHOUT_xxx) > >on your FreeBSD system... > > > So we agree that customization is required, the question is what a user > has to do to effect this customization: > > 1. install a package (possibly included on the install media), or > 2. set WITHOUT_MOZILLA_CA_BUNDLE and rebuild FreeBSD. 3. rm /etc/ssl/cert.ca > To me, the approach that doesn't require "rebuild FreeBSD" is the > simpler one. > > It also doesn't require a Security Advisory every time a CA gets dropped > from Mozilla's bundle (which ought to happen a lot). Ports get updated, > people get that. I don't think we should introduce things in the base > system that we *know* will require SAs, freebsd-update, etc. But don't we want people to get in the habit of patching/addressing security issues? As far as this one is to address, it's easy... manually fetch and install this file... A lot easier than most SA's to address by hand if you're not using freebsd-update.. -- 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 Jul 4 15:43:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 459FE69A for ; Fri, 4 Jul 2014 15:43:57 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF5922672 for ; Fri, 4 Jul 2014 15:43:56 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id v10so1445038qac.32 for ; Fri, 04 Jul 2014 08:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pTo/0Lk6YNKZmN9T7ZD37F2gtWtffdn5BR1H0RQF3Bg=; b=TM8v+L8LPODSe51n7H/gwp6hza9kYvk1Q/gP3W88FDtaMxasKPEdmgpsyLcMch8zRw 7KvtKSeX9hFD2cEZKm1HYTNHg7nGzGYT+4kEPOdQHBqFMmB4I9h+jtDNXFRJkn03TTFy ejryY/Tb0VtVSgcJ0GJjABpYSxiTp5hLYAtM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pTo/0Lk6YNKZmN9T7ZD37F2gtWtffdn5BR1H0RQF3Bg=; b=WfdXjqaSlPRdZBljm332X17np0JiddPj+ntdYujY1gIqa22elyKHWq3uReMYKgfzOj INVbEAhjIbd+3RxdKidRuZdZFmplyEGvN5lAZceDA9Eg5IIFj6onAVwoPdkB27pLTV4Z OyhxYW018GNx5Ri1g7pZMFcunTPamWElxrwZJk/G7dc9aK2F6k82fRkUdbic6CR4GZ9J v6bzV0NVlbKTL6kfdW4UxxCc3PnyVlvZy5Y86cjTjtsEnVmMw6QLtH0GkspTZNDlkFQ8 GeR6s+KEodYAefer8Ai3o76ulvZT3MhiwGpRm6UmsWe4epzMRhzY/tvU5X81r/K/D8jI ZKdA== X-Gm-Message-State: ALoCoQn6/m3xZu/hywEtJCN8EEC7zxo/icC2hb6fYovg11Jb3OtVBf3UBNQt/x2366rxc342H6t0 X-Received: by 10.140.81.209 with SMTP id f75mr12676501qgd.60.1404488635809; Fri, 04 Jul 2014 08:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.88.132 with HTTP; Fri, 4 Jul 2014 08:43:25 -0700 (PDT) In-Reply-To: References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <53B57FC9.4080302@FreeBSD.org> From: Eitan Adler Date: Fri, 4 Jul 2014 08:43:25 -0700 Message-ID: Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Cc: Xin LI , gecko@freebsd.org, Bryan Drewery , "freebsd-security@freebsd.org security" , Jung-uk Kim , FreeBSD Ports Management Team , re , Jonathan Anderson X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:43:57 -0000 On 4 July 2014 02:11, Ben Laurie wrote: > On 3 July 2014 17:07, Jonathan Anderson wrote: >> Eitan Adler wrote: >>> >>> Perhaps we should remove HTTPS support from libfetch and require the >>> user to install wget or curl if they want to use SSL? Having a >>> *default* certificate bundle (that could be removed / edited, of >>> course) is not necessarily even making a trust claim about a >>> particular cert. [0] IMHO the position where the majority of SSL on >>> the internet is broken by default is not tenable. >>> >>> We support HTTP. We don't support HTTPS. The browsers spend a lot of >>> time on this problem. We don't. I am not asserting that the Mozilla >>> set is perfect. I am asserting that we should have *functional* SSL >>> in the base system, and that using the Mozilla set is a good way to >>> obtain that with a good enough policy. >> >> >> I think it's useful to provide the *mechanism* (libfetch does validation of >> whatever certs you put in /usr/local/etc/ssl), I'm just saying that we >> should be very conservative about *policy*: we can vouch for exactly one >> certificate, and that's the one we control. Vendors who base their products >> on FreeBSD might choose to pre-populate /etc/ssl with ca-freebsd.pem and >> ca-vendor.pem, while people who install FreeBSD boxes can choose to install >> a CA bundle package to /usr/local/etc/ssl. >> >> I do see a couple of potential solutions to the "I can't fetch anything on >> my clean install" problem. First, we can make sure that CA bundles are in >> the set of packages we put on the install media, so the person installing >> the OS can choose to adopt the "accept whatever CAs Mozilla likes" policy >> (or the "accept CAs that Dr Paranoid likes" policy). Second, we could let >> interactive 'fetch' warn users about unrecognized CAs (different from >> validation failures) and prompt as to whether or not they want to continue >> with the fetching. That behaviour would be no worse than manually specifying >> --no-verify-peer, which is the logical next step when you see a missing CA >> error today. > > +1. I agree that not making policy decisions on behalf of the user is > the right thing to do, but likewise, leaving them entirely to their > own devices will just lead to further fail, so a port or ports that > will allow users to adopt someone else's policy seems like a necessary > part of the equation. Lets stop conflating "default" with "policy decision". -- Eitan Adler From owner-freebsd-security@FreeBSD.ORG Sat Jul 5 08:43:21 2014 Return-Path: Delivered-To: FreeBSD-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C60CDC3E for ; Sat, 5 Jul 2014 08:43:21 +0000 (UTC) Received: from mailout4.lrau.net (mailout4.lrau.net [IPv6:2a02:d40:2:2::73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 841A323FA for ; Sat, 5 Jul 2014 08:43:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=email; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=6Thu1ui64ScVaFQPlLEUi8nH+ZBboLGYcBjtmMiQrQY=; b=dTK9ohED9VYQw2Iat+1KcZra8AnU3eb8y/pT3i+m6NPdnrOVtXyGWpKVkFB9GlFP92XIQEyuFnElFpfnegf7zf9sDsGEBPqul58shuovLZAiqPCnQVoVtl+7S+Ozu6jjA3rCXlVefRbLs618Mq44HIXISedg6tlGXGJLasAW4fc=; Received: from [91.216.35.74] (helo=imap.lrau.net) by mailout4.lrau.net with esmtp (Exim 4.82) (envelope-from ) id 1X3LZ0-000HTc-DP for FreeBSD-security@FreeBSD.org; Sat, 05 Jul 2014 08:43:18 +0000 Received: from AXEL.RAU@Chaos1.DE by imap.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1404549797-27428-27426/7/779; Sat, 5 Jul 2014 08:43:17 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? From: Axel Rau In-Reply-To: <21429.55379.293697.133423@hergotha.csail.mit.edu> Date: Sat, 5 Jul 2014 10:43:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <20140703221448.GA99094@calvin.ustdmz.roe.ch> <21429.55379.293697.133423@hergotha.csail.mit.edu> To: FreeBSD-security@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 08:43:21 -0000 Am 04.07.2014 um 00:25 schrieb Garrett Wollman : > < said: >=20 >> [1] There is no such thing as a perfect CA bundle (i.e. both >> secure *and* usable) given how broken the whole CA system is >> these days. >=20 > So is anyone working on DANE support in libfetch and other base-system > utilities? Let's lead on this rather than just flaming about how CAs > suck=E2=80=A6. +1 DANE is the route to go in the future. It perfectly matches the use case discussed here. Axel =2D-- PGP-Key:29E99DD6 =E2=98=80 +49 151 2300 9283 =E2=98=80 computing @ = chaos claudius From owner-freebsd-security@FreeBSD.ORG Sat Jul 5 09:22:58 2014 Return-Path: Delivered-To: FreeBSD-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF027430 for ; Sat, 5 Jul 2014 09:22:58 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8CCD26B2 for ; Sat, 5 Jul 2014 09:22:57 +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 AEFEE20F96; Sat, 5 Jul 2014 05:22:49 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 05 Jul 2014 05:22:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=DhTH85BHqtYD1M8UdO7ellvKrow=; b=N1GTRUwO+okOeWO2wQ6yDbHB0jXe 6+1PDqgPDHfmDRKQNwKXq56sKdYIBk7EIyG3volKLkvpIZOibGW8sdhILYO0hsdD uOnecBu45REhdtV1Hlt9syfCYZz2P1G3g99wAAOtizegcYtRxE8Xq2vWg9X/pFcO 39IXdoD9AJiNMVk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=smtpout; bh=DhTH85BHqtYD1M8UdO7ellvKrow=; b=WmN0 WBR8DbjtrT/EuC0JlQFOtEtSyXvm7dYQxqbVROaexDT4g9GLhJCWEOSbiA7gMqxP 9bvhb4TpbG6TugCtdSDiu1FpH2npcvfdfBXtQZM8sFJSHWZfMDjwW39wvHhFAC83 aDQ67vJhX7mHGn1DAGzjOMnx/Q1/6XxD5tLhcBw= X-Sasl-enc: 4jjWuCYGIcANF92IVfG7tGVqSCi6vaBIq8aVab/MMEE+ 1404552169 Received: from kropotkin.aux.io (unknown [223.252.30.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 92F37C00003; Sat, 5 Jul 2014 05:22:48 -0400 (EDT) Date: Sat, 5 Jul 2014 19:22:37 +1000 From: Alastair Hogge To: Axel Rau Subject: Re: RFC: Proposal: Install a /etc/ssl/cert.pem by default? Message-ID: <20140705092237.GA94704@kropotkin.aux.io> References: <53B499B1.4090003@delphij.net> <53B4B7FB.6070407@FreeBSD.org> <53B56F49.7030109@FreeBSD.org> <20140703221448.GA99094@calvin.ustdmz.roe.ch> <21429.55379.293697.133423@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 09:22:59 -0000 On 2014-07-05 Sat 10:43:16 +0200, Axel Rau wrote: > > Am 04.07.2014 um 00:25 schrieb Garrett Wollman : > > > < said: > > > >> [1] There is no such thing as a perfect CA bundle (i.e. both > >> secure *and* usable) given how broken the whole CA system is > >> these days. > > > > So is anyone working on DANE support in libfetch and other base-system > > utilities? Let's lead on this rather than just flaming about how CAs > > suckā€¦. > +1 DANE is the route to go in the future. > It perfectly matches the use case discussed here. +1 From owner-freebsd-security@FreeBSD.ORG Tue Jul 8 22:33:48 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D21DD6F0; Tue, 8 Jul 2014 22:33:48 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD38D2A25; Tue, 8 Jul 2014 22:33:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s68MXmtE043083; Tue, 8 Jul 2014 22:33:48 GMT (envelope-from security-advisories@freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s68MXmuX043081; Tue, 8 Jul 2014 22:33:48 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 8 Jul 2014 22:33:48 GMT Message-Id: <201407082233.s68MXmuX043081@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: delphij set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-14:17.kmem Reply-To: freebsd-security@freebsd.org Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 22:33:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-14:17.kmem Security Advisory The FreeBSD Project Topic: Kernel memory disclosure in control messages and SCTP notifications Category: core Module: kern, sctp Announced: 2014-07-08 Credits: Michael Tuexen Affects: All supported versions of FreeBSD. Corrected: 2014-07-08 21:54:50 UTC (stable/10, 10.0-STABLE) 2014-07-08 21:55:27 UTC (releng/10.0, 10.0-RELEASE-p7) 2014-07-08 21:54:50 UTC (stable/9, 9.3-PRERELEASE) 2014-07-08 21:55:27 UTC (releng/9.3, 9.3-RC3-p1) 2014-07-08 21:55:27 UTC (releng/9.3, 9.3-RC2-p1) 2014-07-08 21:55:27 UTC (releng/9.3, 9.3-RC1-p2) 2014-07-08 21:55:27 UTC (releng/9.3, 9.3-BETA3-p2) 2014-07-08 21:55:27 UTC (releng/9.2, 9.2-RELEASE-p10) 2014-07-08 21:55:27 UTC (releng/9.1, 9.1-RELEASE-p17) 2014-07-08 21:54:50 UTC (stable/8, 8.4-STABLE) 2014-07-08 21:55:39 UTC (releng/8.4, 8.4-RELEASE-p14) CVE Name: CVE-2014-3952, CVE-2014-3953 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The control message API is used to construct ancillary data objects for use in control messages sent and received across sockets and passed via the recvmsg(2) and sendmsg(2) system calls. II. Problem Description Buffer between control message header and data may not be completely initialized before being copied to userland. [CVE-2014-3952] Three SCTP cmsgs, SCTP_SNDRCV, SCTP_EXTRCV and SCTP_RCVINFO, have implicit padding that may not be completely initialized before being copied to userland. In addition, three SCTP notifications, SCTP_PEER_ADDR_CHANGE, SCTP_REMOTE_ERROR and SCTP_AUTHENTICATION_EVENT, have padding in the returning data structure that may not be completely initialized before being copied to userland. [CVE-2014-3953] III. Impact An unprivileged local process may be able to retrieve portion of kernel memory. For the generic control message, the process may be able to retrieve a maximum of 4 bytes of kernel memory. For SCTP, the process may be able to retrieve 2 bytes of kernel memory for all three control messages, plus 92 bytes for SCTP_SNDRCV and 76 bytes for SCTP_EXTRCV. If the local process is permitted to receive SCTP notification, a maximum of 112 bytes of kernel memory may be returned to userland. 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. 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 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:17/kmem.patch # fetch http://security.FreeBSD.org/patches/SA-14:17/kmem.patch.asc # gpg --verify kmem.patch.asc [FreeBSD 8.4, 9.2 and 9.3-RC] # fetch http://security.FreeBSD.org/patches/SA-14:17/kmem-89.patch # fetch http://security.FreeBSD.org/patches/SA-14:17/kmem-89.patch.asc # gpg --verify kmem.patch.asc [FreeBSD 9.1] # fetch http://security.FreeBSD.org/patches/SA-14:17/kmem-9.1.patch # fetch http://security.FreeBSD.org/patches/SA-14:17/kmem-9.1.patch.asc # gpg --verify kmem.patch.asc b) Apply the patch. Execute the following commands as root: # 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/ r268432 releng/8.4/ r268435 stable/9/ r268432 releng/9.1/ r268434 releng/9.2/ r268434 releng/9.3/ r268433 stable/10/ r268432 releng/10.0/ r268434 - ------------------------------------------------------------------------- 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 v2 iQIcBAEBCgAGBQJTvHEtAAoJEO1n7NZdz2rnbRcP+gJ9CIH2kch1kXgs94McM1L+ uSnUQsv30OQFe/J//q65HUINVwCMwyRZRFZ238sVsJ6jpft6UTaDxDSdJAqR2opi hew/KEYYQhrrFXCHAgyaXh7Ph1B9URBJ5/MOkDWIBYOei3bxPZRP4ordrtclq/bA qFRvov9gXUah6imbnRMvmC68tzt9v7I/vE2VwsC9fE/yL25IvP5ZunEATegOm4IQ w+fk2VB/6GNFbTsWW1aR6FM60mWXVj2uJfHenEG1K381AXXQb4lSzo8E2SsdkI3B x+MJkxBhNrpSm6tV/zndtYRoDtFseuTHBjKxe7liTyJcFuztkZqmdHaNzbeBSVON P/fIqMHt2f143028ZZZEFqHzuqiEWrWB3WcgQnfsp3HrhMPnhnwkfo8TuC5NiKYx 6CsdnWLdPb1ix9RqX4MqnbFBHDKCoK28nuCKcxJB/OXanikGzcIBazpLsqFmTcm6 9bZ79zuMWU7wiU8p5qdGURmjTJQx9eF5UHcyfIPX6wZLyx8WVltbF5zVJa0nw0LC OEf5KmmgEbPhfdkJ5R2UyHffwQDCNs+vixNLRSJS9/D/6lczT8qPxpDEkjQCsSKw YxmLubDOjnqR57yrh4kKEj2V5ZJcRu2G1q1EKdLfD98VJOrot8p4qa4sCL+o9sbw nII906M+PVUAnsa9synp =nTZs -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri Jul 11 12:48:55 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D9B7F8C; Fri, 11 Jul 2014 12:48:55 +0000 (UTC) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9047D254B; Fri, 11 Jul 2014 12:48:53 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBE1BD.dip0.t-ipconnect.de [217.251.225.189]) (authenticated bits=128) by land.berklix.org (8.14.5/8.14.5) with ESMTP id s6BBiXNl006156; Fri, 11 Jul 2014 11:44:34 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id s6BBkHoa021149; Fri, 11 Jul 2014 13:46:17 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id s6BBk5Z3082993; Fri, 11 Jul 2014 13:46:17 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201407111146.s6BBk5Z3082993@fire.js.berklix.net> To: Xin Li Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 9.2 EoL coming soon From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Thu, 10 Jul 2014 21:56:30 +0000." <201407102156.s6ALuU4H058789@freefall.freebsd.org> Date: Fri, 11 Jul 2014 13:46:05 +0200 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:48:55 -0000 > Hello Everyone, > > On September 30, 2014, FreeBSD 9.2 will reach its End of Life and will > no longer be supported by the FreeBSD Security Team. > > Users of FreeBSD 9.2 are strongly encouraged to upgrade to one of the > newer releases before the that date. A tight timesecale to force business users to upgrade. 9.2 is the main release today (8.4 old, & 10.0 risky) 9.3 not even released just RC3. Northern hemisphere is 3 weeks off August when some whole countries (eg .fr) virtually close down on holiday, & others don't get much done 'till after 1st week in Sept. Slip 9.2 EOL one month to 31st Oct. & it'll give many business sys admins a much better window. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Interleave replies Below, like a play script. From owner-freebsd-security@FreeBSD.ORG Fri Jul 11 13:34:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA2C7D97 for ; Fri, 11 Jul 2014 13:34:57 +0000 (UTC) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59F192982 for ; Fri, 11 Jul 2014 13:34:56 +0000 (UTC) Received: from kgw.obluda.cz ([194.108.204.138]) by smtp1.ms.mff.cuni.cz (8.14.5/8.14.5) with ESMTP id s6BDYlSw038395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Fri, 11 Jul 2014 15:34:53 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <53BFE7F7.1060309@obluda.cz> Date: Fri, 11 Jul 2014 15:34:47 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 9.2 EoL coming soon References: <201407111146.s6BBk5Z3082993@fire.js.berklix.net> In-Reply-To: <201407111146.s6BBk5Z3082993@fire.js.berklix.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:34:57 -0000 On 07/11/14 13:46, Julian H. Stacey: >> On September 30, 2014, FreeBSD 9.2 will reach its End of Life > A tight timesecale to force business users to upgrade. 9.2 is the > main release today (8.4 old, & 10.0 risky) 9.3 not even released > just RC3. Northern hemisphere is 3 weeks off August when some whole > countries (eg .fr) virtually close down on holiday, & others don't > get much done 'till after 1st week in Sept. Slip 9.2 EOL one month > to 31st Oct. & it'll give many business sys admins a much better window. Valid arguments and +1m slip should not harm Security Officer so much. On the other side, business users, especially holiday sensitive users, could consider not to install releases with non-extended lifetime in the future ... System with extended lifetime will give them more freedom ... Dan From owner-freebsd-security@FreeBSD.ORG Fri Jul 11 14:40:28 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8BBF798 for ; Fri, 11 Jul 2014 14:40:28 +0000 (UTC) Received: from mail.freebsd.systems (unknown [IPv6:2001:6a0:1cb::b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DA6B207D for ; Fri, 11 Jul 2014 14:40:28 +0000 (UTC) Received: from mail.freebsd.systems (mail.freebsd.systems [IPv6:2001:6a0:1cb::b]) by mail.freebsd.systems (Postfix) with ESMTP id A5F4423E; Fri, 11 Jul 2014 16:40:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at freebsd.systems Received: from mail.freebsd.systems ([IPv6:2001:6a0:1cb::b]) by mail.freebsd.systems (scan.freebsd.systems [IPv6:2001:6a0:1cb::b]) (amavisd-new, port 10026) with ESMTP id aIaZvc-MuyGS; Fri, 11 Jul 2014 16:39:53 +0200 (CEST) Received: from [192.168.138.100] (unknown [194.181.86.74]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.freebsd.systems (Postfix) with ESMTPSA id DE2CA239; Fri, 11 Jul 2014 16:39:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wasikowski.net; s=default; t=1405089593; bh=yLg9IelB7xyJR1TRsJ5nV/AydCUJ2vL6l1NBhBpLHRI=; h=Date:From:To:References:In-Reply-To; b=ivNMZFBZIVRHncR2jGlzWrawQj8Wq3YlSfJUN2x0JgYeXbp9XpUuS1FnYT25oiWQm ldQcJk760Y6c36ZnEomVAXoX3lWCVJVu9wRWwWxa9nNb8XpJzptRS6RYbCj+O59pon ZyTzCgvMfjMfWCJZO4v5k5Iewn/nz/+lFGudLzGSqoVp5bWt9Bkd1fPz47F76Io8gH lh6fttvxnTKA82V7YFpeeSrcxiF747tmK5KFcWitrdMAoOuJTqonSvmi0zshKZuiFc 3ytUIZquzhn5JXwwqSjlQJSF0JrIFu1TF7Io9ZZcWzE0081FVyCeD7JpE8x8kl94VG YfHQjF9dDmF0w== Message-ID: <53BFF72C.1060500@wasikowski.net> Date: Fri, 11 Jul 2014 16:39:40 +0200 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dan Lukes , freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 9.2 EoL coming soon References: <201407111146.s6BBk5Z3082993@fire.js.berklix.net> <53BFE7F7.1060309@obluda.cz> In-Reply-To: <53BFE7F7.1060309@obluda.cz> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 14:40:28 -0000 W dniu 2014-07-11 15:34, Dan Lukes pisze: > On 07/11/14 13:46, Julian H. Stacey: >>> On September 30, 2014, FreeBSD 9.2 will reach its End of Life > >> A tight timesecale to force business users to upgrade. 9.2 is the >> main release today (8.4 old, & 10.0 risky) 9.3 not even released >> just RC3. Northern hemisphere is 3 weeks off August when some whole >> countries (eg .fr) virtually close down on holiday, & others don't >> get much done 'till after 1st week in Sept. Slip 9.2 EOL one month >> to 31st Oct. & it'll give many business sys admins a much better window. > > Valid arguments and +1m slip should not harm Security Officer so much. > > On the other side, business users, especially holiday sensitive users, > could consider not to install releases with non-extended lifetime in the > future ... > > System with extended lifetime will give them more freedom ... There were too many important changes / fixes in 9.2 to stick with 9.1. +1 month for migration to 9.3 would be great. -- best regards, Lukasz Wasikowski From owner-freebsd-security@FreeBSD.ORG Tue Jul 15 05:26:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60FBF8C7 for ; Tue, 15 Jul 2014 05:26:33 +0000 (UTC) Received: from ruxcon.org.au (ruxcon.org.au [106.186.24.76]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27F222B2E for ; Tue, 15 Jul 2014 05:26:32 +0000 (UTC) Received: by ruxcon.org.au (Postfix, from userid 111) id 35C76E5DC; Tue, 15 Jul 2014 15:16:40 +1000 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruxcon.org.au; s=mail; t=1405401400; bh=6vrU0LdDXNTxzhPojF8uhnLQhkaI21zLg1Gi8P8fPG0=; h=Subject:From:To:Date:From; b=XpaeipaO/ovQAvec5blXluidqhLBmqeJjd4FgRlv/A5RY+SavdIMKRW/EavMGdW3L 2bE8LOTJorFmLXrik5cbeV0XOY5PKZFfmYVMjkRCCOyyfR4qrLwfCSEifc4zp/xeIy RI9Utmpnns9dcahITzYWfJnBzLrN3po0FsC7rgvw= X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ruxcon X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE,HTML_TAG_BALANCE_BODY,HTML_TAG_BALANCE_HEAD,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from [127.0.0.1] (ruxcon [127.0.0.1]) by ruxcon.org.au (Postfix) with ESMTP id 592F8E5FA for ; Tue, 15 Jul 2014 15:16:38 +1000 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruxcon.org.au; s=mail; t=1405401398; bh=6vrU0LdDXNTxzhPojF8uhnLQhkaI21zLg1Gi8P8fPG0=; h=Subject:From:To:Date:From; b=iGYvIhjreXXpPW6PSZ0BnQoEI8CB7Pc15GKRdARJEd1HMOTQ2q1pjZKDOwuMKKymJ sppiPUCmN+rfiXSacE1npDNc6etv0xDE3A+NMGkmxgTxG3AxN7UKIxmObROyXyQCdH yzJXm1VU+2YHACcOFQThn5c9sjUr+qh+GOvhZTZY= MIME-Version: 1.0 Subject: Ruxcon 2014 Final Call For Presentations From: cfp@ruxcon.org.au To: freebsd-security@freebsd.org Date: Tue, 15 Jul 2014 15:16:38 +1000 Message-Id: <20140715051638.592F8E5FA@ruxcon.org.au> X-Mailman-Approved-At: Tue, 15 Jul 2014 11:38:40 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 05:26:33 -0000 Ruxcon 2014 Call For Presentations Melbourne, Australia, October 11th-12th CQ Function Centre http://www.ruxcon.org.au The Ruxcon team is pleased to announce the Final Call For Presentations for Ruxcon 2014. This year the conference will take place over the weekend of the 11th and 12th of October at the CQ Function Centre, Melbourne, Australia. The deadline for submissions is the 15th of September, 2014. .[x]. About Ruxcon .[x]. Ruxcon is ia premier technical computer security conference in the Australia. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations. The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community. .[x]. Important Dates .[x]. September 15 - Call For Presentations Close October 6-7 - Ruxcon/Breakpoint Training October 8-9 - Breakpoint Conference October 11-12 - Ruxcon Conference .[x]. Topic Scope .[x]. o Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) .[x]. Submission Guidelines .[x]. In order for us to process your submission we require the following information: 1. Presentation title 2. Detailed summary of your presentation material 3. Name/Nickname 4. Mobile phone number 5. Brief personal biography 6. Description of any demonstrations involved in the presentation 7. Information on where the presentation material has or will be presented before Ruxcon * As a general guideline, Ruxcon presentations are between 45 and 60 minutes, including question time. If you have any enquiries about submissions, or would like to make a submission, please send an email to presentations@ruxcon.org.au .[x]. Contact .[x]. o Email: presentations@ruxcon.org.au o Twitter: @ruxcon From owner-freebsd-security@FreeBSD.ORG Tue Jul 15 19:21:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3D26A1F; Tue, 15 Jul 2014 19:21:27 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F7602AB5; Tue, 15 Jul 2014 19:21:26 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id l18so6032874wgh.25 for ; Tue, 15 Jul 2014 12:21:25 -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=YRYJreMVVfZ5WhTa6DZCRmB7lVKQddexuii2Iimc8So=; b=pxWD3IaDNf0AbDTQ/uGXOcNcJJGRaJ0vSejcJZNxBCrTsFqHdhWKi47m11bkyq5n3t l/prkIgqSrGBsbTjK8uAEpkQjrwS3XtOSUarGQ757EsMVdo+Glut2c2+iCTAcLBe7hpT 5XBFGnXDNKoaXGpTIuhyG5EKEBEN7KdBboFItT1heohMD9LNWkj90Wy8IGk2+9PVSncP ioQ4gAMkiNDYzaeCtWGOjZmFCEaN8yYKYwgYXyAHpPeP471Af5GDR7ZV9srWfOYI5pcx lO0e8Iqj35g7UEIs482kGkPkCIJGrRvyLnSpraR9dSXP51sqoddONM8GZLyAMmlZBMpp 9atA== MIME-Version: 1.0 X-Received: by 10.194.189.50 with SMTP id gf18mr30196339wjc.13.1405452085423; Tue, 15 Jul 2014 12:21:25 -0700 (PDT) Received: by 10.216.241.70 with HTTP; Tue, 15 Jul 2014 12:21:25 -0700 (PDT) In-Reply-To: <201407102156.s6ALuU4H058789@freefall.freebsd.org> References: <201407102156.s6ALuU4H058789@freefall.freebsd.org> Date: Tue, 15 Jul 2014 23:21:25 +0400 Message-ID: Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 9.2 EoL coming soon From: Sergey Kandaurov To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-announce@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 19:21:27 -0000 On 11 July 2014 01:56, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Everyone, > > On September 30, 2014, FreeBSD 9.2 will reach its End of Life and will > no longer be supported by the FreeBSD Security Team. And what about this part [1]: "Releases [...] will be supported by the Security Officer [...] for sufficient additional time (if needed) to ensure that there is a newer release for at least 3 months before the older Normal release expires." I parsed this as 9.2 should (could) be supported until after 3 months since 9.3-RELEASE. E.g., 9.0 support was extended as 9.1-RELEASE got delayed. [1] http://security.freebsd.org -- wbr, pluknet From owner-freebsd-security@FreeBSD.ORG Wed Jul 16 12:50:57 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8313CAF2 for ; Wed, 16 Jul 2014 12:50:57 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43D352486 for ; Wed, 16 Jul 2014 12:50:57 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id m20so717126qcx.0 for ; Wed, 16 Jul 2014 05:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=11MImhdof32Ch/AyuEK506KmYEOWl2Xz/CaIVi7YE/w=; b=XUW37uct6jA8GXULdTdbsBleFMxNIT9b7+qxWJdoaQb6MDKsG/GK3U8u6jn+SyO0fR NJREjtnKsk8yH2owgH2SlCzodml5ZaKlaB3frtrVqeg2C+lOcY5PjtA3GE/8+vSoos6a pcyQ6duxSYhOV5VdmkJmsRMRVcAr02u3VjzVl4UkJ7ulqvZ360j+fDMTY3RH3OmlEox2 nvCbtoCmxU4zcmm87DINBU+GCPZqOLlj5Y5GBMwG0/EZf+DTm5AxM+F7GposF7IquTSf Buo3hutfAumKZRq9aDCRQu2CC8wGJyfRr3vZDtGTB3H2HA096yjYGTErMOh/BuKR/6mN mUAA== MIME-Version: 1.0 X-Received: by 10.224.79.11 with SMTP id n11mt34079465qak.40.1405515056236; Wed, 16 Jul 2014 05:50:56 -0700 (PDT) Sender: spankthespam@gmail.com Received: by 10.229.88.68 with HTTP; Wed, 16 Jul 2014 05:50:56 -0700 (PDT) In-Reply-To: References: <201407102156.s6ALuU4H058789@freefall.freebsd.org> Date: Wed, 16 Jul 2014 13:50:56 +0100 X-Google-Sender-Auth: ir8e2VaOV_mFXPdMxqM_Fd9IAvk Message-ID: Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 9.2 EoL coming soon From: Bartek Rutkowski Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, freebsd-announce@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 12:50:57 -0000 On Tue, Jul 15, 2014 at 8:21 PM, Sergey Kandaurov wrote: > On 11 July 2014 01:56, Xin Li wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hello Everyone, >> >> On September 30, 2014, FreeBSD 9.2 will reach its End of Life and will >> no longer be supported by the FreeBSD Security Team. > > And what about this part [1]: > "Releases [...] will be supported by the Security Officer [...] for > sufficient additional time (if needed) to ensure that there is a newer > release for at least 3 months before the older Normal release expires." > > I parsed this as 9.2 should (could) be supported until after 3 months since > 9.3-RELEASE. E.g., 9.0 support was extended as 9.1-RELEASE got delayed. > > [1] http://security.freebsd.org > Given the extension announcement was just sent, I hope we'll remind users again, somwhere like 3 months and then again 1 month before the extended EoL happens. Shouldnt we also add it to the news section of the website so that it would be visible to more users? Kind regards, Bartek Rutkowski From owner-freebsd-security@FreeBSD.ORG Wed Jul 16 13:46:31 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88BA4F01; Wed, 16 Jul 2014 13:46:31 +0000 (UTC) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 474C62A49; Wed, 16 Jul 2014 13:46:30 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id EAAB376BC; Wed, 16 Jul 2014 13:46:29 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 7DE8360EE; Wed, 16 Jul 2014 15:46:08 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bartek Rutkowski Subject: Re: [FreeBSD-Announce] HEADS UP: FreeBSD 9.2 EoL coming soon References: <201407102156.s6ALuU4H058789@freefall.freebsd.org> Date: Wed, 16 Jul 2014 15:46:08 +0200 In-Reply-To: (Bartek Rutkowski's message of "Wed, 16 Jul 2014 13:50:56 +0100") Message-ID: <86y4vtto0v.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, freebsd-announce@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 13:46:31 -0000 Bartek Rutkowski writes: > Given the extension announcement was just sent, I hope we'll remind > users again, somwhere like 3 months and then again 1 month before the > extended EoL happens. Both Xin and I have reminders in our calendars :) > Shouldnt we also add it to the news section of the website so that it > would be visible to more users? Done. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no