From owner-freebsd-security@freebsd.org Mon Aug 22 09:25:00 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CD5ABC0D7B for ; Mon, 22 Aug 2016 09:25:00 +0000 (UTC) (envelope-from schmidt@ze.tum.de) Received: from mail.ze.tum.de (mail.ze.tum.de [IPv6:2001:4ca0:2e03::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.ze.tum.de", Issuer "Zertifizierungsstelle der TUM" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EE9C1FE6 for ; Mon, 22 Aug 2016 09:25:00 +0000 (UTC) (envelope-from schmidt@ze.tum.de) Received: from etustar.ze.tum.de ([IPv6:2001:4ca0:2e03:0:0:0:1:180]) by mail.ze.tum.de (8.15.2/8.15.2) with ESMTPS id u7M9OuuG099598 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Aug 2016 11:24:56 +0200 (CEST) (envelope-from schmidt@ze.tum.de) X-Authentication-Warning: hades.ze.tum.de: Host [IPv6:2001:4ca0:2e03:0:0:0:1:180] claimed to be etustar.ze.tum.de To: freebsd-security@freebsd.org From: Gerhard Schmidt Subject: Ports EOL vuxml entry Message-ID: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> Date: Mon, 22 Aug 2016 11:24:51 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SaWoUH4GHb0IQ0XSSDE3x4d2fER0KnVNd" X-Mailman-Approved-At: Mon, 22 Aug 2016 11:23:43 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 09:25:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SaWoUH4GHb0IQ0XSSDE3x4d2fER0KnVNd Content-Type: multipart/mixed; boundary="L6T2np12HcflSTa7cTIqE0NW7XNxe9IMQ" From: Gerhard Schmidt To: freebsd-security@freebsd.org Message-ID: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> Subject: Ports EOL vuxml entry --L6T2np12HcflSTa7cTIqE0NW7XNxe9IMQ Content-Type: multipart/mixed; boundary="------------75ECDDB58DA6C19B2F5BCC56" This is a multi-part message in MIME format. --------------75ECDDB58DA6C19B2F5BCC56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, today there was a new entry added to the vuxml file including all outdated ports. Where is the value in this Entry. The Information is already in the fact that the port has been removed. In this file should only are real vulnerabilities and not maybe vulnerable not existing ports. Right now this breaks my system to find vulnerable ports on my systems because all systems with legacy code show up with this entry. Please only add real vulnerabilities to this file. Maybe pkg audit should be print a warning (suppressible by a commandline switch or a whiltelist in the config file) when discontinued ports are installed. Putting all well known discontinued ports in a vuxml entry isn't a clean way to do it and creates a falls impression of security because all the not so well known discontinued ports are not in this list and users might depend on this warning. Regards Estartu --=20 ---------------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de Technische Universit=C3=A4t M=C3=BCnchen | Jabber: estartu@ze.tum.de WWW & Online Services | Tel: +49 89 289-25270 | PGP-PublicKey Fax: +49 89 289-25257 | on request --------------75ECDDB58DA6C19B2F5BCC56-- --L6T2np12HcflSTa7cTIqE0NW7XNxe9IMQ-- --SaWoUH4GHb0IQ0XSSDE3x4d2fER0KnVNd 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 iQIvBAEBCAAZBQJXusTjEhxzY2htaWR0QHplLnR1bS5kZQAKCRB00kPMRXANowxP EACVD6oHfeJVxrpLmM8HjDMYCdRV0yKVR16PeiSLTUb+OFc/ValcuQQjGq0GxcMn GrnpopvTJyswW5SB7D/euUWYHZXvt9GVryhAAGibnZzu5EUQWVzaf+VYg0N0929f KQdBGhHAHbYuaiQPqNuiBp/acyZ5Y8R75+GssoJViWBBe1u18YFe6RpM8hReq0lG hlLEBheavpS/3kcodDfiC9duRjybAaDL595NdlNRAImtrzL1HIf3Yy6SACY8/eL4 d9sv7qr3dKMQuR3Sk2Bl0PfaGnCT2qdPjpWWYfZ9ScnMEfljswvuO0eCetdo1uXV UgoRhw39G/apJVdu9B9OYVxvjrqZrSjA+ASuc5pXCccyWIDbedoBJax1GScLPq52 mKmCnWKx9NclSZyF45R42lnzWnh/oXjuko+48zy0b0sBF0+fs1pB8bvQV6+L5PS+ dEpAkWKc0PGObHMZ5S2A3I+G694TKbHfLX7mWwuK1WD9vuuC+enmlxoA2gDrSUeP aibIKHQ/vEyV9Bry7GY9QqMvedPw/WOfb+RwuyfGarCfnlVHHtvg706sDEV7I56n Z+gTXyeEbpGx/vvhOtXeUvlDmT7pkOqwiXgP3LtlmtLT8VmsZ4IWLBUyJm93IcNY SMUQlcQwTANEOA/4CB4CwVPJZLYykXarEKYwWKZp/Jmeug== =Mf28 -----END PGP SIGNATURE----- --SaWoUH4GHb0IQ0XSSDE3x4d2fER0KnVNd-- From owner-freebsd-security@freebsd.org Mon Aug 22 13:54:28 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82A12BC2899 for ; Mon, 22 Aug 2016 13:54:28 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6166B1705 for ; Mon, 22 Aug 2016 13:54:28 +0000 (UTC) (envelope-from marquis@roble.com) Date: Mon, 22 Aug 2016 06:54:20 -0700 (PDT) From: Roger Marquis To: Gerhard Schmidt cc: freebsd-security@freebsd.org Subject: Re: Ports EOL vuxml entry In-Reply-To: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 13:54:28 -0000 > today there was a new entry added to the vuxml file including all > outdated ports. Where is the value in this Entry. This is good news for many of us Gerhard, who depend on the output of 'pkg audit' for vulnerability information. > In this file should only are real vulnerabilities and not maybe > vulnerable not existing ports. You raise two issues here, A) what constitutes a 'real' vulnerability and B) how else would you be warned of probable vulnerabilities (due to unmaintained and unaudited code). There is 'pkg version' of course but few sites use this flag and fewer still use it for vulnerability information. > Right now this breaks my system to find vulnerable ports on my systems > because all systems with legacy code show up with this entry. Can you post details of how it breaks your system? > Maybe pkg audit should be print a warning (suppressible by a commandline > switch or a whiltelist in the config file) when discontinued ports are > installed. A command line switch to ignore deprecated, discontinued and otherwise unadited ports is an excellent idea though I don't think there will be much demand for it. A default 'warn if deprecated' will no doubt be the modal usage and benefit the larger community (who have until now been mislead by the output of 'pkg audit'). Thanks for the heads-up. Roger From owner-freebsd-security@freebsd.org Mon Aug 22 14:26:16 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E291EBC1A49 for ; Mon, 22 Aug 2016 14:26:16 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA651EFA for ; Mon, 22 Aug 2016 14:26:15 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.9/8.14.9) with ESMTP id u7MEFlHr028958; Mon, 22 Aug 2016 15:15:47 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id u7MEFlsr009161; Mon, 22 Aug 2016 15:15:47 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id u7MEFl8d009158; Mon, 22 Aug 2016 15:15:47 +0100 Date: Mon, 22 Aug 2016 15:15:47 +0100 Message-Id: <201608221415.u7MEFl8d009158@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-security@freebsd.org Subject: Unexplained update to /boot/boot1.efi and 2 others by freebsd-update X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 14:26:17 -0000 Running freebsd-update to convert 10.1-RELEASE-p36 to -p37 updates 3 efi files in /boot, but they are not mentioned in any security advisory or errata notice that I can find and no corresponding source files are updated. This is repeatable on several unrelated systems so I don't think my files have been corrupted. Is this expected? # freebsd-version -u 10.1-RELEASE-p36 # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching metadata signature for 10.1-RELEASE from update4.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /etc/ntp.conf The following files will be updated as part of updating to 10.1-RELEASE-p37: /bin/freebsd-version /boot/boot1.efi /boot/boot1.efifat /boot/loader.efi /usr/bin/bspatch /usr/sbin/freebsd-update /usr/src/sys/conf/newvers.sh /usr/src/usr.bin/bsdiff/bspatch/bspatch.c /usr/src/usr.sbin/freebsd-update/freebsd-update.sh __Martin From owner-freebsd-security@freebsd.org Mon Aug 22 20:01:50 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1F89BC242F for ; Mon, 22 Aug 2016 20:01:50 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id DD45A1A18 for ; Mon, 22 Aug 2016 20:01:50 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id C1B7A56488 for ; Mon, 22 Aug 2016 15:01:44 -0500 (CDT) Subject: Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh References: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> To: freebsd-security@FreeBSD.org From: Eric van Gyzen X-Forwarded-Message-Id: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> Message-ID: <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> Date: Mon, 22 Aug 2016 15:01:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 20:01:51 -0000 I had never looked at pam_ssh before. Does it really ignore authorized_keys and allow authentication using any of the default key file names? After a quick read of the code, that certainly seems to be the case. Does anyone else find that alarming? Sure, it's in my ~/.ssh directory and has appropriate permissions, but that doesn't mean I want to use it for authentication to this machine (or any machine sharing this home directory). That's what authorized_keys is for. I might have created it only to authenticate from this machine to another one. I might have even given it an empty passphrase because that other machine is disposable and I don't really care about it. Eric On 08/22/2016 14:27, Ollivier Robert wrote: > Author: roberto > Date: Mon Aug 22 19:27:20 2016 > New Revision: 304626 > URL: https://svnweb.freebsd.org/changeset/base/304626 > > Log: > Add support for Ed25519 keys. > > Reported by: mwlucas > MFH: 2 weeks > > Modified: > head/lib/libpam/modules/pam_ssh/pam_ssh.8 > head/lib/libpam/modules/pam_ssh/pam_ssh.c > > Modified: head/lib/libpam/modules/pam_ssh/pam_ssh.8 > ============================================================================== > --- head/lib/libpam/modules/pam_ssh/pam_ssh.8 Mon Aug 22 19:05:11 2016 (r304625) > +++ head/lib/libpam/modules/pam_ssh/pam_ssh.8 Mon Aug 22 19:27:20 2016 (r304626) > @@ -137,6 +137,8 @@ SSH2 RSA key > SSH2 DSA key > .It Pa $HOME/.ssh/id_ecdsa > SSH2 ECDSA key > +.It Pa $HOME/.ssh/id_ed25519 > +SSH2 Ed25519 key > .El > .Sh SEE ALSO > .Xr ssh-agent 1 , > > Modified: head/lib/libpam/modules/pam_ssh/pam_ssh.c > ============================================================================== > --- head/lib/libpam/modules/pam_ssh/pam_ssh.c Mon Aug 22 19:05:11 2016 (r304625) > +++ head/lib/libpam/modules/pam_ssh/pam_ssh.c Mon Aug 22 19:27:20 2016 (r304626) > @@ -81,6 +81,7 @@ static const char *pam_ssh_keyfiles[] = > ".ssh/id_rsa", /* SSH2 RSA key */ > ".ssh/id_dsa", /* SSH2 DSA key */ > ".ssh/id_ecdsa", /* SSH2 ECDSA key */ > + ".ssh/id_ed25519", /* SSH2 Ed25519 key */ > NULL > }; > > From owner-freebsd-security@freebsd.org Mon Aug 22 21:11:21 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BA83BC2654 for ; Mon, 22 Aug 2016 21:11:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3335B15AF; Mon, 22 Aug 2016 21:11:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 28059156D; Mon, 22 Aug 2016 21:11:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id D537C234DD; Mon, 22 Aug 2016 21:11:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 67A8dGN8-sRA; Mon, 22 Aug 2016 21:11:14 +0000 (UTC) Subject: Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 16892234D6 To: Eric van Gyzen , freebsd-security@FreeBSD.org References: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org> Date: Mon, 22 Aug 2016 14:11:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="38cujjGuRhgUVucI9fmWsUo3hqMCbWwH2" X-Mailman-Approved-At: Mon, 22 Aug 2016 22:45:37 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:11:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --38cujjGuRhgUVucI9fmWsUo3hqMCbWwH2 Content-Type: multipart/mixed; boundary="GQG4SG1ig2aUu6b4xI6tkbuxRBdMFQ1Lc" From: Bryan Drewery To: Eric van Gyzen , freebsd-security@FreeBSD.org Message-ID: <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org> Subject: Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh References: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> In-Reply-To: <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> --GQG4SG1ig2aUu6b4xI6tkbuxRBdMFQ1Lc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/22/2016 1:01 PM, Eric van Gyzen wrote: > I had never looked at pam_ssh before. Does it really ignore authorized= _keys and Yeah, that was the entire purpose! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D15158 For its original purpose I can understand using it, to login *locally*...= I am surprised to find this too. > allow authentication using any of the default key file names? After a = quick > read of the code, that certainly seems to be the case. Does anyone els= e find > that alarming? Sure, it's in my ~/.ssh directory and has appropriate > permissions, but that doesn't mean I want to use it for authentication = to this > machine (or any machine sharing this home directory). That's what > authorized_keys is for. I might have created it only to authenticate f= rom this > machine to another one. I might have even given it an empty passphrase= because > that other machine is disposable and I don't really care about it. At least it is off-by-default: > # grep -r pam_ssh /etc/pam.d|grep auth > /etc/pam.d/system:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/ftp:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/ftpd:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/telnetd:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/xdm:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/imap:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/other:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/sshd:#auth sufficient pam_ssh.so = no_warn try_first_pass > /etc/pam.d/pop3:#auth sufficient pam_ssh.so = no_warn try_first_pass The implications of uncommenting these are not explained in the files though. The manpage has this gem: "nullok Normally, keys with no passphrase are ignored for authentication purposes. If this option is set, keys with no passphrase will be taken into consideration, allowing the user to log in with a blank password." Why would anyone ever use nullok and use the pam_ssh module? I don't know pam well but I'm sure there's another way to make a check always succeed without a password. So supporting nullok in pam_ssh is just asking for an unknown security bug. I would really like to see nullok support removed from pam_ssh. Why is it even in the remote service files as an example when it is dangerous in those contexts? I find the pam configuration files overly complex and error-prone to begin with, but to discover that there's such a bombshell sitting there is concerning. >=20 > Eric >=20 > On 08/22/2016 14:27, Ollivier Robert wrote: >> Author: roberto >> Date: Mon Aug 22 19:27:20 2016 >> New Revision: 304626 >> URL: https://svnweb.freebsd.org/changeset/base/304626 >> >> Log: >> Add support for Ed25519 keys. >> =20 >> Reported by: mwlucas >> MFH: 2 weeks >> >> Modified: >> head/lib/libpam/modules/pam_ssh/pam_ssh.8 >> head/lib/libpam/modules/pam_ssh/pam_ssh.c >> >> Modified: head/lib/libpam/modules/pam_ssh/pam_ssh.8 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> --- head/lib/libpam/modules/pam_ssh/pam_ssh.8 Mon Aug 22 19:05:11 2016= (r304625) >> +++ head/lib/libpam/modules/pam_ssh/pam_ssh.8 Mon Aug 22 19:27:20 2016= (r304626) >> @@ -137,6 +137,8 @@ SSH2 RSA key >> SSH2 DSA key >> .It Pa $HOME/.ssh/id_ecdsa >> SSH2 ECDSA key >> +.It Pa $HOME/.ssh/id_ed25519 >> +SSH2 Ed25519 key >> .El >> .Sh SEE ALSO >> .Xr ssh-agent 1 , >> >> Modified: head/lib/libpam/modules/pam_ssh/pam_ssh.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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> --- head/lib/libpam/modules/pam_ssh/pam_ssh.c Mon Aug 22 19:05:11 2016= (r304625) >> +++ head/lib/libpam/modules/pam_ssh/pam_ssh.c Mon Aug 22 19:27:20 2016= (r304626) >> @@ -81,6 +81,7 @@ static const char *pam_ssh_keyfiles[] =3D=20 >> ".ssh/id_rsa", /* SSH2 RSA key */ >> ".ssh/id_dsa", /* SSH2 DSA key */ >> ".ssh/id_ecdsa", /* SSH2 ECDSA key */ >> + ".ssh/id_ed25519", /* SSH2 Ed25519 key */ >> NULL >> }; >> =20 >> --=20 Regards, Bryan Drewery --GQG4SG1ig2aUu6b4xI6tkbuxRBdMFQ1Lc-- --38cujjGuRhgUVucI9fmWsUo3hqMCbWwH2 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 iQEcBAEBAgAGBQJXu2pxAAoJEDXXcbtuRpfPGQYIAJjl9ZPETowtVFZb611X3zHu IkI6Dy+WCrVf0bhRL2gVaePBKGjcNNoO/uCr01ieierZwvsgmoABPtN2+m49rW1l cYVgTBt39mO9aUN+JzN+uSBT7BRzqW/eAJ07ECKGSQWK/9JXP8mK3i3MvJMOkzAl 8tlLrw+pMJaE9cEOUuhEqXvd5tZbzDl0YzEErzRh2dWLNYfFwHxAqNhbGRMcMWsx vEctg76H/u1zRqvkrg4q2eGAMYzBfqNeqbx84cJ7mI2zuZVvjI7Jlp3psKz/gWjo Bbchky6ADpd4mv2jEmTse1IUJUSm/xEOEhHPJOB30Bb+ByXrsgme24U+9zHuc+I= =Ldk3 -----END PGP SIGNATURE----- --38cujjGuRhgUVucI9fmWsUo3hqMCbWwH2-- From owner-freebsd-security@freebsd.org Mon Aug 22 23:06:47 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D29BC229F for ; Mon, 22 Aug 2016 23:06:47 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9C91D27; Mon, 22 Aug 2016 23:06:46 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5407D56488; Mon, 22 Aug 2016 18:06:45 -0500 (CDT) Subject: pam_ssh and default key file names [was: Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh] To: Bryan Drewery , freebsd-security@FreeBSD.org References: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org> From: Eric van Gyzen Message-ID: Date: Mon, 22 Aug 2016 18:06:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 23:06:47 -0000 On 08/22/2016 16:11, Bryan Drewery wrote: > On 8/22/2016 1:01 PM, Eric van Gyzen wrote: >> I had never looked at pam_ssh before. Does it really ignore authorized_keys and > > Yeah, that was the entire purpose! > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15158 Ah, thanks for that research. > For its original purpose I can understand using it, to login *locally*... Yeah, pam_ssh makes sense for local logins, but even then I still find it alarming that it looks at all default key file names. If I change pam_ssh to only use authorized_keys, I would be adding the assumption that users authenticate with the same keys over ssh as on the console. The current pam_ssh code allows different keys (viz. authorized_keys versus id_foo). This seems like a perfectly reasonable assumption. I'd like to hear whether this would break anyone's deployment of pam_ssh. If so, I'd also like to hear a strong argument for such a use case. I might have to ask on, say, questions@ to get a wider audience. > I am surprised to find this too. Thanks for confirming my remaining sanity. :) > At least it is off-by-default: Indeed. > The manpage has this gem: > "nullok Normally, keys with no passphrase are ignored for > authentication purposes. If this option is set, keys with no passphrase > will be taken into consideration, allowing the user to log in with a > blank password." > > Why would anyone ever use nullok and use the pam_ssh module? I don't > know pam well but I'm sure there's another way to make a check always > succeed without a password. So supporting nullok in pam_ssh is just > asking for an unknown security bug. Yes, I also don't like nullok here. There are use cases for a private key without a password, but this is not one of them. > Why is it even in the remote service files as an example when it is > dangerous in those contexts? Good point. I'll remove it from the dangerous examples (unless you beat me to it, since it's time for supper). ;) Eric From owner-freebsd-security@freebsd.org Tue Aug 23 00:28:23 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE416BB7713 for ; Tue, 23 Aug 2016 00:28:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C89FA11FF for ; Tue, 23 Aug 2016 00:28:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u7N0SMWZ048859 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Aug 2016 17:28:22 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u7N0SLke048858; Mon, 22 Aug 2016 17:28:21 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 22 Aug 2016 17:28:21 -0700 From: Gleb Smirnoff To: Martin Simmons Cc: freebsd-security@freebsd.org Subject: Re: Unexplained update to /boot/boot1.efi and 2 others by freebsd-update Message-ID: <20160823002821.GJ1069@FreeBSD.org> References: <201608221415.u7MEFl8d009158@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201608221415.u7MEFl8d009158@higson.cam.lispworks.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 00:28:24 -0000 Martin, On Mon, Aug 22, 2016 at 03:15:47PM +0100, Martin Simmons wrote: M> Running freebsd-update to convert 10.1-RELEASE-p36 to -p37 updates 3 efi files M> in /boot, but they are not mentioned in any security advisory or errata notice M> that I can find and no corresponding source files are updated. This is M> repeatable on several unrelated systems so I don't think my files have been M> corrupted. M> M> Is this expected? The freebsd-update build code attempts to extract and ignore timestamps in order to determine whether files are 'really' changing between builds; unfortunately these particular files contain a build artifact which the freebsd-update code was not able to handle, thus resulting in them being incorrectly identified as needing to be distributed. So, this shouldn't have happened. But don't worry the files aren't forged and they do originate from the official freebsd-update server. -- Totus tuus, Glebius. From owner-freebsd-security@freebsd.org Tue Aug 23 06:23:13 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F9C7BC3C8C for ; Tue, 23 Aug 2016 06:23:13 +0000 (UTC) (envelope-from estartu@ze.tum.de) Received: from mail.ze.tum.de (mail.ze.tum.de [IPv6:2001:4ca0:2e03::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.ze.tum.de", Issuer "Zertifizierungsstelle der TUM" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C785A120C for ; Tue, 23 Aug 2016 06:23:12 +0000 (UTC) (envelope-from estartu@ze.tum.de) Received: from etustar.ze.tum.de ([IPv6:2001:4ca0:2e03:0:0:0:1:180]) by mail.ze.tum.de (8.15.2/8.15.2) with ESMTPS id u7N6N82t077671 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2016 08:23:08 +0200 (CEST) (envelope-from estartu@ze.tum.de) X-Authentication-Warning: hades.ze.tum.de: Host [IPv6:2001:4ca0:2e03:0:0:0:1:180] claimed to be etustar.ze.tum.de Subject: Re: Ports EOL vuxml entry To: Roger Marquis , freebsd-security@freebsd.org References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> From: Gerhard Schmidt Reply-To: schmidt@ze.tum.de Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_M=c3=bcnchen_-_WWW_und_O?= =?UTF-8?Q?nline_Services?= Message-ID: Date: Tue, 23 Aug 2016 08:23:08 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 06:23:13 -0000 Am 22.08.2016 um 15:54 schrieb Roger Marquis: >> today there was a new entry added to the vuxml file including all >> outdated ports. Where is the value in this Entry. > > This is good news for many of us Gerhard, who depend on the output of > 'pkg audit' for vulnerability information. Is an outdated (EOL) port a vulnerability? I don't think so. It's a possible vulnerability, but not a real one. >> In this file should only are real vulnerabilities and not maybe >> vulnerable not existing ports. > > You raise two issues here, A) what constitutes a 'real' vulnerability > and B) how else would you be warned of probable vulnerabilities (due to > unmaintained and unaudited code). There is 'pkg version' of course but > few sites use this flag and fewer still use it for vulnerability > information. A real vulnerability is a bug in the software that allows a attacker to gain access to a system or a higher level of access on a system. Most code is really unaudited. Many of the recent security problem where in well maintained code. So saying that unaudited and unmaintained code is a vulnerability is wrong. It's a security risk. But the vuxml database is not about security risks. It's about actual and proven vulnerabilities. >> Right now this breaks my system to find vulnerable ports on my systems >> because all systems with legacy code show up with this entry. > > Can you post details of how it breaks your system? I'm monitoring my FreeBSD Servers (about 60 of them) with icinga an have a test that queries pkg audit if any of the installed packages are vulnerable. I have some servers that run legacy code that still needs python24. Every one of this machines reports right now that there is a vulnerable package installed and there is no way to tell pkg audit to stop reporting it. Sure i can filter python24 from the pkg audit output so it doesn't trigger the warning. But if a real vulnerability is reported for python24 i don't get it. I know that's a theoretical possibility, but still it reduces my systems reliability. >> Maybe pkg audit should be print a warning (suppressible by a commandline >> switch or a whiltelist in the config file) when discontinued ports are >> installed. > > A command line switch to ignore deprecated, discontinued and otherwise > unadited ports is an excellent idea though I don't think there will be > much demand for it. A default 'warn if deprecated' will no doubt be the > modal usage and benefit the larger community (who have until now been > mislead by the output of 'pkg audit'). As stated in the original mail. Outdated unmaintained ports should not be part of the vulnerability Database because they are no vulnerability. They are a different kind of Security risk and pkg audit should report them by default as that, but not as vulnerability. There should be a way to state that the sysadmin is aware of the outdated port and prevent pkg audit from reporting it over and over again. We could do that easily in the pkg.conf. A line like ignore_outdated=python24 would be sufficient. Regards Estartu -- ---------------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de Technische Universität München | Jabber: estartu@ze.tum.de WWW & Online Services | Tel: +49 89 289-25270 | PGP-PublicKey Fax: +49 89 289-25257 | on request -- ------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de TU-München | Jabber: estartu@ze.tum.de WWW & Online Services | Tel: 089/289-25270 | Fax: 089/289-25257 | PGP-Publickey auf Anfrage From owner-freebsd-security@freebsd.org Tue Aug 23 13:15:31 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAF2FBC315F for ; Tue, 23 Aug 2016 13:15:31 +0000 (UTC) (envelope-from weldon@excelsusphoto.com) Received: from veyron.excelsus.com (emmett.excelsus.com [74.93.113.252]) (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 A675B1E41 for ; Tue, 23 Aug 2016 13:15:29 +0000 (UTC) (envelope-from weldon@excelsusphoto.com) Received: from localhost (localhost [127.0.0.1]) by veyron.excelsus.com (Postfix) with ESMTP id 6B33214F0 for ; Tue, 23 Aug 2016 08:08:22 -0500 (CDT) Received: from veyron.excelsus.com ([127.0.0.1]) by localhost (mail.excelsus.com [127.0.0.1]) (maiad, port 10024) with ESMTP id 39220-03 for ; Tue, 23 Aug 2016 08:08:12 -0500 (CDT) Received: by veyron.excelsus.com (Postfix, from userid 80) id 816FE14ED; Tue, 23 Aug 2016 08:08:12 -0500 (CDT) To: freebsd-security@freebsd.org Subject: Re: Ports EOL vuxml entry X-PHP-Originating-Script: 0:rcube.php MIME-Version: 1.0 Date: Tue, 23 Aug 2016 08:08:12 -0500 From: Weldon Godfrey Message-ID: <80eda92991512e9c50915536e7793396@excelsusphoto.com> X-Sender: weldon@excelsusphoto.com User-Agent: Roundcube Webmail/1.2.0 X-Virus-Scanned: Maia Mailguard X-Mailman-Approved-At: Tue, 23 Aug 2016 14:01:49 +0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 13:15:31 -0000 Gerhard Schmidt wrote: > Is an outdated (EOL) port a vulnerability? I don't think so. It's a > possible vulnerability, but not a real one. An EOL product is typically no longer tracked, analyzed, and corrected for security vulnerabilities. With this higher risk profile, it is correct to assume it is vulnerable or at least a higher security risk. Since a clean report from pkg audit with EOL packages on the system will mislead the vast majority of end-users that they have a lower risk security profile. It is correct for pkg audit to warn on EOL packages. Especially since any actual vulnerabilities, that is almost certain to come up, will likely never show on a future report. From owner-freebsd-security@freebsd.org Tue Aug 23 15:02:50 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80F1EBC3434 for ; Tue, 23 Aug 2016 15:02:50 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EAAF123D for ; Tue, 23 Aug 2016 15:02:50 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id y134so44577188pfg.0 for ; Tue, 23 Aug 2016 08:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kH19lsfnXcT8QjRlL8ZaDmwt5+79+ekznZIWvmCydDU=; b=HkQ4PImw4ucWaQ3zEAOIueildFbysBOuTjhX1I2mNVYpHaFiGQquESf01cplKH1ZOO 7HymfMMRAYsZvRInivJ3ugulSJmxK5k4UwFwn6QE/PnZCCut/roI2x4nOlBP5V5wRb18 ixxD/IqprWqyLffB0aX/+g644xvm8SOcf6q8d5KjJFSWUW6j5H7+KtWBe0gOoPxPrPc1 Y9w6jbncEPfLEKV56/kkGqKNv3jcwzSq8MoEhW6RSSVWVOK/48B58n3NNyqT2So4ZWgh YofM15egDdefHjuNGT1ObWFsOlQOTCtGuZLAs5so81xOQ4Y0IflRCtzDe6fvG7ATyNLk jh+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=kH19lsfnXcT8QjRlL8ZaDmwt5+79+ekznZIWvmCydDU=; b=mZ3t0lfsZvY7c41kCvyu5VPEFLZvuBadIL/lnyAwOPX+ov3uuYt6c96fXf/AXfCObT urITntMYea46fihltAnZLMPtpAjbBHdPYHcQsNiB5sICPspDgDeUhBaTmA6PyLdU5+sZ K8J9db9tpf5HC6uRRT+ro1SYKk4Ar6ZxBJ6OptYCbNwtWQKxOYysavnTJsaMeL0/2e88 cydW/FJ6Bf1Ik4KB8ZLuJlDYHihY9p28BndQZHebNAvy9P0NVYFHsJVd0kEXTaTFlg0o 9nSueLrANO322BhHu5vFkLWu052auOhYP/hDiK0QrFz+kpj5a/ZqN9vRaCbCVB9Rbtjt aDrg== X-Gm-Message-State: AEkoousBLLhpTFAHa/aPkuSlk4WW7ekHoH8rd4byEMWPg8pQWHth6/mUGWM6OMNK/htQXw== X-Received: by 10.98.192.144 with SMTP id g16mr54613615pfk.55.1471964569208; Tue, 23 Aug 2016 08:02:49 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b01:1c1a:5103:265d:bfaf? (2001-44b8-31ae-7b01-1c1a-5103-265d-bfaf.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:1c1a:5103:265d:bfaf]) by smtp.gmail.com with ESMTPSA id y9sm6526841pay.25.2016.08.23.08.02.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Aug 2016 08:02:48 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Ports EOL vuxml entry References: <80eda92991512e9c50915536e7793396@excelsusphoto.com> To: Weldon Godfrey , freebsd-security@freebsd.org From: Kubilay Kocak Message-ID: <8a222379-442d-b77d-e96d-27a556f798df@FreeBSD.org> Date: Wed, 24 Aug 2016 01:02:42 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Thunderbird/50.0a2 MIME-Version: 1.0 In-Reply-To: <80eda92991512e9c50915536e7793396@excelsusphoto.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:02:50 -0000 On 23/08/2016 11:08 PM, Weldon Godfrey wrote: > Gerhard Schmidt wrote: > >> Is an outdated (EOL) port a vulnerability? I don't think so. It's >> a possible vulnerability, but not a real one. > > An EOL product is typically no longer tracked, analyzed, and > corrected for security vulnerabilities. With this higher risk > profile, it is correct to assume it is vulnerable or at least a > higher security risk. Since a clean report from pkg audit with EOL > packages on the system will mislead the vast majority of end-users > that they have a lower risk security profile. It is correct for pkg > audit to warn on EOL packages. Especially since any actual > vulnerabilities, that is almost certain to come up, will likely never > show on a future report. This (good) argument sounds primarily about classification and/or the ability or lack thereof to distinguish between types-of-things, which are not identical: * Explicit vulnerability ("Active", Official record (CVE, etc), will or likely/expected to be fixed) * Implicit (probable) vulnerability (by way of EoL, no fixes/support, may have CVE (forever), port/pkg deleted, etc) VuXML is about declaring/documenting vulnerabilities yes, but it's also about arming users with the information they need to make sound security decisions. Being prescriptive in *either* case is not really telling the full truth and feels unsatisfying. If and when we delete ports/packages of still-upstream-supported software (say they are BROKEN in latest FreeBSD versions) that have an active CVE's now or ever in the future, are they "vulnerable" according to what we want if a user has them installed? Should they be listed? Having said that, VuXML is a 'vulnerability markup language', and without an actual and explicit 'vulnerability', should it be listed? On solutions, perhaps this is a simple matter of --exclude-{deleted,eol,} or similar in pkg audit to tell the difference, allowing the user to make *note* of differences, and decide accordingly. I shall avoid the bikeshed on what the default should be. Or maybe an EoLXML. Read this generically as: a second or multiple data 'sources' for pkg audit, for auditing different things. Just free thinking here. ./koobs From owner-freebsd-security@freebsd.org Tue Aug 23 15:50:51 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6271BBC2017 for ; Tue, 23 Aug 2016 15:50:51 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 475FB17D0 for ; Tue, 23 Aug 2016 15:50:50 +0000 (UTC) (envelope-from marquis@roble.com) Date: Tue, 23 Aug 2016 08:50:44 -0700 (PDT) From: Roger Marquis To: schmidt@ze.tum.de cc: freebsd-security@freebsd.org Subject: Re: Ports EOL vuxml entry In-Reply-To: References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:50:51 -0000 > Is an outdated (EOL) port a vulnerability? I don't think so. It's a > possible vulnerability, but not a real one. Exactly. The meta-discussion we're having is regarding the word 'audit' (in 'pkg audit'). When you or I audit a server or a site the client always wants to know about potential vulnerabilities as well as known ones. This is because the deliverable is a measure of risk, not just proven risks but also potential risks. Even the commercial scanning tools (Tripwire, Qualis ...) report on potential vulnerabilities as well as those documented in CVEs. > I have some servers that run legacy code that still needs > python24. Every one of this machines reports right now that there is a > vulnerable package installed and there is no way to tell pkg audit to > stop reporting it. If my reading of is correct python24 has documented vulnerabilities. This is expected of deprecated software and the reason many of us want to know which installed packages are deprecated when we run 'pkg audit'. > Sure i can filter python24 from the pkg audit output so it doesn't trigger > the warning. Why not just 'grep vulnerable' if that's your goal, or 'grep -v deprecated' (or use a pkg flag to that effect if and when one becomes available)? > They are a different kind of Security risk and pkg audit should report > them by default as that, but not as vulnerability. But it's not reporting them as vulnerable, it is reporting them as deprecated or unmaintained. > There should be a way to state that the sysadmin is aware of the > outdated port and prevent pkg audit from reporting it Agreed though I expect such a report would see little use. Roger From owner-freebsd-security@freebsd.org Wed Aug 24 04:12:00 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4757BC456E for ; Wed, 24 Aug 2016 04:12:00 +0000 (UTC) (envelope-from zingelman@fnal.gov) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0138.outbound.protection.outlook.com [23.103.200.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 511341C6B for ; Wed, 24 Aug 2016 04:11:59 +0000 (UTC) (envelope-from zingelman@fnal.gov) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fermicloud.onmicrosoft.com; s=selector1-fnal-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AlaA7nOPBIExtd6ze8DJzsQrFyZ+UllC5OVNW2BJMCg=; b=gV0aBUTNF97i5X4uPUjh4DPfbY42jdB5NyF0bDutYC6jPXQdgE4tO6JROZCMPR+fCHXV6JLjbW2KMxSOlEDNk2SZN8lEAZlwnRCMM5wpmBR50F/848e1VVqJ+x9ZwBoiRJyS4zg7PVAU5VANq8tpzg31Or67XHddQ8Fywg8A9IM= Received: from DM2PR09CA0004.namprd09.prod.outlook.com (10.160.127.14) by SN1PR09MB0765.namprd09.prod.outlook.com (10.162.2.26) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Tue, 23 Aug 2016 16:37:25 +0000 Received: from BN1BFFO11FD049.protection.gbl (2a01:111:f400:7c10::1:179) by DM2PR09CA0004.outlook.office365.com (2a01:111:e400:3c14::14) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13 via Frontend Transport; Tue, 23 Aug 2016 16:37:18 +0000 Authentication-Results: spf=pass (sender IP is 131.225.70.94) smtp.mailfrom=fnal.gov; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=bestguesspass action=none header.from=fnal.gov; Received-SPF: Pass (protection.outlook.com: domain of fnal.gov designates 131.225.70.94 as permitted sender) receiver=protection.outlook.com; client-ip=131.225.70.94; helo=smtp-ux-prd1.fnal.gov; Received: from smtp-ux-prd1.fnal.gov (131.225.70.94) by BN1BFFO11FD049.mail.protection.outlook.com (10.58.145.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.587.6 via Frontend Transport; Tue, 23 Aug 2016 16:37:19 +0000 Received: from nova.fnal.gov (nova.fnal.gov [131.225.121.207]) by smtp-ux-prd1.fnal.gov (Postfix) with SMTP id 43194E060F; Tue, 23 Aug 2016 11:37:18 -0500 (CDT) Received: from nova.fnal.gov (localhost [127.0.0.1]) by nova.fnal.gov (8.14.4+Sun/8.14.4) with ESMTP id u7NGbItL026468; Tue, 23 Aug 2016 11:37:18 -0500 (CDT) Received: from localhost (tez@localhost) by nova.fnal.gov (8.14.4+Sun/8.14.4/Submit) with ESMTP id u7NGbIBM026465; Tue, 23 Aug 2016 11:37:18 -0500 (CDT) X-Authentication-Warning: nova.fnal.gov: tez owned process doing -bs Date: Tue, 23 Aug 2016 11:37:18 -0500 From: Tim Zingelman X-X-Sender: tez@nova.fnal.gov Reply-To: Tim Zingelman To: "freebsd-security@freebsd.org" CC: Roger Marquis , "schmidt@ze.tum.de" Subject: Re: Ports EOL vuxml entry In-Reply-To: <8e50a727e71a444f9b2ccaa4844221f9@MWHPR09MB1359.namprd09.prod.outlook.com> Message-ID: References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> <8e50a727e71a444f9b2ccaa4844221f9@MWHPR09MB1359.namprd09.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-559023410-1804928587-1471969389=:25496" Content-ID: X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:131.225.70.94; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(438002)(24454002)(189002)(129404003)(199003)(4610100001)(43066003)(50986999)(54356999)(8936002)(76176999)(53806999)(246002)(2906002)(2501003)(110136002)(5890100001)(3480700004)(19580395003)(19580405001)(5000100001)(8676002)(356003)(87936001)(189998001)(586003)(568964002)(60046009)(2476003)(4326007)(41446006)(86362001)(5660300001)(93886004)(2950100001)(5009310100001)(7596002)(305945005)(626004)(512954002)(106466001)(3450700001)(5640700001)(76506005)(7846002)(84326002)(57986006)(11100500001)(2351001)(7636002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR09MB0765; H:smtp-ux-prd1.fnal.gov; FPR:; SPF:Pass; PTR:smtp-ux-prd1.fnal.gov; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD049; 1:xZNeUBn+3f6twRUaGyKYUfYu/CNL2LS8+aBhpf1LU9W9TB2zVLemKxMDQrpMJY6m+HvPTu3tEWPjW9u9FLBIxi7jVwM5vs+v3zzl4QNeNapX0MU0irfm5EQhefeRkU0EohVR543Ypo4wu4bcCafN3H12TD0Leuxq5MTQ8VMFI11FmY0hm+8HVb5MCIz+swzLx1qbMj64r++IIpV3PWeeZh4cdHWEmKJQ5nepMQRCe9rxykd7ZriKXIUTXjtg06nRrObiFmx06Aj/x6YdTsxqoKguUyYe1ArQG+7DVQqbXFVxMEAA3tHBEvbKZvL9fKw0bQpXVan867gxqAEREagLzgzf6VnXlHFvIMEzb556LDOOU8SVPNuwoXUjamH7ao3pxxrVavstlg+5I3r9ZWIU4a6+bv501nDF48s3vb7Y3MpZOkO5BXbwt+H+ue9gz8HJJWltzDoCHcEgZ4bFXEpGF19Lxtm//+hPeICtrx1QkjXDhpoT6umI+93hjcJ5rfMTIOvYFT4k0VAO1C+tr5IIbwKZFX/gVuUtQD9+AzMksFpdhu81EUY5xcRPs8J/gmSt X-MS-Office365-Filtering-Correlation-Id: 49afaa2f-99e9-4c8a-e050-08d3cb73c010 X-Microsoft-Exchange-Diagnostics: 1; SN1PR09MB0765; 2:QCpX5OArwkU7B/YqjurYg7wshZ+z2GN7NkZoaIpQD10cxYk45Bn8xmocFf+96crl620ClK4Arvo1RIyrYNnI8mAege05pd6m1k62AeMi7lYsLdePUA6Su+LLdCFiEdKp6NL+1+JVVdT3x/vMAdnc9KWHsElpHsPfTkBzxjeiqZjNGSmXqUgj9guAR2f/AjFg; 3:2HS2GBtXQi4d7Z4h9aKxKCa71KHqSFsv+zc4K7j+31Ptc3tcLzaP6dkVER1zJwTIhdO01jMVOoYU8GPun+Ve2rK0rVYfbQdYND+GDqXebNC4acGNayb+9PRLFEb5YL/tqdysgHuNoO19dXiwHVSAxNTBJpou3ehP/nakHQi/zsdyNs3Bap6FLVKLCFWc6XL4/LRCq4Ro3hpIl1JE/lPcBtsQEvF407NCybpuNQp3U/0s1v46jgnymb6kIWe40agAhaFGl1xm04GeyZM04WZg+w==; 25:nphGy+URx9S6NFfEh4F/q3985iBlD1PtkXuHS4YxtpfiKkG2AGRWh/R0Xci8D4a2W9hQqoh2STtNL8xTv4UlFYEsgkGFdfLUwpHcfjA4+nN2Iys2PtPPRW/MGUbVwMoEY3Iz0NB27nGCJUi+M+1GPnh1/bezxXWmzTFMOIjgFGprr+JwCGmlUz2SbHuKc07tYo2RZN7XeMTLKJNfYtnx6Sn9XDcY4MVp3JtoEfITjJh60tZ2wrT/DbVaEHyE4G9d2vzBDk6cg/fbkQ7BahytKNefi2mxbkC8k/bgxYsxitWm5kiJT/ePQEFyM/PGXewn8HHzjZl7+ac9hQfYFleTNcjUFKtNoIjcbBU2bm0ymY+fqjwYa1TKWi966lr95eTdkoAGdueb3X8x8YUAC6R+4D/VbpKuZnkxlld5TZIKI6zaMq8uBUAe88Cu6UGaxRuGbJ1giwabnxQfZtz9GEeg1zrOXIgC7isUkSp9Zr+Tbps= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:SN1PR09MB0765; X-Microsoft-Exchange-Diagnostics: 1; SN1PR09MB0765; 31:yVWK08EG3pvU/0jutZ2TtppGMWPDaWFB61KvEwtwwNY2eDgDPMXihd9iucGOb0hSJnt+7QFNWVx/ZP6fctzvmf8lcpLZaEX4f+jiwRdoGd59WWWtff2U0cCZDSV2HgJvMJPvYiJlVnlyf9BH3MOO7a1NUkHl4ZmWwF+w9xmlIuAAClffX/B0yLYYxDaqE92O4k/+lDxq+uvHoaE155IEvHzDjd9I08ebLvgxvWDbt8a+t7u6PjpcpEeY6jTfbdWz; 20:JcRZdGBwO+Y7NizzVtmetOSZ8rmh4HYStEjJtIG3mkANnkrG0qeYBtGv5g/uO6bLV+/KSI9jWIFIxSfDkcALUzy+gKhBkUwNq25QNPpl3WhtKxem1rMEYircUbo2zcIvyxlxyXM4W4KVlgfZM1cgXgqI2IbwT/T9esD43uHpQ/j0bOEqjaxH/VRemc+dMPEUdXKM1b6wUvVGX7MhC4raWWuu9/Ym2H9lMZJd1e3TG2ywcjTAfOj3lMik7Q/rcjLkxthEJ7EDmYmczPX+8yUIIRKdeBDVQ+/qafF5icbhzWP+42/AQJNZ1hPkEVQCPjaMb22ChJCrE7GCdbZxql/Bj30ORvh/0/R72v3MnlrJbJNcbovNbvLgFLXjcjiD9klqlUsmnX/7Wurrp3I/E5rqNxkE/ZzzZC3/plB40ds6uDue9dSOWZnUpSayjxizhRcoRIYTq1JePYQYkBGu8++zCU4bKxysZaURXmGyzQ4G7JZa8WD4OemGEvXo7ZHYVbEB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(40475595445134)(211171220733660); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(13015025)(13017025)(13023025)(13024025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR09MB0765; BCL:0; PCL:0; RULEID:; SRVR:SN1PR09MB0765; X-Microsoft-Exchange-Diagnostics: 1; SN1PR09MB0765; 4:wvcYxN1yzXuS5pw3mj96jhjBSgQfusMwO6D3ZZGXZKLrfhLI3vkvKX4872Sggg0sKEUjv6BPVgdl72GXrvVGuZ8Aww8+GI0F8FscpiWitZ5TR5d3CXCZe9TCYK2zKp3rEbQN+yPgx/mJu/kBTZy5EybePhZRZTFN9Dcmc6YTxBMxsGrauQHYF9waz+ibpRsV5fBeRIm7AV30vJ5yG/6Mmeb9LLkhy3hdKV02Z7sXaSkBEFvyCoXeOLOW2PJUDrfKqG03OGJ2grZxybtdDKbGX5UgMvrqXHMGUnXxSKIPYQ4NkiYHmIhIjSWDWsvkfpGWY4OoR4XOHBaBUPXloIyH1W5eaMq0L9M5rWTjuewpMQ98pdQRQUHNHN2IJMc7XdFUzKY/DJOlZ1A2PKaaevLKmDXtz9MpoiAEWM0zCc29U/h7EncoSvf9cPqTjCIeMgdKCLl7VFlbc0Q6tRK+RRQCZ/Sfv5k3MsCzZQhifkffBM2EKLA5d7lcIfFFrm7dwjHTY5D97VDYZo8vxVvCqalTV8mGBx07KSADp9JMaYA37vNLUZyDS1qxY+wDqv8zGHTN6vIPfK0ZSoNgtjdfsKRYxk/2JnIJaBwsHkCl760iUS8= X-Forefront-PRVS: 004395A01C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR09MB0765; 23:qXe2VTCHE4W36eX0nd7uST/rMl77jXvj/01UgAE3f?= =?us-ascii?Q?lyTVCzenx+mCB/0YWx82mf0mzPJNAUr1REjEFCxXLOZJrvKG0ppuiGtjDbNw?= =?us-ascii?Q?8PeFdsuJt2SuQSxdbi0R6FiA+4dIiDO3JneiXQz8qoKnb4cn+Lj5w+qfPaej?= =?us-ascii?Q?l4U1q4rcXta1fmPTBqzUiyoyg+DycGNXKWacZ0aGwpJk4eF0AZjv3intyivk?= =?us-ascii?Q?fI373NPtCPPUnA68w/+EcYKbiJrULZ9k0BQe6+teIdpKXrDwyXNs44t9qKFD?= =?us-ascii?Q?M28sHTtOptRjCW3TSR4n/6SCps/ax4tsGtVUOTdtPoMPV2XpZURFYt8a1/pN?= =?us-ascii?Q?GCjAlyj6U+D6zRh6+syBsKIQP1GCkU6ZfjtfeSA4eVK2S24izY4kVlUiZW57?= =?us-ascii?Q?afdasiBb1cvVDTilmN5nHmuAVjrYwTY8hvZh28sUcCX0aaAXJgr+yn96e14S?= =?us-ascii?Q?w8SZj7yki7YVRa1wdJUbT1d7raXp2YsxSWIwEy7/FXZQAxNPoDalvdffv7NP?= =?us-ascii?Q?Smub/8qCz+zSekxbVan6q9BpS0ZSyfhh5frRJQwuUxuZ15qtRwpQ6Sx1sLfX?= =?us-ascii?Q?BWb3erY+STwxY71Ox/R93BZXAzDsW9gd04J3HkKo56ejK2mcMq4i+JWP2IIo?= =?us-ascii?Q?IW2JlNjHBRrd6Xz1PyK+wZRtcCnNctEtXFNgygVBDfL3wJtp3NnuDzriLEGJ?= =?us-ascii?Q?hMZQ7AvqUZGPdsReJrDMxZgx2Cv9jG7L55C325fNc3DkTMh2HlNmpe0Pw00/?= =?us-ascii?Q?1lZ7BC1HzCJ/czj5VJJZWFs63Jp0XN71CZRqqffgFaoP+luASavB2oixMveF?= =?us-ascii?Q?AVJKougN/VGYJkSJePu2CQq5M5ZyR4TdGFuv1Vtp1OksN7wZW/4eCdUGYtX5?= =?us-ascii?Q?U76Iw50Fcs5yMfETSoH6RJqOIgx9wuPUY5WUe9EktuQZs4U8sS0Os4X4IJsq?= =?us-ascii?Q?F6SmOPT0/XZMbekblFBqMZvzlPjrJAlBweyub8mr3wT6kJLajHyfztFUh53t?= =?us-ascii?Q?GKpZN4aERxBeKeEUBMJsBbhqwSqnOyGvVk7WPpm7MKFUS2+cjdtqJuzZFgvt?= =?us-ascii?Q?coj9KrS+7zAl68JooTi+0xciLPiFFJ/NHPiMHNfXRdIMgDnB9KRh9bEyPaEZ?= =?us-ascii?Q?0qyQpeZPES9WHXk8O1vco3YxDQUPGCJtef19Jumbw1SZUkxOoqe8NGQr0WN3?= =?us-ascii?Q?FbSfUqmf8ITnxw11cqWu5HGWJhytON0whsUJMO2VBe0C4C359IuqJgfugk3a?= =?us-ascii?Q?MYUrL76HkLSABm/CnSh5zTdgLxx5t2KNGzMlcBzrj5+GbCjq21Nk0nyITlze?= =?us-ascii?Q?Km5jtw9nuUXlVASYX/B38g=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR09MB0765; 6:AZDMo/W9rMB9ezO5qEaaCOsA6g0iE1tDYUtmK5iPZrRFQ73hXA0/2xCzxtK3oYuxHgG6+84D4lKNeXKPrh3ToB2swFiJwbysNZx2EaqxXJwUgNN2wXk+wBEZjYZUxvM9rc1etmuiSpKa5L0op/STnTYLVcVMzKXMZY0R7GZvcojL5RZZKG3E6sax0D1vZyF0V0PLhxwBZeGvbxrTFPTtUok+0z3AEmLJ0jKAid79bBFDSpKr7uTsGHW3ITsvJRdmigGSMN2qkj+sTsfRFymYoy6+XmOInLbWEhDcQGpA5v8MQtpAhZ7+RhssmFz3ZUL7WvVpWwapnh9/pzDtQOlwMw==; 5:W/ynhVNztbNvei10t4tFBSkkWn/5BPiYUqF3sSZeTYsJg7p0tAIyGLQGzO9deCxJiNEdcwf4DB4f5xTOgR15awi6w1f5+mDMCBZgIP1pqcYN3vm219E1iGrLbYD4ctzgIPHxrND4SocZDaZF9Jb8DQ==; 24:+WdmW8noqx5gCBxlakxGNRkWuNTOTJ6/nBYFxAunaIgMX/RJUi15PopF+30lvfCGnhhw54Ov+6lqf3vhi8x5QQBl51ytFxJ3+Rz5mrN1su0=; 7:zRmlQpfPmSii1lU5HeXXBwDxYthfLpJRSllG2rm8mumSOkP6SZveFX0ZiBUc8C23VTeQewujUW2TPDB8B4S4Il+PyTVypbbP7kTAoCHB8K3aG2QovycR/7KCrlDPqF4TfYQQZMbEAMW+qihWXptQfPKXZZe6l6BUG/+YXmkJ3ldR4kkyVWI2ut13auv2lPm4SQ58GYzTuG4+ZiTk9sZkBSlryYwv7y/RvS/IhKkCTRzWU7r+dofJIerQ+jSYrgTZ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: fnal.gov X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2016 16:37:19.1353 (UTC) X-MS-Exchange-CrossTenant-Id: 9d5f83d3-d338-4fd3-b1c9-b7d94d70255a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=9d5f83d3-d338-4fd3-b1c9-b7d94d70255a; Ip=[131.225.70.94]; Helo=[smtp-ux-prd1.fnal.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR09MB0765 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 04:12:00 -0000 ---559023410-1804928587-1471969389=:25496 Content-Type: text/plain; charset="US-ASCII"; format=flowed Content-ID: On Tue, 23 Aug 2016, Roger Marquis wrote: >> There should be a way to state that the sysadmin is aware of the >> outdated port and prevent pkg audit from reporting it > > Agreed though I expect such a report would see little use. I maintain a local patch to preserve this functionality which was in portaudit but not in pkg audit. Perhaps not bullet proof, but simple enough to be sure it does what I want it to do. Just drop the attached file into /usr/ports/ports-mgmt/pkg/files/ and put the VuXML ID's you want ignored into /usr/local/etc/portaudit.conf. (easy enough to edit the patch if you prefer pkg.conf or other) This allows the administrator to evaluate each vulnerability entry, decide if it affects a system or not, and document that decision. There are issues with this solution when VuXML entries are edited after the fact to add new packages to the list, but it is better than nothing. (I'd argue that any such edits should require a new VuXML ID to be used.) Hope this helps, - Tim ---559023410-1804928587-1471969389=:25496 Content-Type: text/plain; charset="US-ASCII"; name="patch-pkg_audit.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="patch-pkg_audit.c" LS0tIGxpYnBrZy9wa2dfYXVkaXQuYy5vcmlnCTIwMTQtMTAtMjkgMDM6NDg6 MTIuMDAwMDAwMDAwIC0wNTAwDQorKysgbGlicGtnL3BrZ19hdWRpdC5jCTIw MTQtMTItMzAgMTU6Mzc6MDUuMDAwMDAwMDAwIC0wNjAwDQpAQCAtMTQwLDYg KzE0MCw4IEBADQogCWJvb2wgbG9hZGVkOw0KIAl2b2lkICptYXA7DQogCXNp emVfdCBsZW47DQorCXZvaWQgKmlnbm9yZTsNCisJc2l6ZV90IGlnbm9yZV9s ZW47DQogfTsNCiANCiANCkBAIC04MDIsNiArODA0LDEwIEBADQogCQkJaWYg KGZubWF0Y2goZS0+cGtnbmFtZSwgcGtnLT5uYW1lLCAwKSAhPSAwKQ0KIAkJ CQljb250aW51ZTsNCiANCisJCQkvKiBpZ25vcmUgYnkgaWQgaW4gL3Vzci9s b2NhbC9ldGMvcG9ydGF1ZGl0LmNvbmYgKi8NCisJCQlpZiAoYXVkaXQtPmln bm9yZV9sZW4gJiYgc3RybnN0cihhdWRpdC0+aWdub3JlLGUtPmlkLGF1ZGl0 LT5pZ25vcmVfbGVuKSkNCisJCQkJY29udGludWU7DQorDQogCQkJaWYgKHBr Zy0+dmVyc2lvbiA9PSBOVUxMKSB7DQogCQkJCS8qDQogCQkJCSAqIEFzc3Vt ZSB0aGF0IGFsbCB2ZXJzaW9ucyBzaG91bGQgYmUgY2hlY2tlZA0KQEAgLTg3 Miw2ICs4NzgsMjEgQEANCiAJYXVkaXQtPmxlbiA9IHN0LnN0X3NpemU7DQog CWF1ZGl0LT5sb2FkZWQgPSB0cnVlOw0KIA0KKwlhdWRpdC0+aWdub3JlID0g MDsNCisJYXVkaXQtPmlnbm9yZV9sZW4gPSAwOw0KKwlpZiAoc3RhdCgiL3Vz ci9sb2NhbC9ldGMvcG9ydGF1ZGl0LmNvbmYiLCAmc3QpID09IC0xKQ0KKwkJ cmV0dXJuIChFUEtHX09LKTsNCisJaWYgKChmZCA9IG9wZW4oIi91c3IvbG9j YWwvZXRjL3BvcnRhdWRpdC5jb25mIiwgT19SRE9OTFkpKSA9PSAtMSkNCisJ CXJldHVybiAoRVBLR19PSyk7DQorCWlmICgobWVtID0gbW1hcChOVUxMLCBz dC5zdF9zaXplLCBQUk9UX1JFQUQsIE1BUF9QUklWQVRFLCBmZCwgMCkpID09 IE1BUF9GQUlMRUQpIHsNCisJCWNsb3NlKGZkKTsNCisJCXJldHVybiAoRVBL R19PSyk7DQorCX0NCisJY2xvc2UoZmQpOw0KKw0KKwlhdWRpdC0+aWdub3Jl ID0gbWVtOw0KKwlhdWRpdC0+aWdub3JlX2xlbiA9IHN0LnN0X3NpemU7DQor DQogCXJldHVybiAoRVBLR19PSyk7DQogfQ0KIA0K ---559023410-1804928587-1471969389=:25496-- From owner-freebsd-security@freebsd.org Wed Aug 24 09:36:31 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C73AEBC19CF for ; Wed, 24 Aug 2016 09:36:31 +0000 (UTC) (envelope-from delphij@delphij.net) 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 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7EA01E39 for ; Wed, 24 Aug 2016 09:36:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MacBook-Pro.local (c-73-189-16-150.hsd1.ca.comcast.net [73.189.16.150]) (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 DBCD61C10B; Wed, 24 Aug 2016 02:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1472031385; x=1472045785; bh=nZ9PPQdhUhMaC1wo1uf8xsteHKYSww004/m5vgMku8M=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=kguU8Nl/zPHNASp7pEJoi+h5x2Bdek5/W113jWofu/c5CliWKIscc5MLSHxJiHtmn hIPg0x9ve7YyhUhGdb9bU2npvYbtblQicdmsnigq6EqgsFvp+lH3P5JLabDQOR8G9z X2qCdKmXBkPI5tHKzmPgvL9g2NFv+YqHlRuLj2dA= Subject: Re: Ports EOL vuxml entry To: freebsd-security@freebsd.org References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> Cc: d@delphij.net, zingelman@fnal.gov From: Xin Li Message-ID: <0a6f9f6a-349a-0d03-69f8-97ad7c4d96b2@delphij.net> Date: Wed, 24 Aug 2016 17:36:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="58FNbKvqceSHhuI4rV23PxoD7vSvL5Vpc" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 09:36:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --58FNbKvqceSHhuI4rV23PxoD7vSvL5Vpc Content-Type: multipart/mixed; boundary="ufnHtAV9TL9WqoVXsofCnme23qhgfKOhd" From: Xin Li To: freebsd-security@freebsd.org Cc: d@delphij.net, zingelman@fnal.gov Message-ID: <0a6f9f6a-349a-0d03-69f8-97ad7c4d96b2@delphij.net> Subject: Re: Ports EOL vuxml entry References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> In-Reply-To: --ufnHtAV9TL9WqoVXsofCnme23qhgfKOhd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/23/16 14:23, Gerhard Schmidt wrote: > Is an outdated (EOL) port a vulnerability? I don't think so. It's a > possible vulnerability, but not a real one. Do you have an exact VuXML ID? I don't think vuxml actually warns about EoL'ed software, and it's likely that you have an actual issue, and choose to ignore it (probably for legitimate reason). If it's just reporting a software being outdated (rather than really vulnerable to something), then we should change the entry, I doubt that this is not the case, though. It seems to be sensible to implement Tim's suggestion, however, that allows the system administrator to explicitly override certain VuXML IDs, if they really knows what they are doing. Cheers, --ufnHtAV9TL9WqoVXsofCnme23qhgfKOhd-- --58FNbKvqceSHhuI4rV23PxoD7vSvL5Vpc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXvWqVAAoJEJW2GBstM+nsu5oP/0vtzgQfX3g6eszFDEVmlvsI 0IykBfTh9DH/47qOxdexI55fbpNe8E40Zn+2xV58l9c7k9qfxIHTApqXqg9YnH9E gBNenJ4oK9pqW69evzfpjc4l1Fe86WrAh43NAjwMKgQQbI5TKy5IufRP2+YNepH9 CWAXhOXRHarB5jE6UsM3gMuI69J8hAAN01PYkZVe9Bil0yMWAWuyPjansHuhkww0 hTjiz6cUaWuwi0ZDODAzT50AKcA+2RgoxLPLnDgT6M1UqFGbM2wXc8RAN2KjtTwZ 2Wr4tboumKj6LufczLBDGbbnCGc+Ym3g4napm5az/UOj5slVrQ+U06ju1zvtPR6B UuQcrnzPeyeetwlNHvd3rpsjREb09wq5L3CF+YbSujqwxlelrYusDxF2zaocMJB8 GXGMjTfclgdbZGtNBNyXxogiH6ia0JZgv+0CHMVV+C8ZwW+2hvfXtHIxEr4obOfC nXp5TLoH3PzMatPzAMcFiyhvQlkILYsl1Poj0Kh5VUKdppTBb+HzbKJa/RzIN5WX 73LoFNce8x5ldjNOVTp0TRRLmqszCI0/erxyOPW6m+lhPrqa2wmMoQw/hsW9miRD iBpaAOUT40jDt++TgTBkxFYwlGoG7WXTQd7qsyk6srxljtUCRRHjB4TvrSJ2iGwA corhRG/VjkxjdrxzHYrV =S9i1 -----END PGP SIGNATURE----- --58FNbKvqceSHhuI4rV23PxoD7vSvL5Vpc-- From owner-freebsd-security@freebsd.org Thu Aug 25 00:59:41 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC205BC4147 for ; Thu, 25 Aug 2016 00:59:41 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1.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 816D11272 for ; Thu, 25 Aug 2016 00:59:41 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.15.2/8.15.2) with ESMTP id u7P0xb5Z002564; Wed, 24 Aug 2016 20:59:37 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.15.2/8.14.4/Submit) id u7P0xbK2002563; Wed, 24 Aug 2016 20:59:37 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22462.17145.259645.468877@hergotha.csail.mit.edu> Date: Wed, 24 Aug 2016 20:59:37 -0400 From: Garrett Wollman To: Tim Zingelman Cc: "freebsd-security\@freebsd.org" Subject: Re: Ports EOL vuxml entry In-Reply-To: References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> <8e50a727e71a444f9b2ccaa4844221f9@MWHPR09MB1359.namprd09.prod.outlook.com> X-Mailer: VM 8.2.0b under 24.5.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 24 Aug 2016 20:59:37 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-Mailman-Approved-At: Thu, 25 Aug 2016 01:39:09 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 00:59:41 -0000 < said: > I maintain a local patch to preserve this functionality which was in > portaudit but not in pkg audit. Perhaps not bullet proof, but simple > enough to be sure it does what I want it to do. I have an open bug against pkg that it doesn't have this feature. Would you consider submitting your patch on bugs.freebsd.org/186497 so it doesn't get lost? bapt@ has already said in response to my bug that he would be happy to accept a contribution of this nature. -GAWollman From owner-freebsd-security@freebsd.org Thu Aug 25 12:49:52 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A557BC5433 for ; Thu, 25 Aug 2016 12:49:52 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 4FD1B149E for ; Thu, 25 Aug 2016 12:49:51 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 52A7E2848D for ; Thu, 25 Aug 2016 14:49:43 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 380532840C for ; Thu, 25 Aug 2016 14:49:42 +0200 (CEST) Message-ID: <57BEE965.8000903@quip.cz> Date: Thu, 25 Aug 2016 14:49:41 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: freebsd security Subject: using pkg audit to show base vulnerabilities Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 12:49:52 -0000 I am not sure if this is the right list or not. If not, please redirect me to the right one. I noticed this post from Mark Felder https://blog.feld.me/posts/2016/08/monitoring-freebsd-base-system-vulnerabilities-with-pkg-audit/ Great work Mark, thank you! I found it very useful. I want this to be part of the nightly reports on all our machines so I tried to write 405.base-audit. It is based on original 410.pkg-audit It can check kernel and world of a host or world in jail or chroot (if freebsd-version is installed in jail or chroot) You can my find first attempt at http://freebsd.quip.cz/script/405.base-audit.sh It would be nice if somebody skilled in periodic shell scripting can check this code and post some advices. There are some comments in the code. My main concerns are about the right way to get version info from jail or chroot. I know it is not safe to execute something in jail (or chroot) from the parent: $basedir/bin/freebsd-version -u Is it better to parse freebsd-version file by awk? awk -F= '$1 ~ /^USERLAND_VERSION/ { gsub(/"/, ""); print $2 }' $basedir/bin/freebsd-version Or should we assume that all jails and chroots must be trusted to run any checks on them from parent? The last thing - is it possible to have something like this included as a part of ports-mgmt/pkg Miroslav Lachman From owner-freebsd-security@freebsd.org Fri Aug 26 10:53:26 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EB08A94FF7 for ; Fri, 26 Aug 2016 10:53:26 +0000 (UTC) (envelope-from estartu@ze.tum.de) Received: from mail.ze.tum.de (mail.ze.tum.de [IPv6:2001:4ca0:2e03::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.ze.tum.de", Issuer "Zertifizierungsstelle der TUM" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A57087C9 for ; Fri, 26 Aug 2016 10:53:25 +0000 (UTC) (envelope-from estartu@ze.tum.de) Received: from etustar.ze.tum.de ([IPv6:2001:4ca0:2e03:0:0:0:1:180]) by mail.ze.tum.de (8.15.2/8.15.2) with ESMTPS id u7QArB9i033463 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2016 12:53:12 +0200 (CEST) (envelope-from estartu@ze.tum.de) X-Authentication-Warning: hades.ze.tum.de: Host [IPv6:2001:4ca0:2e03:0:0:0:1:180] claimed to be etustar.ze.tum.de Subject: Re: Ports EOL vuxml entry To: Xin Li , freebsd-security@freebsd.org References: <6c3a84dc-5669-039c-6fa1-92565dd47dff@ze.tum.de> <3sHwFX4YYpz1y2W@mailrelay2.lrz.de> <0a6f9f6a-349a-0d03-69f8-97ad7c4d96b2@delphij.net> Reply-To: schmidt@ze.tum.de From: Gerhard Schmidt Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_M=c3=bcnchen_-_WWW_und_O?= =?UTF-8?Q?nline_Services?= Message-ID: Date: Fri, 26 Aug 2016 12:53:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0a6f9f6a-349a-0d03-69f8-97ad7c4d96b2@delphij.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 10:53:26 -0000 Am 24.08.2016 um 11:36 schrieb Xin Li: > > > On 8/23/16 14:23, Gerhard Schmidt wrote: >> Is an outdated (EOL) port a vulnerability? I don't think so. It's a >> possible vulnerability, but not a real one. > > Do you have an exact VuXML ID? I don't think vuxml actually warns about > EoL'ed software, and it's likely that you have an actual issue, and > choose to ignore it (probably for legitimate reason). If it's just > reporting a software being outdated (rather than really vulnerable to > something), then we should change the entry, I doubt that this is not > the case, though. python24-2.4.6 is vulnerable: End of Life Ports WWW: https://vuxml.FreeBSD.org/freebsd/7fe7df75-6568-11e6-a590-14dae9d210b8.html I Lists a number of ports that are outdated. Not actual vulnerability mentioned. > It seems to be sensible to implement Tim's suggestion, however, that > allows the system administrator to explicitly override certain VuXML > IDs, if they really knows what they are doing. That would be really helpfull. Regards Gerhard Schmidt -- ---------------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de Technische Universität München | Jabber: estartu@ze.tum.de WWW & Online Services | Tel: +49 89 289-25270 | PGP-PublicKey Fax: +49 89 289-25257 | on request From owner-freebsd-security@freebsd.org Fri Aug 26 17:24:29 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B634B75797 for ; Fri, 26 Aug 2016 17:24:29 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 12E53142 for ; Fri, 26 Aug 2016 17:24:27 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.9/8.14.9) with ESMTP id u7QHOIGZ088903; Fri, 26 Aug 2016 18:24:18 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id u7QHOI15001233; Fri, 26 Aug 2016 18:24:18 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id u7QHOIIh001228; Fri, 26 Aug 2016 18:24:18 +0100 Date: Fri, 26 Aug 2016 18:24:18 +0100 Message-Id: <201608261724.u7QHOIIh001228@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-security@freebsd.org In-reply-to: <20160823002821.GJ1069@FreeBSD.org> (message from Gleb Smirnoff on Mon, 22 Aug 2016 17:28:21 -0700) Subject: Re: Unexplained update to /boot/boot1.efi and 2 others by freebsd-update References: <201608221415.u7MEFl8d009158@higson.cam.lispworks.com> <20160823002821.GJ1069@FreeBSD.org> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 17:24:29 -0000 >>>>> On Mon, 22 Aug 2016 17:28:21 -0700, Gleb Smirnoff said: > > Martin, > > On Mon, Aug 22, 2016 at 03:15:47PM +0100, Martin Simmons wrote: > M> Running freebsd-update to convert 10.1-RELEASE-p36 to -p37 updates 3 efi files > M> in /boot, but they are not mentioned in any security advisory or errata notice > M> that I can find and no corresponding source files are updated. This is > M> repeatable on several unrelated systems so I don't think my files have been > M> corrupted. > M> > M> Is this expected? > > The freebsd-update build code attempts to extract and ignore timestamps in order > to determine whether files are 'really' changing between builds; unfortunately these > particular files contain a build artifact which the freebsd-update code was not > able to handle, thus resulting in them being incorrectly identified as needing to be > distributed. > > So, this shouldn't have happened. But don't worry the files aren't forged and they > do originate from the official freebsd-update server. Thanks, that's good to know. __Martin