Security Alerts Need To Suck Less   3 comments

As a systems administrator, I get a lot of security vulnerability alerts. Since I do Linux and Windows, I get sandblasted with them on a distressingly regular basis; security vulnerabilities usually come in blocks, and are often grouped in bunches by operating system, so if you’re lucky enough to just do Solaris (for example) you have a bad month or two during a year when all of the Solaris security guys publish all their stuff in chunks, but for the most part you can cheerfully ignore the IIS, IE, Apache, or Linux kernel updates that come your way.

You handle two major operating systems, you always have something to read about.

I’m going to write this post about a particular security vulnerability, recently published, for the Linux kernel, to illustrate how bad the handling of security vulnerabilities is done in our industry.

Here’s the vulnerability, according to CAIC. Here it is, according to CERT. Oh, wait… no, it’s not. CERT doesn’t have it in the list yet. Here it is on Secunia. Here it is on SecurityFocus. Here it is on NIST. And ISS, and FrSIRT, and blah, blah, blah.

CAIC’s summary:

The risk is MEDIUM. A loal attacker can exploit this issue to access arbitrary files on the affected computer. Successfully exploiting this issue may grant the attacker elevated privileges on affected computers.

ISS’s summary:

The Linux kernel could allow a local attacker to bypass security restrictions, caused by a vulnerability when opening a directory and checking the access modes and open flags. If write privileges for the directory are truncated, a local attacker could call the open() function using specific flags to bypass security restrictions and truncate arbitrary directories.

FrSIRT’s summary:

A vulnerability has been identified in Linux Kernel, which could be exploited by malicious users to bypass security restrictions. This issue is caused by an error in the “may_open()” [fs/namei.c] function that performs tests of access mode by using the “flag” variable instead of the “acc_mode” variable, which could be exploited by local attackers to bypass file permissions and gain unauthorized access to certain files.

Secunia’s summary:

Less critical Impact: Security Bypass, Manipulation of data

Security Focus says:

A local attacker can exploit this issue to access arbitrary files on the affected computer. Successfully exploiting this issue may grant the attacker elevated privileges on affected computers. Other attacks are also possible.

NIST weighs in:

VFS in the Linux kernel before 2.6.22.16, and 2.6.23.x before 2.6.23.14, performs tests of access mode by using the flag variable instead of the acc_mode variable, which might allow local users to bypass intended permissions and remove directories. Impact Type: Provides administrator access, Allows complete confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service. CVSS Severity (version 2.0): CVSS v2 Base score: 7.2 (High)

Six different security databases, three different ratings. “High”, “Medium”, “Less Critical”.

Six different security databases, six different summaries of what an attacker can actually do by exploiting this vulnerability, some of which sound functionally equivalent to “OMG h4x0r pwndage imminent!”

Six different security databases, six links to the kernel.org changelog. Well, at least they all did one thing exactly the same.

Of course, if you’re going to link to Bill Roman’s original bug report, maybe you might (as a security database) want to link to THIS version, which includes the actual code change to fix the problem. This contains, you know, actual information about the problem Bill found.

 fs/namei.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 3b993db..73e2e66 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1605,7 +1605,7 @@ int may_open(struct nameidata *nd, int acc_mode, int flag)
        if (S_ISLNK(inode->i_mode))
                return -ELOOP;

-       if (S_ISDIR(inode->i_mode) && (flag & FMODE_WRITE))
+       if (S_ISDIR(inode->i_mode) && (acc_mode & MAY_WRITE))
                return -EISDIR;

        /*
@@ -1620,7 +1620,7 @@ int may_open(struct nameidata *nd, int acc_mode, int flag)
                        return -EACCES;

                flag &= ~O_TRUNC;
-       } else if (IS_RDONLY(inode) && (flag & FMODE_WRITE))
+       } else if (IS_RDONLY(inode) && (acc_mode & MAY_WRITE))
                return -EROFS;

        error = vfs_permission(nd, acc_mode);
-

Now, I’m not a real C programmer, and I’m certainly not a kernel engineer. I know very little about namei.c (here’s the code for the whole thing). People who actually know code are testing this out. Here’s the previous version. The clip we’re interested in is this:

int may_open(struct nameidata *nd, int acc_mode, int flag)
{
	struct dentry *dentry = nd->dentry;
	struct inode *inode = dentry->d_inode;
	int error;

	if (!inode)
		return -ENOENT;

	if (S_ISLNK(inode->i_mode))
		return -ELOOP;

	if (S_ISDIR(inode->i_mode) && (flag & FMODE_WRITE))
		return -EISDIR;

	error = vfs_permission(nd, acc_mode);
	if (error)
		return error;

	/*
	 * FIFO's, sockets and device files are special: they don't
	 * actually live on the filesystem itself, and as such you
	 * can write to them even if the filesystem is read-only.
	 */
	if (S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) {
	    	flag &= ~O_TRUNC;
	} else if (S_ISBLK(inode->i_mode) || S_ISCHR(inode->i_mode)) {
		if (nd->mnt->mnt_flags & MNT_NODEV)
			return -EACCES;

		flag &= ~O_TRUNC;
	} else if (IS_RDONLY(inode) && (flag & FMODE_WRITE))
		return -EROFS;
	/*
	 * An append-only file must be opened in append mode for writing.
	 */
	if (IS_APPEND(inode)) {
		if  ((flag & FMODE_WRITE) && !(flag & O_APPEND))
			return -EPERM;
		if (flag & O_TRUNC)
			return -EPERM;
	}

	/* O_NOATIME can only be set by the owner or superuser */
	if (flag & O_NOATIME)
		if (current->fsuid != inode->i_uid && !capable(CAP_FOWNER))
			return -EPERM;

	/*
	 * Ensure there are no outstanding leases on the file.
	 */
	error = break_lease(inode, flag);
	if (error)
		return error;

	if (flag & O_TRUNC) {
		error = get_write_access(inode);
		if (error)
			return error;

		/*
		 * Refuse to truncate files with mandatory locks held on them.
		 */
		error = locks_verify_locked(inode);
		if (!error) {
			DQUOT_INIT(inode);

			error = do_truncate(dentry, 0, ATTR_MTIME|ATTR_CTIME, NULL);
		}
		put_write_access(inode);
		if (error)
			return error;
	} else
		if (flag & FMODE_WRITE)
			DQUOT_INIT(inode);

	return 0;
}

