from http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:146 === SGI developers discovered a remote DoS (Denial of Service) condition in the NFS statd server. rpc.statd did not ignore the "SIGPIPE" signal which would cause it to shutdown if a misconfigured or malicious peer terminated the TCP connection prematurely. === ------- Additional Comments From jpdalbec 2004-12-13 12:22:18 ---- 04.49.10 CVE: CAN-2004-1014 Platform: Linux Title: NFS rpc.statd Remote Denial of Service Description: rpc.statd implements the NSM (Network Status Monitor) RPC protocol. rpc.statd fails to ignore the SIGPIPE signal and terminates on receiving this signal. nfs-utils version 1.0.6 is affected. Ref: http://www.securityfocus.com/bid/11785 ------- Additional Comments From bugzilla.fedora.us 2004-12-14 12:13:24 ---- CAN-2004-0946 affects 64-bit archs. http://bugs.gentoo.org/show_bug.cgi?id=72113 from http://security.gentoo.org/glsa/glsa-200412-08.xml == Arjan van de Ven has discovered a buffer overflow on 64-bit architectures in 'rquota_server.c' of nfs-utils (CAN-2004-0946). == ------- Additional Comments From pekkas 2004-12-20 00:23:37 ---- For 1014 also see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139611 (no info at the moment) ------- Additional Comments From pekkas 2004-12-23 06:10:39 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Created packages, by taking the patch from RHEL3 update and backporting it. CAN-2004-0946 is not fixed (even in RHEL), because rpc.rquotad supplied with this code is not installed. Rquotad comes from 'quota' package (which may or may not be affected, I did not investigate). Further, FL does not support 64 bit architectures in any case. The patch for 1014 has a bit non-critical fixes on the side, but because that's what's shipped with RHEL3, that's what I used. Backporting was trivial. Note that the stat code does not exist in either 1.0.1 or 0.3.3. Please note that RHL73 package does not rebuild on newer systems (because there are some installed files which are not packaged), but I did not want to change the packaging to fix this, but instead built it on a RHL73 system. RHL73, RHL9 and FC1 in that order: http://www.netcore.fi/pekkas/linux/nfs-utils-0.3.3-6.73.1.legacy.src.rpm http://www.netcore.fi/pekkas/linux/nfs-utils-1.0.1-3.9.1.legacy.src.rpm http://www.netcore.fi/pekkas/linux/nfs-utils-1.0.6-1.1.legacy.src.rpm 84946a53ac15d7a1767608573f304137f7700ae2 nfs-utils-0.3.3-6.73.1.legacy.src.rpm 8a84cfefb14577901d886dce7ca89548f7da308c nfs-utils-1.0.1-3.9.1.legacy.src.rpm e52ac07926c7ff1155b39cf6c39022cf48fefdf4 nfs-utils-1.0.6-1.1.legacy.src.rpm * Thu Dec 23 2004 Pekka Savola <pekkas> 1.0.1-3.9.1.legacy - - Backport statd fixes from RHEL3 to fix CAN-2004-1014. (#2339) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFByuyuGHbTkzxSL7QRAosiAJ0Z/FMln4Tfu6xjvjn+/Srj6GIWlACgwnSn byOd6RMbmehD7h1AnCK/GDo= =Ue5i -----END PGP SIGNATURE----- ------- Additional Comments From rob.myers.edu 2004-12-24 04:55:24 ---- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i did QA on pekka's nfs-utils rpms: rh73: 84946a53ac15d7a1767608573f304137f7700ae2 nfs-utils-0.3.3-6.73.1.legacy.src.rpm sha1sum ok release number ok source files ok - verified against nfs-utils-0.3.3-6.73 patch ok - verified as good backport against nfs-utils-1.0.6-1 - fixes CAN-2004-1014 spec file ok builds fine in mach despite "installed but unpackaged files" warning on newer systems cra's rpm-build-compare script looks good rh9: 8a84cfefb14577901d886dce7ca89548f7da308c nfs-utils-1.0.1-3.9.1.legacy.src.rpm sha1sum ok release number ok source files ok - verified against nfs-utils-1.0.1-3.9 patch ok - verified against nfs-utils-0.3.3-6.73.1.legacy - fixes CAN-2004-1014 spec file ok builds fine in mach cra's rpm-build-compare script looks good fc1: e52ac07926c7ff1155b39cf6c39022cf48fefdf4 nfs-utils-1.0.6-1.1.legacy.src.rpm sha1sum ok release number ok source files ok - verified against nfs-utils-1.0.6-1 patch ok - verified from RHEL3 nfs-utils-1.0.6-33EL - fixes CAN-2004-1014 spec file ok builds fine in mach cra's rpm-build-compare script looks good this file is available at: http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/2339-qa.txt.asc +PUBLISH rh73, rh9, fc1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBzC1ztU2XAt1OWnsRAqyLAJ0XvmGr6ODuoqXf/91cJrFoR4Rm+QCfTKo8 jEeXzxqExdhFkJ//M1OpP3g= =0ja8 -----END PGP SIGNATURE----- ------- Additional Comments From marcdeslauriers 2005-02-09 16:16:38 ---- Packages were pushed to updates-testing. ------- Additional Comments From pizza 2005-03-06 04:08:45 ---- QA on RH9: Package installs and GPG verifies okay. All NFS exports seem to have continues working, though none are heavily-loaded servers. WorksForMe(tm) QA on FC1: Package installs and GPG verifies okay. No further testing, as there are no active exports on any of my FC1 boxen. (Hey, at least it doesn't make the machine HACF..) +VERIFY RH9 ------- Bug moved to this database by dkl 2005-03-30 18:30 ------- This bug previously known as bug 2339 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=2339 Originally filed under the Fedora Legacy product and Package request component. Unknown priority P2. Setting to default priority "normal". Unknown platform PC. Setting to default platform "All". Unknown operating system Windows XP. Setting to default OS "Linux". The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, dkl. Previous reporter was bugzilla.fedora.us. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL 7.3 Package: nfs-utils-0.3.3-6.73.1.legacy.i386.rpm Signatures and checksums seem okay. Package installed on active, busy NFS server without problem. Installed via "rpm -Uhv". It stopped/started mountd, NFS daemon, NFS quotas, and NFS services. Did not appear to restart rpc.statd, which worries me since the bug description makes it sound like a DoS in statd, so I'm wondering if rpc.statd should have been restarted? Processes before install: rpc 1602 1 0 Apr03 ? 00:00:12 portmap rpcuser 1630 1 0 Apr03 ? 00:00:03 rpc.statd root 1914 1 0 Apr03 ? 00:00:01 rpc.rquotad root 1935 1933 0 Apr03 ? 00:00:00 [rpciod] root 2003 1 0 Apr03 ? 00:00:00 rpc.mountd -p 2219 Processes after install: rpc 1602 1 0 Apr03 ? 00:00:12 portmap rpcuser 1630 1 0 Apr03 ? 00:00:03 rpc.statd root 13288 1 0 12:59 ? 00:00:00 rpc.rquotad root 13308 13307 0 12:59 ? 00:00:00 [rpciod] root 13377 1 0 12:59 ? 00:00:00 rpc.mountd -p 2219 Note that portmap and rpc.statd did not restart. Would need to run /etc/rc.d/init.d/nfslock to restart statd on RHL 7.3 systems. Restarted statd, and all NFS and file locking still working. Package seems to work fine, but question if statd needs to be restarted or not. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCXA+w4jZRbknHoPIRAjcrAJ4uZr6RGAH/d8LkvBBLsmf620kCfQCfQymh 2p/XfCgJ7rUqF6b0pSkB3Sk= =GXqb -----END PGP SIGNATURE-----
I think the general assumption in Red Hat and friends is that daemons are not ever restarted by updates. Worth mentioning in the advisory, though, maybe.
As I stated, it *did* restart daemons, in particular the rpc.rquotad, the rpciod/nfsd, and rpc.mountd all restarted. The fact that it didn't touch portmap is normal (no reason to). But it *did* restart all NFS services *except* for statd, which is, IIRC, where the bug is actually at, no? So, either it needs to restart statd, or it shouldn't restart any of them, or I'm mistaken about where the bug is in which case everything is fine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ++VERIFY RHL 7.3 sha1sums: 8c5abe86dcf8c54d71fdb7431df159405fed830b nfs-utils-0.3.3-6.73.1.legacy.i386.rpm rpm --checksig -v: nfs-utils-0.3.3-6.73.1.legacy.i386.rpm: MD5 sum OK: b78a4f50bcae94d04e15177bae2c05c6 gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Sat 05 Feb 2005 05:44:23 PM EST using DSA key ID 731002FA gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) <secnotice>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA Installed on production NFS server and NFS clients, no locking issues noted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCZQEhJL4A+ldA7asRApCxAJ9oNDErmTeTOh9k+7pmH726pQhGpwCeO44u UWZx8UVdUvixro6XziQ04Q4= =tdmN -----END PGP SIGNATURE-----
Sorry, forgot about line wrapping. Trying again. This is modulo the issue of what services should/should not be restarted, of course. I guess my vote would be not to restart any of the services automatically. Maybe we could display a message that the services need to be restarted by the administrator. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ++VERIFY RHL 7.3 sha1sums: 8c5abe86dcf8c54d71fdb7431df159405fed830b nfs-utils-0.3.3-6.73.1.legacy.i386.rpm rpm --checksig -v: nfs-utils-0.3.3-6.73.1.legacy.i386.rpm: MD5 sum OK: b78a4f50bcae94d04e15177bae2c05c6 gpg: Warning: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Sat 05 Feb 2005 05:44:23 PM EST using DSA key ID 731002FA gpg: Good signature from "Fedora Legacy (http://www.fedoralegacy.org) <secnotice>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Fingerprint: D66D 121F 9784 5E7B 2757 8C46 108C 4512 7310 02FA Installed on production NFS server and NFS clients, no locking issues noted. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCZQHHJL4A+ldA7asRAkP+AKC35iC4dfYIDnvi3IKLKn2bvCnO5wCfTgio ofJox1TdovUaKza0JCfV38U= =y29T -----END PGP SIGNATURE-----
I'm okay with it restarting all services, and I'm okay with it not restarting any services. But the current behaviour seems at least inconsistent, and if the bug is in statd, then downright dangerous as it appears that everything is restarted an no further action is required when in reality another daemon restart would be needed. I don't think printing a message from the RPM would fly, but there is a section in the advisory template for additional instructions where we can note the need to restart daemons.
The restarting part is non-trivial. For example, RHL73 runs 'restart' for nfs.init only; the init scripts don't even support condrestart. RHL9 does not run any restarting at all; FC devel tree runs condrestart for rpcidmapd, rpcgssd, and nfs. (The first two are recent FC additions.) So if we assume that the latest FC should be OK, there is no need to restart nfslock (also including statd), so that's OK. I guess we could make (cond)restarting 'nfs' more consistent, but I fear that has the chance of breaking more than fixing. But if the folks want to make it more consistent, that's possible; move or add the nfs condrestart line from %post to %postun (ensure it's like below). %postun if [ "$1" -ge 1 ]; then /etc/rc.d/init.d/nfs condrestart > /dev/null fi (note: in some versions, the restart was done at %post) But as said, I'm afraid this might break more than it fixes.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL 9 Package: nfs-utils-1.0.1-3.9.1.legacy.i386.rpm Signatures and checksums seem okay. Package installed on active, lightly loaded NFS servers and clients. No problems noticed. Didn't restart rpc.statd, which still worries me (see RHL 7.3 report I filed above) but seems fine, both before and after I manually restart the daemons. ++VERIFY RHL 9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCb9U14jZRbknHoPIRAvpwAJ9hz2O4KJVeZbBoV8UXPQX/V3DuogCdGpjk PxUr94NvQb3HNORvBgqcv/Q= =s+86 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for RHL 7.3 Sckage: nfs-utils-0.3.3-6.73.1.legacy.i386.rpm Signatures and checksums seem okay Installed on very busy NFS server, no problems after two weeks of use. I'm still concerned about the daemons restarting, but not enough to hold up the packages. I second the idea about noting in the advisory about the user may want to restart the daemons after the update. ++VERIFY RHL 7.3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCb9ba4jZRbknHoPIRAu2MAJ0SG5H0lETkpIvLWtLjctDA3TOQzACgqyeN 2GvdbHXE46QVOWIOvpLzWlU= =3n8L -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FC1 Verify: sha1: 8720cd5101f6d989e2f0695a54049561644ccd93 nfs-utils-1.0.6-1.1.legacy.i386.rpm signatures: nfs-utils-1.0.6-1.1.legacy.i386.rpm: Header V3 DSA signature: OK, key ID 731002fa Header SHA1 digest: OK (94b2f0e2c537ada6f345e73d4d504f70ece13d60) MD5 digest: OK (1e982ac8f88e604efd20e8447a04ac4b) V3 DSA signature: OK, key ID 731002fa installed without any warnings or errors I nfs mounted a share from a FreeBSD server, created and removed some files, walked around through the nfs mount. Everything appears to work normally. I also verified that "showmount -e" works as expected. +VERIFY FC1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCgRXb+CqvSzp9LOwRApa0AJ91KyNfgKBhL8a/ST5gzbDsq7euQQCdGmFs un0O6+xBmvVDC/V0zWGAcwk= =MJyx -----END PGP SIGNATURE-----
Released to updates