First published: Tue Apr 19 2011(Updated: )
It was found that mount.nfs suffers from the same flaw as other mount helpers (see <a href="https://access.redhat.com/security/cve/CVE-2011-1089">CVE-2011-1089</a>). Instead of using addmntent(), nfs-utils implements its own similar function (nfs_addmntent()) 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 RLIMIT_FSIZE value. In nfs-utils-1.2.3/support/nfs/nfs_mntent.c: 126 int 127 nfs_addmntent (mntFILE *mfp, struct mntent *mnt) { 128 char *m1, *m2, *m3, *m4; 129 int res; 130 131 if (fseek (mfp->mntent_fp, 0, SEEK_END)) 132 return 1; /* failure */ 133 134 m1 = mangle(mnt->mnt_fsname); 135 m2 = mangle(mnt->mnt_dir); 136 m3 = mangle(mnt->mnt_type); 137 m4 = mangle(mnt->mnt_opts); 138 139 res = fprintf (mfp->mntent_fp, "%s %s %s %s %d %d\n", 140 m1, m2, m3, m4, mnt->mnt_freq, mnt->mnt_passno); 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->mntent_fp) == 0) ? 0 : 1);
Credit: secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Linux-nfs Nfs-utils | <=1.2.3 | |
Linux-nfs Nfs-utils | =1.2.2 | |
Linux-nfs Nfs-utils | =1.2.1 | |
Linux-nfs Nfs-utils | =1.2.0 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.