Looks like the old version errors out, or truncates things.

Now, admittedly, this is a bad thing. Anyone who is worried about data retention is going to be worried about this. But actually exploiting this would be *hard*, for one thing, and it doesn’t “provide administrative access” or “unauthorized data disclosure”. Telling someone that this gives an attacker “elevated privileges on affected computers” or “other attacks are possible” is technically true, but totally useless information from a risk analysis standpoint.

Who is to blame for this nightmare of conflicting information? Well, I’ll give props to Bill for finding the bug, but he didn’t do a good job of explaining what the actual possible effects of the problem were. That’s not really Bill’s fault; he’s talking on a kernel mailing list with a bunch of geeks that make me look like an idiot, and they know in their heads what the possible applications of this problem really are. The security vendors all cross-link each other in their own databases, so it’s obvious that there is some level of awareness that other security databases exist, but they don’t use the same terminology, they don’t use the same encoding for threat levels, and it’s painfully obvious that at least some of them HAVE NO IDEA WHAT THEY ARE TALKING ABOUT. Heck, I could be wrong in my estimation of what’s going on here, I don’t have the time to dig through the entire namei.c function and find out if my logic is correct. But the functional description of what the vulnerability *is* doesn’t match.

Will you people get your $!@&^* together, for crying out loud? Maybe you could have *one* database, and instead of paying to maintain your own individual ones, hire a couple of people to actually put meaningful information in your summaries?

Digg!

Advertisements

Posted January 24, 2008 by padraic2112 in security, software, tech, web sites

3 responses to “Security Alerts Need To Suck Less

Subscribe to comments with RSS.

  1. Actually, that’s what the National Vulnerability Database aims to accomplish. And the CVSS score (7.2 == High) is generated algorithmically, and the CVSS scoring tool lets you refine the score if you have a particular scenario in mind or additional knowledge.

    Maybe you have a better idea how it could be done?

    In any case, your frustration is misplaced. The problem is all the morons writing insecure code–this is why you have a constant barrage of alerts. If all we had to deal with was the odd Linux kernel hack, rather than the constant yammering backdrop of vulnerabilities in phpBB and all the homegrown credit card processing applications, etc, etc, etc, things would be a lot quieter around here…

  2. > Maybe you have a better idea how it could be done?

    It would probably be a good start for the various databases to sit down and define terminology. Having a numeric score isn’t as important as having defined different levels of access. Secunia’s use of descriptors is better than most, but “security bypass” is distressingly uninformative.

    It’s also somewhat disingenuous for all of these organizations to aggregate information without processing it properly. Rather than see six different organizations try and publish complete descriptions of every vulnerability (and do it badly), it would make more sense for them to concentrate on analyzing vulnerabilities in an organizational area of expertise, and share those results. My guess is that right now they all rush to put up *some* analysis of whatever vulnerability gets published, rather than creating a thorough analysis.

    > Your frustration is misplaced. The problem is all the morons writing insecure code.

    One of the root causes of the problem is insecure code, sure. Given the history of programming, I don’t think this problem is going to go away any time soon. I am frustrated with insecure code, but that’s not really what this post is about.

    Presumably security vulnerability database maintainers have some expertise to provide to the general community, this is why they publish their databases. Having six different databases describe the same issue in wildly varying ways (some of which are out-and-out contradictory) is just spreading FUD, and doesn’t help the practical problem of trying to keep a deployed cluster in a state of reasonable insecurity.

  3. Pingback: Theme Thursday: Vegetable « Pat’s Daily Grind

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

%d bloggers like this: