From owner-freebsd-security@FreeBSD.ORG Sun Apr 28 12:26:51 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8EE54C67 for ; Sun, 28 Apr 2013 12:26:51 +0000 (UTC) (envelope-from priit.jarv@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 2758F1350 for ; Sun, 28 Apr 2013 12:26:50 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z53so563144wey.15 for ; Sun, 28 Apr 2013 05:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:x-x-sender:to:subject:message-id :user-agent:mime-version:content-type; bh=LgXHKX1OXgqmCC/gPqGafd6bXDJd4aLpjYfFUZSsK9k=; b=FP+m/mHPJ42GNPq1i+iOlhG1gzlaiSHDTwAvCMnOQ3NfTQzYGG2+Q8RC8to1/Yf8aH 9e6/9s+B6AkuN95CNBzXaktTnVEOzo4O/8CF7ZJOtTkweD6o7csL8f/JaI7gbFFThUL1 ENDvVJ4xWGn998eRmRA/D+MM/rcjsvCFSQbeA577cG+x1fP5gvMXnseWxqTJ7jNIIwgJ Wzf3CwOnI26JY66STfwlvT4EbuEB0rX336JArBD30g3YTfHyejeGdJUyO3PynnTREu8P mYa6P/InjFAfZI/p5SXE9qwhARpW+2jtxG6sjp9GhLHksbvFdnmhTRBybNn9vd4sWSFF uX4g== X-Received: by 10.180.187.206 with SMTP id fu14mr12470407wic.11.1367152009264; Sun, 28 Apr 2013 05:26:49 -0700 (PDT) Received: from chu (243.100.196.88.dyn.estpak.ee. [88.196.100.243]) by mx.google.com with ESMTPSA id g9sm15531034wix.1.2013.04.28.05.26.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 05:26:48 -0700 (PDT) Sender: =?UTF-8?Q?Priit_J=C3=A4rv?= Date: Sun, 28 Apr 2013 15:20:53 +0300 (EEST) From: priit@cc.ttu.ee X-X-Sender: priit@chu To: freebsd-security@freebsd.org Subject: setfsmac and LOMAC aux grades - inconsistent behaviour Message-ID: User-Agent: Alpine 2.03 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 12:26:51 -0000 A bit of a background: I've been experimenting with LOMAC labels on a 9.1-RELEASE test system. To get the dynamic IP assigned to the machine, I tried following recipe: set the label for /sbin/dhclient to lomac/high[low]. This gets the job done, but there were a few problems: first of all, this label does not seem to persist after a reboot - I have not yet found a reasonable explanation for this. However, that would not be an issue, as it seems a LOMAC/MLS setup would need a script at boot time to update the labels anyway - the /dev filesystem needs them too. When running a script to set the labels from /etc/rc.d I ran into the following problem. Here's the relevant part of the script: check_startmsgs && echo -n "Setting MAC policy: " getpmac id ls -lZ /sbin/dhclient /usr/sbin/setpmac lomac/equal,mls/equal \ /usr/sbin/setfsmac -v -ef /usr/home/test/mac.policy / ls -lZ /sbin/dhclient setfmac lomac/high\[low\] /sbin/dhclient ls -lZ /sbin/dhclient check_startmsgs && echo '.' It produces the following output on boot: Setting MAC policy: lomac/high(low-high),mls/low(low-high) uid=0(root) gid=0(wheel) groups=0(wheel) -r-xr-xr-x 1 root wheel lomac/high,mls/low 93616 Dec 4 11:33 /sbin/dhclient setfsmac: /usr/home/test/mac.policy: read 1 specifications /sbin/dhclient matched by (^/sbin/dhclient$,lomac/high[low]) -r-xr-xr-x 1 root wheel lomac/high,mls/low 93616 Dec 4 11:33 /sbin/dhclient -r-xr-xr-x 1 root wheel lomac/high[low],mls/low 93616 Dec 4 11:33 /sbin/dhcl ient . As you can see, the setfsmac command fails to set the aux grade (but doesn't give an error), the following setfmac command succeeds. The file mac.policy contains just this: /sbin/dhclient lomac/high[low] Normally, one would suspect that something is wrong with the syntax in this file. After all, setfmac and setfsmac are essentially the same program. However, when logged in as root, running the same script results in setting the label correctly by the setfsmac command. I can only conclude, that in the case described above, mac_set_file(), as called by setfsmac does not return an error but does not set the label either. There does not seem to be a scenario where the call would fail and setfsmac would be silent about it. I've also experimented with setting other labels this way and that appeared to work normally (skipping the detailed results to keep things brief). The only case of failure I found was setting a LOMAC aux grade, by setfsmac, from a boot-time script. To avoid any misunderstanding, the issue here is the ability to set the aux grade on the binary. Getting the IP configured was just the way I stumbled into this and can of course be handled in other ways. Also, it is probably obvious from the above script listing, but the files sit on / filesystem that has multilabel set. lomac and mls modules are loaded. Priit. From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 20:55:38 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9AD55188; Mon, 29 Apr 2013 20:55:38 +0000 (UTC) (envelope-from security-advisories@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 7D6951EF2; Mon, 29 Apr 2013 20:55:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3TKtcX3039960; Mon, 29 Apr 2013 20:55:38 GMT (envelope-from security-advisories@freebsd.org) Received: (from des@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3TKtcEs039958; Mon, 29 Apr 2013 20:55:38 GMT (envelope-from security-advisories@freebsd.org) Date: Mon, 29 Apr 2013 20:55:38 GMT Message-Id: <201304292055.r3TKtcEs039958@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: des set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 20:55:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:05.nfsserver Security Advisory The FreeBSD Project Topic: Insufficient input validation in the NFS server Category: core Module: nfsserver Announced: 2013-04-29 Credits: Adam Nowacki Affects: All supported versions of FreeBSD. Corrected: 2013-04-29 20:15:43 UTC (stable/8, 8.4-PRERELEASE) 2013-04-29 20:15:47 UTC (releng/8.3, 8.3-RELEASE-p8) 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC1-p1) 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC2-p1) 2013-04-29 20:15:55 UTC (stable/9, 9.1-STABLE) 2013-04-29 20:16:00 UTC (releng/9.1, 9.1-RELEASE-p3) CVE Name: CVE-2013-3266 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 server and client implementations of NFS. FreeBSD 8.0 and onward has two NFS implementations: the original CSRG NFSv2 and NFSv3 implementation and a new implementation which also supports NFSv4. FreeBSD 9.0 and onward uses the new NFS implementation by default. II. Problem Description When processing READDIR requests, the NFS server does not check that it is in fact operating on a directory node. An attacker can use a specially modified NFS client to submit a READDIR request on a file, causing the underlying filesystem to interpret that file as a directory. III. Impact The exact consequences of an attack depend on the amount of input validation in the underlying filesystem: - If the file resides on a UFS filesystem on a little-endian server, an attacker can cause random heap corruption with completely unpredictable consequences. - If the file resides on a ZFS filesystem, an attacker can write arbitrary data on the stack. It is believed, but has not been confirmed, that this can be exploited to run arbitrary code in kernel context. Other filesystems may also be vulnerable. IV. Workaround Systems that do not provide NFS service 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. 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-03:15/nfsserver.patch # fetch http://security.FreeBSD.org/patches/SA-03:15/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 revision numbers of each file that was corrected in FreeBSD. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r250058 releng/8.3/ r250059 releng/8.4/ r250062 stable/9/ r250060 releng/9.1/ r250061 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3266 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-13:05.nfsserver.asc -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlF+18oACgkQFdaIBMps37J1PACgm+zcbGd6xF1hkpvFVJbbwR0Q 9PoAnivbP1R0qXFyTlF/t3+sUYcxBtfQ =polM -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 21:20:40 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 055E8D1 for ; Mon, 29 Apr 2013 21:20:40 +0000 (UTC) (envelope-from s-tlk@s-tlk.org) Received: from mail.s-tlk.org (s-tlk.org [178.63.70.119]) by mx1.freebsd.org (Postfix) with ESMTP id 5C26B136E for ; Mon, 29 Apr 2013 21:20:39 +0000 (UTC) Received: from [10.0.3.6] (unknown [10.0.3.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.s-tlk.org (Postfix) with ESMTPSA id 27B49AE119F for ; Mon, 29 Apr 2013 23:13:38 +0200 (CEST) Date: Mon, 29 Apr 2013 23:13:38 +0200 (CEST) From: Michael Schnell X-X-Sender: michi@priv.s-tlk.org To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <201304292055.r3TKtcrk039951@freefall.freebsd.org> Message-ID: References: <201304292055.r3TKtcrk039951@freefall.freebsd.org> User-Agent: Alpine 2.00 (BSF 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.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 21:20:40 -0000 Hi, thanks for the warning. But the link for the source patch is not working for me: http://security.FreeBSD.org/patches/SA-03:15/nfsserver.patch Greetings Michael On Mon, 29 Apr 2013, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ============================================================================= > FreeBSD-SA-13:05.nfsserver Security Advisory > The FreeBSD Project > > Topic: Insufficient input validation in the NFS server > > Category: core > Module: nfsserver > Announced: 2013-04-29 > Credits: Adam Nowacki > Affects: All supported versions of FreeBSD. > Corrected: 2013-04-29 20:15:43 UTC (stable/8, 8.4-PRERELEASE) > 2013-04-29 20:15:47 UTC (releng/8.3, 8.3-RELEASE-p8) > 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC1-p1) > 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC2-p1) > 2013-04-29 20:15:55 UTC (stable/9, 9.1-STABLE) > 2013-04-29 20:16:00 UTC (releng/9.1, 9.1-RELEASE-p3) > CVE Name: CVE-2013-3266 > > 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 server and client > implementations of NFS. > > FreeBSD 8.0 and onward has two NFS implementations: the original CSRG > NFSv2 and NFSv3 implementation and a new implementation which also > supports NFSv4. > > FreeBSD 9.0 and onward uses the new NFS implementation by default. > > II. Problem Description > > When processing READDIR requests, the NFS server does not check that > it is in fact operating on a directory node. An attacker can use a > specially modified NFS client to submit a READDIR request on a file, > causing the underlying filesystem to interpret that file as a > directory. > > III. Impact > > The exact consequences of an attack depend on the amount of input > validation in the underlying filesystem: > > - If the file resides on a UFS filesystem on a little-endian server, > an attacker can cause random heap corruption with completely > unpredictable consequences. > > - If the file resides on a ZFS filesystem, an attacker can write > arbitrary data on the stack. It is believed, but has not been > confirmed, that this can be exploited to run arbitrary code in > kernel context. > > Other filesystems may also be vulnerable. > > IV. Workaround > > Systems that do not provide NFS service 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. > > 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-03:15/nfsserver.patch > # fetch http://security.FreeBSD.org/patches/SA-03:15/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 revision numbers of each file that was > corrected in FreeBSD. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r250058 > releng/8.3/ r250059 > releng/8.4/ r250062 > stable/9/ r250060 > releng/9.1/ r250061 > - ------------------------------------------------------------------------- > > VII. References > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3266 > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-13:05.nfsserver.asc > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAlF+18oACgkQFdaIBMps37J1PACgm+zcbGd6xF1hkpvFVJbbwR0Q > 9PoAnivbP1R0qXFyTlF/t3+sUYcxBtfQ > =polM > -----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 Mon Apr 29 21:20:53 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CF2361A5 for ; Mon, 29 Apr 2013 21:20:53 +0000 (UTC) (envelope-from s-tlk@s-tlk.org) Received: from mail.s-tlk.org (s-tlk.org [178.63.70.119]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8141375 for ; Mon, 29 Apr 2013 21:20:53 +0000 (UTC) Received: from [10.0.3.6] (unknown [10.0.3.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.s-tlk.org (Postfix) with ESMTPSA id ADCA7AE11A3 for ; Mon, 29 Apr 2013 23:20:52 +0200 (CEST) Date: Mon, 29 Apr 2013 23:20:52 +0200 (CEST) From: Michael Schnell X-X-Sender: michi@priv.s-tlk.org To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <201304292055.r3TKtcrk039951@freefall.freebsd.org> Message-ID: References: <201304292055.r3TKtcrk039951@freefall.freebsd.org> User-Agent: Alpine 2.00 (BSF 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.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 21:20:53 -0000 Okay, found the correct link: http://www.freebsd.org/security/patches/SA-13:05/nfsserver.patch http://www.freebsd.org/security/patches/SA-13:05/nfsserver.patch.asc Just a wrong SA number in the url. ;-) Greetings Michael On Mon, 29 Apr 2013, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ============================================================================= > FreeBSD-SA-13:05.nfsserver Security Advisory > The FreeBSD Project > > Topic: Insufficient input validation in the NFS server > > Category: core > Module: nfsserver > Announced: 2013-04-29 > Credits: Adam Nowacki > Affects: All supported versions of FreeBSD. > Corrected: 2013-04-29 20:15:43 UTC (stable/8, 8.4-PRERELEASE) > 2013-04-29 20:15:47 UTC (releng/8.3, 8.3-RELEASE-p8) > 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC1-p1) > 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC2-p1) > 2013-04-29 20:15:55 UTC (stable/9, 9.1-STABLE) > 2013-04-29 20:16:00 UTC (releng/9.1, 9.1-RELEASE-p3) > CVE Name: CVE-2013-3266 > > 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 server and client > implementations of NFS. > > FreeBSD 8.0 and onward has two NFS implementations: the original CSRG > NFSv2 and NFSv3 implementation and a new implementation which also > supports NFSv4. > > FreeBSD 9.0 and onward uses the new NFS implementation by default. > > II. Problem Description > > When processing READDIR requests, the NFS server does not check that > it is in fact operating on a directory node. An attacker can use a > specially modified NFS client to submit a READDIR request on a file, > causing the underlying filesystem to interpret that file as a > directory. > > III. Impact > > The exact consequences of an attack depend on the amount of input > validation in the underlying filesystem: > > - If the file resides on a UFS filesystem on a little-endian server, > an attacker can cause random heap corruption with completely > unpredictable consequences. > > - If the file resides on a ZFS filesystem, an attacker can write > arbitrary data on the stack. It is believed, but has not been > confirmed, that this can be exploited to run arbitrary code in > kernel context. > > Other filesystems may also be vulnerable. > > IV. Workaround > > Systems that do not provide NFS service 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. > > 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-03:15/nfsserver.patch > # fetch http://security.FreeBSD.org/patches/SA-03:15/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 revision numbers of each file that was > corrected in FreeBSD. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r250058 > releng/8.3/ r250059 > releng/8.4/ r250062 > stable/9/ r250060 > releng/9.1/ r250061 > - ------------------------------------------------------------------------- > > VII. References > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3266 > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-13:05.nfsserver.asc > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAlF+18oACgkQFdaIBMps37J1PACgm+zcbGd6xF1hkpvFVJbbwR0Q > 9PoAnivbP1R0qXFyTlF/t3+sUYcxBtfQ > =polM > -----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 Mon Apr 29 21:55:15 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0EDDFE85 for ; Mon, 29 Apr 2013 21:55:15 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CB25A1593 for ; Mon, 29 Apr 2013 21:55:14 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 22FDAD0AA; Mon, 29 Apr 2013 21:55:14 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 9C1871866; Mon, 29 Apr 2013 23:54:49 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Michael Schnell Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <201304292055.r3TKtcrk039951@freefall.freebsd.org> Date: Mon, 29 Apr 2013 23:54:49 +0200 In-Reply-To: (Michael Schnell's message of "Mon, 29 Apr 2013 23:20:52 +0200 (CEST)") Message-ID: <86ip35atp2.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 21:55:15 -0000 Michael Schnell writes: > Just a wrong SA number in the url. ;-) Correct. We will release a revised SA in a short while. I apologize for the mistake. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 21:56:50 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5CD6EFEE; Mon, 29 Apr 2013 21:56:50 +0000 (UTC) (envelope-from security-advisories@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 3F85E15BD; Mon, 29 Apr 2013 21:56:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3TLuoqW052346; Mon, 29 Apr 2013 21:56:50 GMT (envelope-from security-advisories@freebsd.org) Received: (from des@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3TLuoGP052344; Mon, 29 Apr 2013 21:56:50 GMT (envelope-from security-advisories@freebsd.org) Date: Mon, 29 Apr 2013 21:56:50 GMT Message-Id: <201304292156.r3TLuoGP052344@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: des set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver [REVISED] Precedence: bulk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 21:56:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-13:05.nfsserver Security Advisory The FreeBSD Project Topic: Insufficient input validation in the NFS server Category: core Module: nfsserver Announced: 2013-04-29 Revised: 2013-04-29 Credits: Adam Nowacki Affects: All supported versions of FreeBSD. Corrected: 2013-04-29 21:10:49 UTC (stable/8, 8.4-PRERELEASE) 2013-04-29 21:10:53 UTC (releng/8.3, 8.3-RELEASE-p8) 2013-04-29 21:11:31 UTC (releng/8.4, 8.4-RC1-p1) 2013-04-29 21:11:31 UTC (releng/8.4, 8.4-RC2-p1) 2013-04-29 21:11:01 UTC (stable/9, 9.1-STABLE) 2013-04-29 21:11:05 UTC (releng/9.1, 9.1-RELEASE-p3) CVE Name: CVE-2013-3266 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2013-04-29 Initial release. v1.1 2013-04-29 Corrected patch URL. Additional workaround information. 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 server and client implementations of NFS. FreeBSD 8.0 and onward has two NFS implementations: the original CSRG NFSv2 and NFSv3 implementation and a new implementation which also supports NFSv4. FreeBSD 9.0 and onward uses the new NFS implementation by default. II. Problem Description When processing READDIR requests, the NFS server does not check that it is in fact operating on a directory node. An attacker can use a specially modified NFS client to submit a READDIR request on a file, causing the underlying filesystem to interpret that file as a directory. III. Impact The exact consequences of an attack depend on the amount of input validation in the underlying filesystem: - If the file resides on a UFS filesystem on a little-endian server, an attacker can cause random heap corruption with completely unpredictable consequences. - If the file resides on a ZFS filesystem, an attacker can write arbitrary data on the stack. It is believed, but has not been confirmed, that this can be exploited to run arbitrary code in kernel context. Other filesystems may also be vulnerable. IV. Workaround Systems that do not provide NFS service 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-13:05/nfsserver.patch # fetch http://security.FreeBSD.org/patches/SA-13: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 revision numbers of each file that was corrected in FreeBSD. Branch/path Revision - ------------------------------------------------------------------------- stable/8/ r250068 releng/8.3/ r250069 releng/8.4/ r250073 stable/9/ r250070 releng/9.1/ r250071 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3266 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-13:05.nfsserver.asc -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlF+7BUACgkQFdaIBMps37I3LACeIFS/wiaA6eDn9F8ByZ6V8CH4 GT4AoIrhX24l+LHxpvtHoaDmKOoBpva5 =bbRm -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 22:08:39 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D28FCCA for ; Mon, 29 Apr 2013 22:08:39 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from fw.ax.cz (fw.ax.cz [IPv6:2a00:1aa8:1:1000::2]) by mx1.freebsd.org (Postfix) with ESMTP id 07D1E1926 for ; Mon, 29 Apr 2013 22:08:38 +0000 (UTC) Received: from [172.20.1.29] (host10.hide.ax.cz [172.20.1.29]) by fw.ax.cz (8.14.5/8.14.5) with ESMTP id r3TM8X7u053516 for ; Tue, 30 Apr 2013 00:08:36 +0200 (CEST) (envelope-from dan@obluda.cz) Message-ID: <517EEF57.2030106@obluda.cz> Date: Tue, 30 Apr 2013 00:08:23 +0200 From: Dan Lukes User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver [REVISED] References: <201304292156.r3TLuoGP052344@freefall.freebsd.org> In-Reply-To: <201304292156.r3TLuoGP052344@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:08:39 -0000 FreeBSD Security Advisories wrote: > 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. It output "2" on my 9.1-RELEASE-p2 with new NFSD as output of kldstat -v return two lines containing word 'nfsd': > 6 1 0xffffffff80c14000 2b38b nfsd.ko (/boot/kernel/nfsd.ko) > Contains modules: > Id Name > 202 nfsd Someone may be confused by non 0/1 result not catched in advisory. Either kldstat -v | grep -wc nfsd.ko or kldstat | grep -wc nfsd should be used instead the command recommended in advisory to obtain 0/1 result. Regards Dan From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 22:46:49 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A22036EE for ; Mon, 29 Apr 2013 22:46:49 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 707261C94 for ; Mon, 29 Apr 2013 22:46:49 +0000 (UTC) Received: by mail-ia0-f177.google.com with SMTP id y26so6127048iab.36 for ; Mon, 29 Apr 2013 15:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=IwilsWdaOUR2OToEM/FSgLtWFea9a+TPt0cT8BcOoQg=; b=LCD6UGGOqvzVkRFPOGAzQiNmpDyZ9Lgwd8QK/yAWygqX1OG7B1OuNuHCXS5EHDEORo sxjYYgYTwVjntN1Ee3KmjcopWg87bWIBU20YR42fXhRwSFWQ+i96G3RTuozX1jHEYGvk EzpCir4y0J7JoTnXPGG9Yxg8L0TEf9ytH6IZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IwilsWdaOUR2OToEM/FSgLtWFea9a+TPt0cT8BcOoQg=; b=K2xABlQCTbEAA0TcvOPg4E51QXwsG3hRbY6j/1njrLOQvLGANtwzMIIusHyxCeRObn zI5sHSUbBeLDL02427Nm/Nt6pyWXYsbYtqRXYI1a91D8ENPaC1tlZkhcEon7RzMpDA+a zPId8cebWShgADto2Pyy0RxtQdEmsNntxYmaO9SjUTGfeeDSnFe1GRzJRyERD6UbQXbC eMVn/Kp1tYgKdM7qjt/i6OnBuGN8NtVVm0ypZyVf8egu8Xy2NZCznf1QYXEd+tpFc5in zgI98jUfHH4fkktsgjNzueq76ZZ6d7ard1gcoi1luILVfY2bXBazmhSX8YgXZ2Hm6gUb 0IQg== X-Received: by 10.50.153.76 with SMTP id ve12mr2223815igb.61.1367275609160; Mon, 29 Apr 2013 15:46:49 -0700 (PDT) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPSA id d4sm19751001igc.3.2013.04.29.15.46.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 15:46:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver [REVISED] From: Kevin Day In-Reply-To: <201304292156.r3TLuoGP052344@freefall.freebsd.org> Date: Mon, 29 Apr 2013 17:46:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201304292156.r3TLuoGP052344@freefall.freebsd.org> To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmDP0yc0/7FncyrZmXmtKd8FkEdCKDDwwH5c6idHajQQiY00fY7rAMLOnPf2mQ/1O4FDTQe X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:46:49 -0000 On Apr 29, 2013, at 4:56 PM, FreeBSD Security Advisories = wrote: > II. Problem Description >=20 > When processing READDIR requests, the NFS server does not check that > it is in fact operating on a directory node. An attacker can use a > specially modified NFS client to submit a READDIR request on a file, > causing the underlying filesystem to interpret that file as a > directory. Can someone clarify if this is exploitable only from hosts/networks = allowed in /etc/exports? i.e. if exports would not allow an attacker to = mount a filesystem, would they still be able to exploit this? I'm guessing not, but I would have expected "lock down your nfs exports" = to be suggested. -- Kevin From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 22:46:58 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52ABA7BC for ; Mon, 29 Apr 2013 22:46:58 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1B34C1C96 for ; Mon, 29 Apr 2013 22:46:57 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 36D80D13A; Mon, 29 Apr 2013 22:46:57 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id C0D3E1877; Tue, 30 Apr 2013 00:46:32 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Dan Lukes Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver [REVISED] References: <201304292156.r3TLuoGP052344@freefall.freebsd.org> <517EEF57.2030106@obluda.cz> Date: Tue, 30 Apr 2013 00:46:32 +0200 In-Reply-To: <517EEF57.2030106@obluda.cz> (Dan Lukes's message of "Tue, 30 Apr 2013 00:08:23 +0200") Message-ID: <864neparav.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:46:58 -0000 Dan Lukes writes: > Someone may be confused by non 0/1 result not catched in advisory. > > Either > kldstat -v | grep -wc nfsd.ko > or > kldstat | grep -wc nfsd > > should be used instead the command recommended in advisory to obtain 0/1 > result. If NFS is compiled in, both of these will print 0. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 22:50:49 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DE349AB3 for ; Mon, 29 Apr 2013 22:50:49 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A6C8E1CF8 for ; Mon, 29 Apr 2013 22:50:49 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 002D7D14E; Mon, 29 Apr 2013 22:50:48 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 8AF36187A; Tue, 30 Apr 2013 00:50:24 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Kevin Day Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver [REVISED] References: <201304292156.r3TLuoGP052344@freefall.freebsd.org> Date: Tue, 30 Apr 2013 00:50:24 +0200 In-Reply-To: (Kevin Day's message of "Mon, 29 Apr 2013 17:46:45 -0500") Message-ID: <86zjwh9cjz.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:50:49 -0000 Kevin Day writes: > Can someone clarify if this is exploitable only from hosts/networks > allowed in /etc/exports? i.e. if exports would not allow an attacker > to mount a filesystem, would they still be able to exploit this? I thought that was self-explanatory - the attacker must first mount the filesystem. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 22:31:52 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81BEA358; Mon, 29 Apr 2013 22:31:52 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6561BAC; Mon, 29 Apr 2013 22:31:51 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA16119; Mon, 29 Apr 2013 16:08:25 -0600 (MDT) Message-Id: <201304292208.QAA16119@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Apr 2013 16:08:22 -0600 To: freebsd-security@freebsd.org, FreeBSD Security Advisories From: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <201304292055.r3TKtcEs039958@freefall.freebsd.org> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Tue, 30 Apr 2013 03:40:57 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:31:52 -0000 Please be advised that, when using freebsd-update(8) to install the patch for this security problem, freebsd-update will move the current kernel to /boot/kernel.old, and install a new GENERIC kernel in /boot/kernel, even if you have built a custom kernel and created a copy of the GENERIC kernel in /boot/GENERIC. The kernel in /boot/GENERIC is NOT updated, nor are the modules in that directory updated. What's more, if you did not build modules for your custom kernel, you will not get copies of the updated NFS modules. This is probably not the behavior most users who have built custom kernels will want or expect. (I would have hoped that the GENERIC kernel, its modules, and the kernel sources would be updated and that I'd be reminded to rebuild my custom kernel if necessary.) --Brett Glass At 02:55 PM 4/29/2013, FreeBSD Security Advisories wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >============================================================================= >FreeBSD-SA-13:05.nfsserver Security Advisory > The FreeBSD Project > >Topic: Insufficient input validation in the NFS server From owner-freebsd-security@FreeBSD.ORG Mon Apr 29 22:38:01 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D602B4F9 for ; Mon, 29 Apr 2013 22:38:01 +0000 (UTC) (envelope-from wbe@psr.com) Received: from psr.com (mail.psr.com [67.212.42.216]) by mx1.freebsd.org (Postfix) with ESMTP id 804351BDB for ; Mon, 29 Apr 2013 22:38:00 +0000 (UTC) Received: from psr.com (localhost [127.0.0.1]) by psr.com (8.14.5/8.14.5) with ESMTP id r3TMQOPT056591 for ; Mon, 29 Apr 2013 18:26:24 -0400 (EDT) (envelope-from wbe@psr.com) Received: (from wbe@localhost) by psr.com (8.14.5/8.14.5/Submit) id r3TMQOnI056590; Mon, 29 Apr 2013 18:26:24 -0400 (EDT) (envelope-from wbe) Message-Id: <201304292226.r3TMQOnI056590@psr.com> Date: Mon, 29 Apr 2013 18:26 EDT From: Winston To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <20130429205552$12b7@rincewind.paeps.cx> In-Reply-To: <20130429205552$12b7@rincewind.paeps.cx> (FreeBSD Security Advisories's message of "Mon, 29 Apr 2013 22:55:52 +0200") X-Mailman-Approved-At: Tue, 30 Apr 2013 03:41:15 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 22:38:01 -0000 For the purpose of the NFS vulnerability in 9.0-RELEASE, does it make any difference whether one has used /etc/exports and an explicitly started nfsd, or exported the files using "zfs set sharenfs={options}" if the exported file system in both cases is ZFS? (That's probably similar to asking whether ZFS has its own NFSd code or uses /usr/sbin/nfsd.) Thanks in advance, -WBE From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 03:46:07 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56A7F1AC; Tue, 30 Apr 2013 03:46:07 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 381BB1799; Tue, 30 Apr 2013 03:46:06 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 5C32B23F804; Mon, 29 Apr 2013 23:46:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us 5C32B23F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Mon, 29 Apr 2013 23:46:03 -0400 From: Glen Barber To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <20130430034603.GF1588@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NY6JkbSqL3W9mApi" Content-Disposition: inline In-Reply-To: <201304292208.QAA16119@lariat.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 03:46:07 -0000 --NY6JkbSqL3W9mApi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2013 at 04:08:22PM -0600, Brett Glass wrote: > Please be advised that, when using freebsd-update(8) to install the patch= for > this security problem, freebsd-update will move the current kernel to /bo= ot/kernel.old, > and install a new GENERIC kernel in /boot/kernel, even if you have built = a custom > kernel and created a copy of the GENERIC kernel in /boot/GENERIC.=20 >=20 > The kernel in /boot/GENERIC is NOT updated, nor are the modules in that d= irectory > updated. What's more, if you did not build modules for your custom kernel= , you > will not get copies of the updated NFS modules. >=20 > This is probably not the behavior most users who have built custom kernel= s will > want or expect. (I would have hoped that the GENERIC kernel, its modules,= and the > kernel sources would be updated and that I'd be reminded to rebuild my cu= stom kernel > if necessary.) >=20 This has _always_ been the case with freebsd-update(8). Glen --NY6JkbSqL3W9mApi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRfz57AAoJEFJPDDeguUaj6ZgH/1eBAaIrofVAo304Zr220ADN KUB2z0ez+qJaxrahu3T89I4F/ZkxCu4FoKWgWiiFPBnOPRZpAfF1lL3NypB7rb+5 Z6m4a9pXmYzOS7LadqKvO3GdVEmRp633k6jf7A1Bb72jIeLiHsi+87gZ995l/NLZ LphfN8TS77K5tkOXc6AQeq6PnY5Yu8Ap+inxeQaX4REjHirnYMy6q7a5fkfpknlY TF+pw9PU8eVWJEHWo3/3Z2oDk6ymGFkZQW/Op4yEHvWfItMWihHAH1FYj2dt8quA D5BWH4FQCfr+8N9w2NO+xRi1/moGEzNHhEKiPiiO/BjYc51Crs/EOiJ0HJQKcEM= =JyQZ -----END PGP SIGNATURE----- --NY6JkbSqL3W9mApi-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 04:24:18 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1B99833; Tue, 30 Apr 2013 04:24:18 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 8FE7518C1; Tue, 30 Apr 2013 04:24:18 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id E866823F804; Tue, 30 Apr 2013 00:24:16 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us E866823F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 30 Apr 2013 00:24:15 -0400 From: Glen Barber To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <20130430042415.GG1588@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v2Uk6McLiE8OV1El" Content-Disposition: inline In-Reply-To: <201304300416.WAA20729@lariat.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 04:24:18 -0000 --v2Uk6McLiE8OV1El Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2013 at 10:16:43PM -0600, Brett Glass wrote: > At 09:46 PM 4/29/2013, Glen Barber wrote: >=20 > >This has _always_ been the case with freebsd-update(8). >=20 > Should it be? Yes. freebsd-update(8) does not, and cannot, know of custom kernel configurations. > It seems to me that the current behavior >=20 > a) Violates POLA; and >=20 Wrong. Users that build a custom kernel are responsible for maintaining the custom kernel for upgrades. > b) Puts any system with a custom kernel at serious risk if > surgery and/or a kernel rebuild is not done prior to the > next reboot. If there's a power failure, the system may > well not come up. Wrong. Previous statement applies. Glen --v2Uk6McLiE8OV1El Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRf0dvAAoJEFJPDDeguUajoO8H/2lYpy4aXLNsROVGHxjYWCno N/D7HJHZ45DZgLCjXhTYAQ/AR+wiWQv9JAt7t6BAhnXJaK0MP2HgOcKSWlmjHjM3 29SkAh0RmTsQWDxtY5uTV8QCEEcQf31y/56n/gqSv6OS11aDy6jHLu1cCy6dSgHX aTqpHdTpmKL4qvzF4HhkRFqGiFOKVtHxPOfzFk/HZrMM3rTU/kfdkXhZhYrXJ0s0 Ib+PoNEOebTtqpGNYnb27EPKYIDhvYfRD/URdmaYVZj2oKZvL/+FqrVYQ2d3iX5Q XYguLfDcazg1j9/QdVxeDrKQ8XggRJtdrb+BHvCwrWLSUoyYn5BJOjqkdcPoUB0= =sWl3 -----END PGP SIGNATURE----- --v2Uk6McLiE8OV1El-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 05:24:54 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88FF0670 for ; Tue, 30 Apr 2013 05:24:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 766501BBB for ; Tue, 30 Apr 2013 05:24:54 +0000 (UTC) Received: from delphij-macbook.local (c-67-188-85-47.hsd1.ca.comcast.net [67.188.85.47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id B14F511F46; Mon, 29 Apr 2013 22:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1367299487; bh=6wN86eCXh3YrtHLto6hltmCqpP1ED/OCHDeH5/JlB/o=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=MwS4LxJ8lo+MKd7WoMTS7dhw1KxS50iR8LzeIK5CLihucchdliR97HxYEcxwgv1CJ Mziy3n+BctGugbTGbpbqdPg93auo08JAnBi8XybQL0l3R3SeS+otG6xSoAR8/5q42m h0oNa6hJYFJAoFUNF3T/Y29T2N73LKhI+lj9o1ew= Message-ID: <517F559F.3060407@delphij.net> Date: Mon, 29 Apr 2013 22:24:47 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Winston Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <20130429205552$12b7@rincewind.paeps.cx> <201304292226.r3TMQOnI056590@psr.com> In-Reply-To: <201304292226.r3TMQOnI056590@psr.com> X-Enigmail-Version: 1.5.1 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.14 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, 30 Apr 2013 05:24:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/29/13 3:26 PM, Winston wrote: > For the purpose of the NFS vulnerability in 9.0-RELEASE, does it > make any difference whether one has used /etc/exports and an > explicitly started nfsd, or exported the files using "zfs set > sharenfs={options}" if the exported file system in both cases is > ZFS? (That's probably similar to asking whether ZFS has its own > NFSd code or uses /usr/sbin/nfsd.) No, there is no difference between these two approaches. Please also note that 9.0-RELEASE is EoL now, by the way. Cheers, -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJRf1WfAAoJEG80Jeu8UPuzcmcIALNss+ZuGBqagzyAPa+QiXzm wVOIQAKXsHrDpKuvj9pNvJFGf9eUX+7+Ceau2itR+6NSAXJ7Xx9ATWQUTgvVY23t TZVgvLxcXMEDfw3Y4XAjfXao/19IB1PTHfbo27iZU2y9xJHi/bHG7I1CHRcE9+HN WRRr9iu4H7fdIxSnJu3UO3P9FyPO9CtWmhlTKQ7n1HNMTd8k3NfY/KMewYfCXEbW +VsUvH6h1eZFYKL6DcfA3YpZ/5u8PvlZBaWjzrshhhevtdavlruHlbf743hVEcP/ hKoMLoFJZ9a2sanEVogUvqqE4tSRSmaur1Eh6iadLmj08ScyCz/Ih4ktk7TH24k= =Y4m8 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 09:52:06 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 35AA8F92 for ; Tue, 30 Apr 2013 09:52:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id F306B1671 for ; Tue, 30 Apr 2013 09:52:05 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 2E9CAD8A7; Tue, 30 Apr 2013 09:52:05 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 755A21CAD; Tue, 30 Apr 2013 11:51:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Winston Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <20130429205552$12b7@rincewind.paeps.cx> <201304292226.r3TMQOnI056590@psr.com> Date: Tue, 30 Apr 2013 11:51:39 +0200 In-Reply-To: <201304292226.r3TMQOnI056590@psr.com> (Winston's message of "Mon, 29 Apr 2013 18:26 EDT") Message-ID: <86a9oggxck.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 09:52:06 -0000 Winston writes: > For the purpose of the NFS vulnerability in 9.0-RELEASE, does it make > any difference whether one has used /etc/exports and an explicitly > started nfsd, or exported the files using "zfs set sharenfs=3D{options}" > if the exported file system in both cases is ZFS? (That's probably > similar to asking whether ZFS has its own NFSd code or uses > /usr/sbin/nfsd.) ZFS does not have its own NFSD. What happens when you set sharenfs on a dataset is that it updates /etc/zfs/exports and HUPs mountd. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 04:16:49 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DBF236E0; Tue, 30 Apr 2013 04:16:49 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7394D1887; Tue, 30 Apr 2013 04:16:49 +0000 (UTC) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id WAA20729; Mon, 29 Apr 2013 22:16:45 -0600 (MDT) Message-Id: <201304300416.WAA20729@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Apr 2013 22:16:43 -0600 To: Glen Barber From: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <20130430034603.GF1588@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 30 Apr 2013 11:20:40 +0000 Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 04:16:49 -0000 At 09:46 PM 4/29/2013, Glen Barber wrote: >This has _always_ been the case with freebsd-update(8). Should it be? It seems to me that the current behavior a) Violates POLA; and b) Puts any system with a custom kernel at serious risk if surgery and/or a kernel rebuild is not done prior to the next reboot. If there's a power failure, the system may well not come up. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 16:26:26 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E70138E; Tue, 30 Apr 2013 16:26:26 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 600FE1D63; Tue, 30 Apr 2013 16:26:26 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id 16so853080iea.38 for ; Tue, 30 Apr 2013 09:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rTSVbS3Sbc6jx/1LjiyYojP8BDVMvnNCqRlOtuQ/q/8=; b=IiwQKkny7LCGLelM4XR8mJ1KCiImSpM/XTLXxCeXb5rAD+iT+IJu3Ph3/6D9JDCPUR 70uUN0EznGJ8UIoIBVa88kZQzPfmv9FZbgNKTzvnT0eNQyY/GZqA9JLYnIqn5myMMRNh SsPygkTD0MuhKZMvXEkFfKeVzpPFtBKecXCV9y0sOWEJ6zZa6xHB77P5ghWDTSh8e4fg EydRxdIUxrs+E3fdEw9bW2AVmKftXJHBXLx7aX4IX4LE0Rgk+CJjaVs9jnVwUEkzXQn0 ycERW4I4InHaPus37CRki6+m3tlRzDdoQnq5O1L0Zc08T9z1YHV4eWITQwWHXG+Ndrfl NZIQ== MIME-Version: 1.0 X-Received: by 10.43.47.5 with SMTP id uq5mr32098919icb.0.1367339186036; Tue, 30 Apr 2013 09:26:26 -0700 (PDT) Received: by 10.64.58.52 with HTTP; Tue, 30 Apr 2013 09:26:25 -0700 (PDT) Received: by 10.64.58.52 with HTTP; Tue, 30 Apr 2013 09:26:25 -0700 (PDT) In-Reply-To: <20130430042415.GG1588@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> Date: Tue, 30 Apr 2013 17:26:25 +0100 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver From: Chris Rees To: Glen Barber , Colin Percival X-Mailman-Approved-At: Tue, 30 Apr 2013 17:49:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-security@freebsd.org, Brett Glass X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 16:26:26 -0000 On 30 Apr 2013 05:24, "Glen Barber" wrote: > > On Mon, Apr 29, 2013 at 10:16:43PM -0600, Brett Glass wrote: > > At 09:46 PM 4/29/2013, Glen Barber wrote: > > > > >This has _always_ been the case with freebsd-update(8). > > > > Should it be? > > Yes. freebsd-update(8) does not, and cannot, know of custom kernel > configurations. > > > It seems to me that the current behavior > > > > a) Violates POLA; and > > > > Wrong. Users that build a custom kernel are responsible for maintaining > the custom kernel for upgrades. > > > b) Puts any system with a custom kernel at serious risk if > > surgery and/or a kernel rebuild is not done prior to the > > next reboot. If there's a power failure, the system may > > well not come up. > > Wrong. Previous statement applies. I agreed with Glen, but when checking the docs it turns out that they say that freebsd-update will detect a kernel in /boot/GENERIC: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html Are the docs wrong, or is this only in new freebsd-update? Chris From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 19:37:04 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E5E58F3; Tue, 30 Apr 2013 19:37:04 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id D74961502; Tue, 30 Apr 2013 19:37:03 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA02519; Tue, 30 Apr 2013 13:36:59 -0600 (MDT) Message-Id: <201304301936.NAA02519@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Apr 2013 13:36:52 -0600 To: Chris Rees , Glen Barber , Colin Percival From: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> 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.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 19:37:04 -0000 This is one of several reasons why one would expect freebsd-update(8) to be considerate of a custom kernel: it is documented as knowing about /boot/GENERIC as the place to put he GENERIC kernel if one builds a custom one. Also, I don't think that freebsd-update(8) should, in the course of a normal update, create a situation where the system is not be able to reboot. This would have been the case with the system I updated, had I not caught the problem. I daresay that a system that stops working after a routine update is a violation of POLA. ;-) In my case, the GENERIC kernel was installed in place of the custom one, without modules the system needed -- in either loadable or built-in form. It's easy to prevent this by modifying /boot/GENERIC (which freebsd-update is supposed to know about) instead of overwriting the custom kernel... and then advising the administrator that a new build might be needed. --Brett Glass At 10:26 AM 4/30/2013, Chris Rees wrote: >I agreed with Glen, but when checking the docs it turns out that they say >that freebsd-update will detect a kernel in /boot/GENERIC: > >http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > >Are the docs wrong, or is this only in new freebsd-update? > >Chris >_______________________________________________ >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 30 21:15:37 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A07A31E0; Tue, 30 Apr 2013 21:15:37 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5017E1883; Tue, 30 Apr 2013 21:15:37 +0000 (UTC) Received: from glenbarber.us (75-146-225-65-Philadelphia.hfc.comcastbusiness.net [75.146.225.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id F035723F804; Tue, 30 Apr 2013 17:15:33 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us F035723F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 30 Apr 2013 17:15:31 -0400 From: Glen Barber To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <20130430211531.GA1621@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <201304301936.NAA02519@lariat.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, Colin Percival , Chris Rees X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 21:15:37 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2013 at 01:36:52PM -0600, Brett Glass wrote: > This is one of several reasons why one would expect freebsd-update(8) to = be > considerate of a custom kernel: it is documented as knowing about > /boot/GENERIC as the place to put he GENERIC kernel if one builds a > custom one. >=20 Let's start from the beginning. What is the name of your custom kernel? Glen > Also, I don't think that freebsd-update(8) should, in the course of a nor= mal > update, create a situation where the system is not be able to reboot. This > would have been the case with the system I updated, had I not caught > the problem. >=20 > I daresay that a system that stops working after a routine update is > a violation > of POLA. ;-) >=20 > In my case, the GENERIC kernel was installed in place of the custom > one, without > modules the system needed -- in either loadable or built-in form. It's ea= sy to > prevent this by modifying /boot/GENERIC (which freebsd-update is > supposed to know > about) instead of overwriting the custom kernel... and then advising the > administrator that a new build might be needed. >=20 > --Brett Glass >=20 > At 10:26 AM 4/30/2013, Chris Rees wrote: >=20 > >I agreed with Glen, but when checking the docs it turns out that they say > >that freebsd-update will detect a kernel in /boot/GENERIC: > > > >http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html > > > >Are the docs wrong, or is this only in new freebsd-update? > > > >Chris > >_______________________________________________ > >freebsd-security@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-security > >To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.o= rg" --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRgDRzAAoJEFJPDDeguUajkAIH/09p5KEJeERfmK9b05Im/aep wbFVSXJR2r0IYzYy8tXvJsgzfil9Y18FfH8MHdp58imHS+8ExngJo2qMaWATJJBb r8ywdFcc7tP4dKuCzjWGCjw/e54pSaVN7SANYFZhLslYaI4gHO/E9qr5AxZ7eIzC NwpUeIf/tnC4e3vfkN/whMxA1aFJ2OZcSMoAq+uQYgAlAXQCn93o00II1oMFM2rg ria0T2PAZb0szF0AsNLprtEoslOEl6IoBPNQ/LLrzRtPdzwn4AkHLZN8/8kWnkYv d4QNnWz4WQSgK8Ptq9+moY09+1t2jRjer/qyz9jG5aa8QNKeyHamZ3X+av6RHAg= =wIWS -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 22:28:58 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A9AE1D1 for ; Tue, 30 Apr 2013 22:28:58 +0000 (UTC) (envelope-from cfp@ruxcon.org.au) Received: from ruxcon.org.au (ruxcon.org.au [192.30.33.242]) by mx1.freebsd.org (Postfix) with ESMTP id CF4751CFC for ; Tue, 30 Apr 2013 22:28:57 +0000 (UTC) Received: by ruxcon.org.au (Postfix, from userid 1002) id 871106CC37; Wed, 1 May 2013 07:57:31 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ruxcon.org.au X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from ruxcon.org.au (localhost [127.0.0.1]) by ruxcon.org.au (Postfix) with ESMTP id 886E26CC21 for ; Wed, 1 May 2013 07:57:28 +1000 (EST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Breakpoint 2013 Call For Papers From: cfp@ruxcon.org.au To: freebsd-security@freebsd.org Message-Id: <20130430215728.886E26CC21@ruxcon.org.au> Date: Wed, 1 May 2013 07:57:28 +1000 (EST) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 22:28:58 -0000 Breakpoint 2013 Call For Papers Melbourne, Australia, October 24th-25th Intercontinental Rialto http://www.ruxconbreakpoint.com .[x]. Introduction .[x]. The Ruxcon team is pleased to announce Call For Papers for Breakpoint 2013. Breakpoint showcases the work of expert security researchers from around the world on a wide range of topics. This conference is organised by the Ruxcon team and offers a specialised security conference to complement and lead into the larger and more casual Ruxcon weekend conference. Breakpoint caters towards security researchers and industry professionals alike, with a focus on cutting edge security research. Breakpoint presents a great opportunity for our selected speakers to receive a complimentary trip to Australia and experience both the Breakpoint and Ruxcon conferences, not to mention the great weather, awesome parties, and friendly people. Melbourne is a city of many subcultures, personalities and styles. Melbourne has a vibrant arts and music scene, eccentric cafes, intimate bars and restaurants, and is known as Australia's cultural capital. .[x]. Important Dates .[x]. May 1 - Call For Presentations Open August 23 - Call For Presentations Close October 22-23 - Breakpoint Training October 24-25 - Breakpoint Conference October 26-27 - Ruxcon Conference .[x]. Topic Scope .[x]. Topics of interest include, but are not limited to: o Mobile Device Security o Exploitation Techniques o Reverse Engineering o Vulnerability Discovery o Rootkit Development o Malware Analysis o Code Analysis o Virtualisation, Hypervisor Security o Cloud Security o Embedded Device Security o Hardware Security o Telecommunications Security o Wireless Network Security o Web Application Security o Law Enforcement Activities o Forensics o Threat Intelligence o You get the idea .[x]. Submission Guidelines .[x]. In order for us to process your submission we will 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 presentation 7. Information on where the presentation material has or will be presented before Breakpoint * Preference will be given to presentations that contain original research that will be first presented at Breakpoint. * As a general guideline, Breakpoint presentations are between 45 and 60 minutes, including question time. If you have any questions about submissions, or would like to make a submission, please send an email to bpx@ruxconbreakpoint.com .[x]. Speaker Benefits .[x]. Speakers at Breakpoint will be entitled to the following benefits: - A return economy airfare to Melbourne (total cost limit applies) - Three nights accommodation at the Intercontinental Rialto - Complimentary registration for Breakpoint and Ruxcon conferences - Invitation to all Breakpoint and Ruxcon parties - Unlock 'Presented on world's smallest continent' achievement * All speaker benefits apply to a single speaker per submission. .[x]. Contact .[x]. If you have any questions or inqueries, contact us at: * Email: bpx@ruxconbreakpoint.com * Twitter: @ruxconbpx From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 22:41:19 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96891367; Tue, 30 Apr 2013 22:41:19 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD311D6C; Tue, 30 Apr 2013 22:41:18 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA05359; Tue, 30 Apr 2013 16:41:10 -0600 (MDT) Message-Id: <201304302241.QAA05359@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Apr 2013 16:41:03 -0600 To: Glen Barber From: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <20130430211531.GA1621@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-security@FreeBSD.org, Colin Percival , Chris Rees X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 22:41:19 -0000 At 03:15 PM 4/30/2013, Glen Barber wrote: >Let's start from the beginning. What is the name of your custom kernel? The file name of the compiled kernel? The file name of the configuration file? Or the identification string within the kernel? The file name is, of course, /boot/kernel/kernel. It's built without modules, so it's the only file in the directory /boot/kernel. The configuration file is at /sys/amd64/conf/GATEWAY. The identification string within the kernel is GATEWAY. I am not sure what you're driving at here, though, so please explain. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Tue Apr 30 22:48:54 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 309204BC; Tue, 30 Apr 2013 22:48:54 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 047111DA9; Tue, 30 Apr 2013 22:48:54 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id C899D23F804; Tue, 30 Apr 2013 18:48:52 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us C899D23F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 30 Apr 2013 18:48:50 -0400 From: Glen Barber To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <20130430224850.GA1579@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <201304302241.QAA05359@lariat.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@FreeBSD.org, Colin Percival , Chris Rees X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 22:48:54 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2013 at 04:41:03PM -0600, Brett Glass wrote: > At 03:15 PM 4/30/2013, Glen Barber wrote: >=20 > >Let's start from the beginning. What is the name of your custom kernel? >=20 > The file name of the compiled kernel? The file name of the configuration = file? > Or the identification string within the kernel? >=20 Yes. (All of them.) > The file name is, of course, /boot/kernel/kernel. It's built without > modules, so > it's the only file in the directory /boot/kernel. >=20 > The configuration file is at /sys/amd64/conf/GATEWAY. >=20 > The identification string within the kernel is GATEWAY. >=20 > I am not sure what you're driving at here, though, so please explain. >=20 What I was getting at is seeing if you had a custom kernel called GENERIC, despite the vast amounts of documentation noting that GENERIC should _not_ be modified to customize the kernel. So, since I know you're not new to FreeBSD, if you feel there is a bug somewhere, please file a PR. I disagree that there is a problem, however, since users building a custom kernel should _not_ use freebsd-update(8) for kernel upgrades. Glen --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRgEpSAAoJEFJPDDeguUajWz4H/jLPw4+qwDGL0olN1EDgr1U0 Y20jp4hiTul5pUaFff57sa71MhgPPpa3yiT/D3PaSf33eLyi+jkK9xcD1k1ShqZZ VneTPq382qFZTsPVi7eBGFxRr3Q6cvO8MfqPg/bbvQ7Yw1Dojul2z/rHLeVxW6SM 9aWPnht6ubVe/qVEEON30ggvkQk+sh6py42+eBszRWU2ozI7A9PsnmWkcgt2OjB7 5QIU8815dXrQBoI4cSlx9jMgSYGh5tkmpDWn89fMNzLyps0m9/FWT3hwnRzcQakZ ARt39VOClQ+HHq1/0kS1Sa4oUVSu8tQivUtR0dqsFWaAI8YjxzrMzjQJ0NCtn40= =hirH -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-security@FreeBSD.ORG Wed May 1 01:49:45 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 047EB54B; Wed, 1 May 2013 01:49:45 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 90F0C11E5; Wed, 1 May 2013 01:49:44 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id TAA07809; Tue, 30 Apr 2013 19:49:39 -0600 (MDT) Message-Id: <201305010149.TAA07809@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Apr 2013 19:48:50 -0600 To: Glen Barber From: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <20130430224850.GA1579@glenbarber.us> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-security@FreeBSD.org, Colin Percival , Chris Rees X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 01:49:45 -0000 At 04:48 PM 4/30/2013, Glen Barber wrote: >So, since I know you're not new to FreeBSD, if you feel there is a bug >somewhere, please file a PR. I disagree that there is a problem, >however, since users building a custom kernel should _not_ use >freebsd-update(8) for kernel upgrades. > >Glen I will do that. BTW, I do not use freebsd-update(8) to update the kernel. But I do need it to update the kernel sources (so I can rebuild the kernel myself) and the userland sources and binaries. After all, I can't rebuild the world on every production server each time there's a security fix to apply. --Brett Glass From owner-freebsd-security@FreeBSD.ORG Wed May 1 02:22:36 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 77B5F8EA; Wed, 1 May 2013 02:22:36 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 024CA128F; Wed, 1 May 2013 02:22:36 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 9FF8623F804; Tue, 30 Apr 2013 22:22:30 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us 9FF8623F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 30 Apr 2013 22:22:28 -0400 From: Glen Barber To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <20130501022228.GD1579@glenbarber.us> References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline In-Reply-To: <201305010149.TAA07809@lariat.net> X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@FreeBSD.org, Colin Percival , Chris Rees X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 02:22:36 -0000 --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2013 at 07:48:50PM -0600, Brett Glass wrote: > At 04:48 PM 4/30/2013, Glen Barber wrote: >=20 > >So, since I know you're not new to FreeBSD, if you feel there is a bug > >somewhere, please file a PR. I disagree that there is a problem, > >however, since users building a custom kernel should _not_ use > >freebsd-update(8) for kernel upgrades. > > >=20 > I will do that. BTW, I do not use freebsd-update(8) to update the kernel.= But > I do need it to update the kernel sources (so I can rebuild the kernel my= self) > and the userland sources and binaries. After all, I can't rebuild the wor= ld > on every production server each time there's a security fix to apply. >=20 Maybe I am missing the fundamental usage of freebsd-update(8). How does using freebsd-update(8) to fetch src/ updates install a new kernel? Pardon my ignorance here - I do not use freebsd-update(8) for any of my systems. Glen --mJm6k4Vb/yFcL9ZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRgHxkAAoJEFJPDDeguUajpsoIAICSoDiDTEgUeeeaND3W9CpN ywkYn5i19qg4Z9m10NWAG+H/JvqRWa2iw9lfgHytpC+TKhmMJnkin6/17DxXlBPB JFvD65Y/r5uepukjkvegZk+lA0e2L9dJ2ozilNn+CBFm+Kc0Wz6hUax5nWDI6xvr J2P5aEjoPiRNRgfI6Kh5VOKiGrpK+YpPAD97u6Lvoo9GSuiMjrQ3YALD4+TRcdzC 3ZCXKR+RtTCJRvMs/bKxes/QVYmm97HeTd8/Vy7619QaYKqRbdpZNiWXJNN4/1y+ EURgQpAkMrn8DduHcKZ01yn8oR16WM7PQ3DVCu7rp6oGIPH04uAlF5nI5sL/h08= =l5I1 -----END PGP SIGNATURE----- --mJm6k4Vb/yFcL9ZU-- From owner-freebsd-security@FreeBSD.ORG Wed May 1 02:43:49 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8825B16; Wed, 1 May 2013 02:43:49 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3B19812FF; Wed, 1 May 2013 02:43:48 +0000 (UTC) Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id UAA08356; Tue, 30 Apr 2013 20:43:45 -0600 (MDT) Message-Id: <201305010243.UAA08356@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Apr 2013 20:43:40 -0600 To: Glen Barber From: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <20130501022228.GD1579@glenbarber.us> References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> <20130501022228.GD1579@glenbarber.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-security@FreeBSD.org, Colin Percival , Chris Rees X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 02:43:49 -0000 At 08:22 PM 4/30/2013, Glen Barber wrote: >Maybe I am missing the fundamental usage of freebsd-update(8). How does >using freebsd-update(8) to fetch src/ updates install a new kernel? When you use freebsd-update(8) in the usual manner, it fetches all of the source and binary updates necessary to bring the system up to the latest security patch level. When a userland binary is updated, it overwrites the source and binary. But when the kernel is updated, it moves /boot/kernel to /boot/kernel.old and then drops a GENERIC kernel into /boot/kernel. If there were no loadable modules in /boot/kernel at the start of the update, none are placed in /boot/kernel afterward. This is problematic, because the custom kernel that previously resided in /boot/kernel might have had some necessary modules built in... and they will not be available, either as compiled-in modules or as loadable modules, at the next reboot. To leave the system in a precarious state, where a power glitch could leave it unable to reboot, does not seem to me like a good idea. If /boot/GENERIC exists (which means that the administrator has built a custom kernel and saved the GENERIC kernel there), best to update /boot/GENERIC and leave the custom kernel in place, to be rebuilt if needed. The administrator will probably want to rebuild his or her custom kernel after the update... unless it didn't contain the code that was fixed by the patch, in which case there's no need. (My kernel didn't contain NFS, and I didn't build any loadable NFS modules, so I actually didn't need a rebuild.) --Brett Glass From owner-freebsd-security@FreeBSD.ORG Wed May 1 02:54:51 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29DC1DEF; Wed, 1 May 2013 02:54:51 +0000 (UTC) (envelope-from m-freebsd@fuglos.org) Received: from m.fuglos.org (m.fuglos.org [217.11.61.114]) by mx1.freebsd.org (Postfix) with ESMTP id E22F2133A; Wed, 1 May 2013 02:54:50 +0000 (UTC) Received: by m.fuglos.org (Postfix, from userid 1001) id 988E235C3F7; Wed, 1 May 2013 04:47:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by m.fuglos.org (Postfix) with ESMTP id 2F4B735B857; Wed, 1 May 2013 04:47:49 +0200 (CEST) Date: Wed, 1 May 2013 04:47:48 +0200 (CEST) From: Melanie Schulte X-X-Sender: mel@m.fuglos.org To: freebsd-security@FreeBSD.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-Reply-To: <20130430224850.GA1579@glenbarber.us> Message-ID: References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Glen Barber X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 02:54:51 -0000 Hi, > I disagree that there is a problem, however, since users building a > custom kernel should _not_ use freebsd-update(8) for kernel > upgrades. Could you please elaborate on that? I have also built my own kernel on my servers and I must have missed the section in the handbook saying that running a custom kernel implies that freebsd-update should not be used. Given a security problem, I don't want to spend hours recompiling my base system whereas freebsd-update fixed the problem in seconds. Thanks, melanie From owner-freebsd-security@FreeBSD.ORG Wed May 1 03:00:59 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45A5D128; Wed, 1 May 2013 03:00:59 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 23A6C1394; Wed, 1 May 2013 03:00:58 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 103C723F804; Tue, 30 Apr 2013 23:00:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.2 onyx.glenbarber.us 103C723F804 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Tue, 30 Apr 2013 23:00:55 -0400 From: Glen Barber To: Melanie Schulte Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <20130501030055.GF1579@glenbarber.us> References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zs/RYxT/hKAHzkfQ" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 03:00:59 -0000 --Zs/RYxT/hKAHzkfQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 01, 2013 at 04:47:48AM +0200, Melanie Schulte wrote: > Hi, >=20 > >I disagree that there is a problem, however, since users building a > >custom kernel should _not_ use freebsd-update(8) for kernel > >upgrades. >=20 > Could you please elaborate on that? I have also built my own kernel on > my servers and I must have missed the section in the handbook saying > that running a custom kernel implies that freebsd-update should not be > used. >=20 > Given a security problem, I don't want to spend hours recompiling my > base system whereas freebsd-update fixed the problem in seconds. >=20 freebsd-update(8) _always_ installs GENERIC. Glen --Zs/RYxT/hKAHzkfQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRgIVnAAoJEFJPDDeguUaju+YH/2fAWKRQoJsHGcLHbhKnDIDG LfXaCkVNxnMqAydrw+gS+wfZRKWi1Yg/lNoQt2gxP8xT8j2PSGEVriDI4j/GjwBt pZ0ndT656kfE/OJGOQ8xAoU+5lGR8aSqdkQdk2puyBfRM78AC4jQ3AnJK+qkoaQO PS49nFNOOSuQ047/hBitxA5RKYRgqzNbVHi5UA7NsF9f/FxfCz/5vpTTqO2Otel7 lnGhUDg0vsi1imS78lUYN2DprvRqbbWfsy89hK47khUTTh8y7BJSd9zR/w4d7H52 U5ndr6J+PC53NRHdN2Iyn8l9K8nAX511M0NFfb1gSUTsgDIt6CCLlsDo2Qtrxlk= =g+ty -----END PGP SIGNATURE----- --Zs/RYxT/hKAHzkfQ-- From owner-freebsd-security@FreeBSD.ORG Wed May 1 03:03:23 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 64FD92F3 for ; Wed, 1 May 2013 03:03:23 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4C13714D9 for ; Wed, 1 May 2013 03:03:22 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 3C68AB82A; Tue, 30 Apr 2013 19:55:32 -0700 (PDT) To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver In-reply-to: Your message of "Tue, 30 Apr 2013 19:48:50 MDT." <201305010149.TAA07809@lariat.net> References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> Comments: In-reply-to Brett Glass message dated "Tue, 30 Apr 2013 19:48:50 -0600." Date: Tue, 30 Apr 2013 19:55:32 -0700 From: Bakul Shah Message-Id: <20130501025532.3C68AB82A@mail.bitblocks.com> Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 03:03:23 -0000 On Tue, 30 Apr 2013 19:48:50 MDT Brett Glass wrote: > > I will do that. BTW, I do not use freebsd-update(8) to update the kernel. But > I do need it to update the kernel sources (so I can rebuild the kernel myself) If you are tracking just the kernel sources, you can use svn to track the releng/9.1 branch. If for some reason you really really want to use freebsd-update, I'd suggest setting up a virtual machine that exactly tracks a release. > and the userland sources and binaries. After all, I can't rebuild the world > on every production server each time there's a security fix to apply. You can use a `staging' server where you can update, build and check things out before a wider deployment. There are tools that allow you to push your changes to the deployed machines. From owner-freebsd-security@FreeBSD.ORG Wed May 1 03:14:08 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 53F39675 for ; Wed, 1 May 2013 03:14:08 +0000 (UTC) (envelope-from bounces+73574-f30d-freebsd-security=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id E22E71596 for ; Wed, 1 May 2013 03:14:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpapi; bh=OxAp/NrIHfN9kyWPtYR1SU HulH4=; b=HJCa+Ta0qB+02GqLo3IxvIRvLiVLCRyTt+nGczHKPdk9YCIsg6wHOk CH6gWFELr6UqIpu8X1kNewhKbZMEVwaZLcxP+9la8L8LXgEQSCBIrfo2EgRMsQp0 9kArn196iHNcVF4Z+ZVzaSZusEqS9dKgCRSNhXTlUGAgiGw5lx+bI= Received: by 10.4.35.242 with SMTP id mf70.23618.5180887E6 Wed, 01 May 2013 03:14:06 +0000 (UTC) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi22 (SG) with ESMTP id 5180887e.698.15f2134 for ; Tue, 30 Apr 2013 22:14:06 -0500 (CST) Received: (qmail 24492 invoked from network); 1 May 2013 03:14:05 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 1 May 2013 03:14:05 -0000 Received: (qmail 13778 invoked from network); 1 May 2013 03:13:09 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 1 May 2013 03:13:09 -0000 Message-ID: <51808845.9040804@freebsd.org> Date: Tue, 30 Apr 2013 20:13:09 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130406 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brett Glass Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> <20130501022228.GD1579@glenbarber.us> <201305010243.UAA08356@lariat.net> In-Reply-To: <201305010243.UAA08356@lariat.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: 5qVSvszVOIE6PbdhSmXigMotnDv2KVF2pFB0fKg9JzpPJtIk/1JjUQ0yoXl0YfxWmKq6vZ7b/gJVDCZc1TZ+O2bfgn214htDbHxcjQgk8JzGuzemketuR1T2FkaGlH2JG1+YKTeuMNsbtTxCYY7ELw== Cc: Glen Barber , Chris Rees , freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 03:14:08 -0000 On 04/30/13 19:43, Brett Glass wrote: > When you use freebsd-update(8) in the usual manner, it fetches all of the > source and binary updates necessary to bring the system up to the latest > security patch level. When a userland binary is updated, it overwrites the > source and binary. But when the kernel is updated, it moves /boot/kernel to > /boot/kernel.old and then drops a GENERIC kernel into /boot/kernel. If > there were no loadable modules in /boot/kernel at the start of the update, > none are placed in /boot/kernel afterward. This is problematic, because > the custom kernel that previously resided in /boot/kernel might have had some > necessary modules built in... and they will not be available, either as > compiled-in modules or as loadable modules, at the next reboot. > > To leave the system in a precarious state, where a power glitch could > leave it unable to reboot, does not seem to me like a good idea. If > /boot/GENERIC exists (which means that the administrator has built a custom > kernel and saved the GENERIC kernel there), best to update /boot/GENERIC and > leave the custom kernel in place, to be rebuilt if needed. If you don't want freebsd-update to update your kernel, remove 'kernel' from the 'Components' line in /etc/freebsd-update.conf. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-security@FreeBSD.ORG Wed May 1 06:23:58 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 95F9AB2E; Wed, 1 May 2013 06:23:58 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1CD1D3C; Wed, 1 May 2013 06:23:58 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ta17so1063106obb.40 for ; Tue, 30 Apr 2013 23:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CFHMDN5RmaaEyYGDJg4EtjA3utqiu366uIbmFEn6H8Q=; b=AeMuShyCbMuRxO2zPjQkLt6CkX/mDxVhQv976uSRWEYtvdzE7+ougz/h2K9RWWWuAA rzxJIhe77Vf1Wy32QUIYgREbO+wFAuO6DOanZqCajW0Xigy1K1elltyV4phOw1KgCUNN M/rzKudCMStUht6wmAjS4VqB70aF/WbmFBBn+GZAjojI5K/OklwM7MvyVJPwPBs1svYQ sIUXdunOyLYlRtlM5Ph0UB1YFWMTBeSJJUqQ1g3N6yLV34B02qqecCMK0DDACb/xhiFc A2Hq6UfvXAzhC2sVW5BcSLAWP18+ZSLD+Dy/UUEUpRzStWfGnee54MpqRpgOU/TjP6Kp zLqw== MIME-Version: 1.0 X-Received: by 10.60.76.234 with SMTP id n10mr360012oew.63.1367389437844; Tue, 30 Apr 2013 23:23:57 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Tue, 30 Apr 2013 23:23:57 -0700 (PDT) In-Reply-To: <201305010243.UAA08356@lariat.net> References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> <20130501022228.GD1579@glenbarber.us> <201305010243.UAA08356@lariat.net> Date: Wed, 1 May 2013 08:23:57 +0200 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver From: Oliver Pinter To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , Chris Rees , Colin Percival , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 06:23:58 -0000 On 5/1/13, Brett Glass wrote: > At 08:22 PM 4/30/2013, Glen Barber wrote: > >>Maybe I am missing the fundamental usage of freebsd-update(8). How does >>using freebsd-update(8) to fetch src/ updates install a new kernel? > > When you use freebsd-update(8) in the usual manner, it fetches all of the > source and binary updates necessary to bring the system up to the latest > security patch level. When a userland binary is updated, it overwrites the > source and binary. But when the kernel is updated, it moves /boot/kernel to > /boot/kernel.old and then drops a GENERIC kernel into /boot/kernel. If > there were no loadable modules in /boot/kernel at the start of the update, > none are placed in /boot/kernel afterward. This is problematic, because > the custom kernel that previously resided in /boot/kernel might have had > some > necessary modules built in... and they will not be available, either as > compiled-in modules or as loadable modules, at the next reboot. > > To leave the system in a precarious state, where a power glitch could > leave it unable to reboot, does not seem to me like a good idea. If > /boot/GENERIC exists (which means that the administrator has built a custom > kernel and saved the GENERIC kernel there), best to update /boot/GENERIC and > > leave the custom kernel in place, to be rebuilt if needed. > > The administrator will probably want to rebuild his or her custom kernel > after the update... unless it didn't contain the code that was fixed by > the patch, in which case there's no need. (My kernel didn't contain NFS, > and I didn't build any loadable NFS modules, so I actually didn't need a > rebuild.) The ultimate solution for you described in loader.conf(5). kernel Name of the kernel to be loaded. If no kernel name is set, no additional modules will be loaded. The name must be a subdirectory of /boot that contains a kernel. And set INSTKERNNAME in make.conf - this are in Makefile.inc1. --8<-- #!/bin/sh echo "INSTKERNNAME=magickernel" >> /etc/make.conf echo "kernel=magickernel" >> /boot/loader.conf cd /usr/src make kernel -->8-- good luck :) > > --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 Wed May 1 08:59:50 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3D2AAD7; Wed, 1 May 2013 08:59:50 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 000281291; Wed, 1 May 2013 08:59:49 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 334C1D9EC; Wed, 1 May 2013 08:59:48 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 7732B35720; Wed, 1 May 2013 10:59:24 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Melanie Schulte Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <201304292055.r3TKtcEs039958@freefall.freebsd.org> <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> Date: Wed, 01 May 2013 10:59:23 +0200 In-Reply-To: (Melanie Schulte's message of "Wed, 1 May 2013 04:47:48 +0200 (CEST)") Message-ID: <86ip33rs7o.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, Glen Barber X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 08:59:50 -0000 Melanie Schulte writes: > Could you please elaborate on that? I have also built my own kernel on > my servers and I must have missed the section in the handbook saying > that running a custom kernel implies that freebsd-update should not be > used. > > Given a security problem, I don't want to spend hours recompiling my > base system whereas freebsd-update fixed the problem in seconds. If you run a stock userland on a custom kernel, freebsd-update will patch your userland but not your kernel. If you must build your own kernel, my recommendation is to install it in a different directory, e.g. /boot/MYKERNEL, instead of /boot/kernel. That way, freebsd-update will keep the original GENERIC kernel (still in /boot/kernel) up-to-date, and in a pinch, you can switch back. The easiest way to do this is to append the following lines to /etc/src.conf before building your kernel for the first time: KERNCONF=3DMYKERNEL KODIR=3D/boot/${KERNCONF} You will also need to add this to /boot/loader.conf so the correct kenel will be loaded at boot time: kernel=3D"MYKERNEL" If you built your kernel from the source tree that came with the release, freebsd-update will have updated the source tree, and all you need to do is rebuild and reinstall the kernel. In most cases, you can get away with "make buildkernel -DKERNFAST", which should only take a few seconds. KERNFAST is safe when you've only changed the contents of a source file, but not your kernel configuration or anything that affects the dependency graph (especially anything under sys/conf). If you checked out your source tree from svn, however, you should tell freebsd-update to leave it alone (remove "src" from the "Components" line in /etc/freebsd-update.conf), and update it yourself with "svn up". You should also remove "src" from the "Components" line if you do not have a source tree at all. Otherwise, freebsd-update may become confused by updates that add a source file, like the OpenSSL update did. Updates that modify a file aren't an issue, because freebsd-update will ignore missing files. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed May 1 10:17:07 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DAD5E1F9 for ; Wed, 1 May 2013 10:17:07 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 81D1C15EA for ; Wed, 1 May 2013 10:17:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <5180E940.80107@intersonic.se> Date: Wed, 01 May 2013 12:06:56 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130310 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <201304292055.r3TKtcrk039951@freefall.freebsd.org> In-Reply-To: <201304292055.r3TKtcrk039951@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 May 2013 11:21:07 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 10:17:07 -0000 Path to patch seems wrong? On 2013-04-29 22:55, FreeBSD Security Advisories wrote: > ============================================================================= > FreeBSD-SA-13:05.nfsserver Security Advisory > The FreeBSD Project > > Topic: Insufficient input validation in the NFS server > > Category: core > Module: nfsserver > Announced: 2013-04-29 > Credits: Adam Nowacki > Affects: All supported versions of FreeBSD. > Corrected: 2013-04-29 20:15:43 UTC (stable/8, 8.4-PRERELEASE) > 2013-04-29 20:15:47 UTC (releng/8.3, 8.3-RELEASE-p8) > 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC1-p1) > 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC2-p1) > 2013-04-29 20:15:55 UTC (stable/9, 9.1-STABLE) > 2013-04-29 20:16:00 UTC (releng/9.1, 9.1-RELEASE-p3) > CVE Name: CVE-2013-3266 > > 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 server and client > implementations of NFS. > > FreeBSD 8.0 and onward has two NFS implementations: the original CSRG > NFSv2 and NFSv3 implementation and a new implementation which also > supports NFSv4. > > FreeBSD 9.0 and onward uses the new NFS implementation by default. > > II. Problem Description > > When processing READDIR requests, the NFS server does not check that > it is in fact operating on a directory node. An attacker can use a > specially modified NFS client to submit a READDIR request on a file, > causing the underlying filesystem to interpret that file as a > directory. > > III. Impact > > The exact consequences of an attack depend on the amount of input > validation in the underlying filesystem: > > - If the file resides on a UFS filesystem on a little-endian server, > an attacker can cause random heap corruption with completely > unpredictable consequences. > > - If the file resides on a ZFS filesystem, an attacker can write > arbitrary data on the stack. It is believed, but has not been > confirmed, that this can be exploited to run arbitrary code in > kernel context. > > Other filesystems may also be vulnerable. > > IV. Workaround > > Systems that do not provide NFS service 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. > > 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-03:15/nfsserver.patch > # fetch http://security.FreeBSD.org/patches/SA-03:15/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 revision numbers of each file that was > corrected in FreeBSD. > > Branch/path Revision > ------------------------------------------------------------------------- > stable/8/ r250058 > releng/8.3/ r250059 > releng/8.4/ r250062 > stable/9/ r250060 > releng/9.1/ r250061 > ------------------------------------------------------------------------- > > VII. References > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3266 > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-13:05.nfsserver.asc > _______________________________________________ > 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" > -- Intersonic AB Registered in Solna, Sweden SE556539368201 From owner-freebsd-security@FreeBSD.ORG Wed May 1 15:23:20 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3431C648 for ; Wed, 1 May 2013 15:23:20 +0000 (UTC) (envelope-from jkois@FreeBSD.org) Received: from tux15.hoststar.at (tux15.hoststar.at [213.239.217.242]) by mx1.freebsd.org (Postfix) with ESMTP id CBA931445 for ; Wed, 1 May 2013 15:23:19 +0000 (UTC) Received: from freebsd.bsdkisten.at (chello084115173108.graz.surfer.at [84.115.173.108]) (authenticated bits=0) by tux15.hoststar.at (8.13.8/8.12.11) with ESMTP id r41FNE7d014424; Wed, 1 May 2013 17:23:14 +0200 Message-ID: <51813364.2040502@FreeBSD.org> Date: Wed, 01 May 2013 17:23:16 +0200 From: Johann Kois User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Per olof Ljungmark Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <201304292055.r3TKtcrk039951@freefall.freebsd.org> <5180E940.80107@intersonic.se> In-Reply-To: <5180E940.80107@intersonic.se> 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.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 15:23:20 -0000 You are using an old version of the Security Advisory. The path mentioned was fixed and the Security Advisory was re-released, also via email: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=30985+0+current/freebsd-security Or use the link on the FreeBSD homepage to get directly to fixed version. jkois -- Johann Kois jkois(at)FreeBSD.org FreeBSD Documentation Project FreeBSD German Documentation Project - https://doc.bsdgroup.de On 05/01/2013 12:06, Per olof Ljungmark wrote: > Path to patch seems wrong? > > On 2013-04-29 22:55, FreeBSD Security Advisories wrote: >> ============================================================================= >> FreeBSD-SA-13:05.nfsserver Security Advisory >> The FreeBSD Project >> >> Topic: Insufficient input validation in the NFS server >> >> Category: core >> Module: nfsserver >> Announced: 2013-04-29 >> Credits: Adam Nowacki >> Affects: All supported versions of FreeBSD. >> Corrected: 2013-04-29 20:15:43 UTC (stable/8, 8.4-PRERELEASE) >> 2013-04-29 20:15:47 UTC (releng/8.3, 8.3-RELEASE-p8) >> 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC1-p1) >> 2013-04-29 20:16:25 UTC (releng/8.4, 8.4-RC2-p1) >> 2013-04-29 20:15:55 UTC (stable/9, 9.1-STABLE) >> 2013-04-29 20:16:00 UTC (releng/9.1, 9.1-RELEASE-p3) >> CVE Name: CVE-2013-3266 >> >> 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 server and client >> implementations of NFS. >> >> FreeBSD 8.0 and onward has two NFS implementations: the original CSRG >> NFSv2 and NFSv3 implementation and a new implementation which also >> supports NFSv4. >> >> FreeBSD 9.0 and onward uses the new NFS implementation by default. >> >> II. Problem Description >> >> When processing READDIR requests, the NFS server does not check that >> it is in fact operating on a directory node. An attacker can use a >> specially modified NFS client to submit a READDIR request on a file, >> causing the underlying filesystem to interpret that file as a >> directory. >> >> III. Impact >> >> The exact consequences of an attack depend on the amount of input >> validation in the underlying filesystem: >> >> - If the file resides on a UFS filesystem on a little-endian server, >> an attacker can cause random heap corruption with completely >> unpredictable consequences. >> >> - If the file resides on a ZFS filesystem, an attacker can write >> arbitrary data on the stack. It is believed, but has not been >> confirmed, that this can be exploited to run arbitrary code in >> kernel context. >> >> Other filesystems may also be vulnerable. >> >> IV. Workaround >> >> Systems that do not provide NFS service 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. >> >> 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-03:15/nfsserver.patch >> # fetch http://security.FreeBSD.org/patches/SA-03:15/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 revision numbers of each file that was >> corrected in FreeBSD. >> >> Branch/path Revision >> ------------------------------------------------------------------------- >> stable/8/ r250058 >> releng/8.3/ r250059 >> releng/8.4/ r250062 >> stable/9/ r250060 >> releng/9.1/ r250061 >> ------------------------------------------------------------------------- >> >> VII. References >> >> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3266 >> >> The latest revision of this advisory is available at >> http://security.FreeBSD.org/advisories/FreeBSD-SA-13:05.nfsserver.asc >> _______________________________________________ >> 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 2 09:45:24 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 865CFDD6 for ; Thu, 2 May 2013 09:45:24 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8C71114 for ; Thu, 2 May 2013 09:45:23 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 14A6FDA42; Thu, 2 May 2013 09:45:17 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id CD8313583A; Thu, 2 May 2013 11:44:53 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Per olof Ljungmark Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver References: <201304292055.r3TKtcrk039951@freefall.freebsd.org> <5180E940.80107@intersonic.se> Date: Thu, 02 May 2013 11:44:53 +0200 In-Reply-To: <5180E940.80107@intersonic.se> (Per olof Ljungmark's message of "Wed, 01 May 2013 12:06:56 +0200") Message-ID: <861u9paf6y.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 09:45:24 -0000 Per olof Ljungmark writes: > Path to patch seems wrong? Please see the revised advisory which was published a few hours later. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no