xorl %eax, %eax

CVE-2011-1749: nfs-utils mount.nfs Corruption of /etc/mtab

leave a comment »

This vulnerability is identical to CVE-2011-1089 where GNU C Library’s addmntent() could corrupt the /etc/mtab file when small RLIMIT_FSIZE value was set. The nfs-utils project includes its own implementation of the aforementioned routine that resides in support/nfs/nfs_mntent.c source code file.

int
nfs_addmntent (mntFILE *mfp, struct mntent *mnt) {
	char *m1, *m2, *m3, *m4;
	int res;

	if (fseek (mfp->mntent_fp, 0, SEEK_END))
		return 1;			/* failure */

	m1 = mangle(mnt->mnt_fsname);
	m2 = mangle(mnt->mnt_dir);
	m3 = mangle(mnt->mnt_type);
	m4 = mangle(mnt->mnt_opts);

	res = fprintf (mfp->mntent_fp, "%s %s %s %s %d %d\n",
		       m1, m2, m3, m4, mnt->mnt_freq, mnt->mnt_passno);

	free(m1);
	free(m2);
	free(m3);
	free(m4);
	return (res < 0) ? 1 : 0;
}

Since there is no check that the data are correctly written into ‘mfp->mntent_fp’ file pointer, it could result in partial update of the ‘/etc/mtab’, leaving a corrupted file. A user can trigger this behavior by setting a low value in RLIMIT_FSIZE in the mount.nfs process.

Although there is still no official patch to fix this issue, Vincent Danen suggested using fflush(3) to ensure that data are written before proceeding to updating the file.
His suggestion was to update the ‘return’ to include an additional check.

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

Written by xorl

April 26, 2011 at 20:01

Posted in bugs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s