This is just to note that the Red Hat Security Response team have issued a preliminary comment on the 2.6.30 kernel null pointer vulnerability, as a comment in the associated bugzilla entry:

From Eugene Teo (Security Response Team)  2009-07-17 07:23:57 EDT

The Red Hat Security Response Team is aware of the Linux kernel local privilege
escalation exploit that is published in a number of security mailing lists and
websites. The flaw identified by CVE-2009-1897 is a null pointer dereference
vulnerability in the tun_chr_poll() function of the Linux kernel, introduced
via the upstream git commit 33dccbb0. This flaw affects kernel versions between
2.6.30-rc1 and 2.6.30-rc3 2.6.31-rc3 , and was addressed via the upstream
git commit 3c8a9c63.

The flaw affects only the Red Hat Enterprise Linux 5.4 beta kernel as the
upstream git commit 33dccbb0 was backported to the kernel as a normal bug fix.
We will be addressing this flaw in a future update to the beta kernel. It is
also possible to mitigate this flaw by ensuring that the permissions for
/dev/net/tun is restricted to root only.

The default SELinux policy, in Red Hat Enterprise Linux 5, allows processes in
the unconfined domains to map low memory in the kernel. The exploit did not
bypass the null pointer dereference protection in the Linux kernel. However, we
are updating the selinux-policy package to change this default configuration,
so that it prevents the unconfined processes from being able to map the low
memory. See bug 511143 for more information.

This issue does not affect any other released kernel in any Red Hat product.

In addition, future updates to Red Hat Enterprise Linux kernels may include the
'-fno-delete-null-pointer-checks' gcc CFLAGS. See:
http://git.kernel.org/linus/a3ca86aea507904148870946d599e07a340b39bf

We would like to thank Brad Spengler for bringing these issues to our
attention.

Note that I’m not a member of the security response team: I’m cc’d on the bug and noticed the statement when it was posted.

It is also worth highlighting that you should ensure that the permissions on

/dev/net/tun

are correct.  It should look like this:


# ls -l /dev/net/tun
crw------- 1 root root 10, 200 2009-07-07 09:52 /dev/net/tun


It’s possible that some VPN package may change the permissions on this.

In terms of the SELinux aspect of the exploit, I’ve posted a brief comment in the LWN thread here.

Yes, there was a mistake in the SELinux policy, which allowed the unconfined user to bypass the mmap_min_addr check, which otherwise would have been enforced if the check was enabled (many disable it to get wine etc. working, btw, google disable mmap_min_addr).

This is being fixed in the policy.

The lesson learned here is that more careful review of policy changes needs to happen, and to ask the question as to whether the policy is capable of weakening default security.

The LSM interface is theoretically designed to only allow further restriction of access, but this is a special case, where we are applying policy to a kernel compilation option which can also have its value set via a sysctl. It’s not a typical “access this resource or not?” decision.

The policy bug is now fixed in the selinux-policy-2.4.6-252.el5 package.

The challenge now is to try and ensure that we don’t see this class of problem crop up again, for unusual cases such as this where the normally “restrictive” mode of LSM (i.e. where permissions can only be further restricted) does not apply.  We may need to rethink how this is managed in the kernel to reduce the possibility of such issues in LSM module policy, as the LSM API here appears to be violating the Hard to Misuse design principle.