It was found that mount.nfs suffers from the same flaw as other mount helpers (see CVE-2011-1089). Instead of using addmntent(), nfs-utils implements its own similar function (nfsaddmntent()) which also fails to anticipate whether resource limits would interfere with correctly writing to /etc/mtab. A local user could use this to trigger corruption of the /etc/mtab file via a process with a small RLIMITFSIZE value.

In nfs-utils-1.2.3/support/nfs/nfsmntent.c:

126 int 127 nfsaddmntent (mntFILE mfp, struct mntent mnt) { 128 char m1, m2, m3, m4; 129 int res; 130 131 if (fseek (mfp->mntentfp, 0, SEEKEND)) 132 return 1; / failure / 133 134 m1 = mangle(mnt->mntfsname); 135 m2 = mangle(mnt->mntdir); 136 m3 = mangle(mnt->mnttype); 137 m4 = mangle(mnt->mntopts); 138 139 res = fprintf (mfp->mntentfp, "%s %s %s %s %d %d\n", 140 m1, m2, m3, m4, mnt->mntfreq, mnt->mntpassno); 141 142 free(m1); 143 free(m2); 144 free(m3); 145 free(m4); 146 return (res < 0) ? 1 : 0; 147 }

The above function should use fflush() and return failure based on the success of the fflush() call, to ensure it is fully written prior to updating /etc/mtab. Perhaps something like:

146 return (res < 0) ? 1 : ((fflush(mfp->mntentfp) == 0) ? 0 : 1);

A certain Red Hat build script for nfs-utils before 1.0.9-35z.el52 on Red Hat Enterprise Linux (RHEL) 5 omits TCP wrappers support, which might allow remote attackers to bypass intended access restrictions.

A security flaw was found in the way nfs-utils performed authentication of an incoming request, when an IP based authentication mechanism was used and certain file systems were exported to either to a netgroup or a wildcard (e.g. .my.domain), and some file systems (either the same or different to the first set) were exported to specific hosts, IP addresses, or a subnet. A remote attacker, able to create global DNS entries could use this flaw to access above listed, exported file systems.

References: [1] https://bugzilla.novell.com/showbug.cgi?id=701702 [2] http://www.openwall.com/lists/oss-security/2011/06/27/7 (CVE Request)

Relevant upstream patch: [3] http://marc.info/?l=linux-nfs&m=130875695821953&w=2

It was reported [1],[2] that rpc.gssd in nfs-utils is vulnerable to DNS spoofing due to it depending on PTR resolution for GSSAPI authentication. Because of this, if a user where able to poison DNS to a victim's computer, they would be able to trick rpc.gssd into talking to another server (perhaps with less security) than the intended server (with stricter security). If the victim has write access to the second (less secure) server, and the attacker has read access (when they normally might not on the secure server), the victim could write files to that server, which the attacker could obtain (when normally they would not be able to). To the victim this is transparent because the victim's computer asks the KDC for a ticket to the second server due to reverse DNS resolution; in this case Krb5 authentication does not fail because the victim is talking to the "correct" server.

A patch that prevents this issue has been posted [3].

To workaround this issue, set the IP/host pair in /etc/hosts so that it cannot be spoofed.

A good explanation is also available here [4].

[1] http://marc.info/?l=linux-nfs&m=136491998607561&w=2 [2] http://marc.info/?l=linux-nfs&m=136500502805121&w=2 [3] http://marc.info/?l=linux-nfs&m=136493115612397&w=2 [4] http://ssimo.org/blog/id015.html