Holes

A week ago the OpenBSD 4.2 errata page have been updated with two fixes or vulnerabilities, depending on who you ask. In case you are not aware, OpenBSD doesn't have formal or official security advisories. You have to check the errata page for security vulnerabilities.

• 008: RELIABILITY FIX: February 25, 2008 All architectures
  Malformed IPv6 routing headers can cause a kernel panic.


• 007: RELIABILITY FIX: February 22, 2008 All architectures
  Incorrect assumptions in tcp_respond can lead to a kernel panic.

I wonder if arbitrary code execution is possible for these bugs. Those entries reminded me of a 4.0 errata entry:

• 010: SECURITY FIX: March 7, 2007 All architectures
  2nd revision, March 17, 2007
  Incorrect mbuf handling for ICMP6 packets.

Started as a RELIABILITY FIX until Core Security took a jab at it. They provided a POC and forced OpenBSD to revise the errata. It's troubling that a remote crash is not considered a security vulnerability in OpenBSD.

On March 16, 2007 an update was done to the famous one liner that glazed the project's homepage.

Alfredo Ortega of Core Security presented to Defcon 15 the details of the exploitation. Read the paper and the slides. I reckon entry 008 is the third remote vulnerability that Core Security was talking about.

In the presentation you will see they disabled W^X through extension of the kernel CS (Code Segment) selector. This shows the lack of protection done to kernel memory unlike what PaX provides to the Linux kernel. Expected, as PaX predates W^X and is obviously based on it.

Later this year we will possibly see a OpenBSD feature similar to KERNEXEC. Besides the latest PF code I don't see any advantage using OpenBSD anymore. Even NetBSD is catching up and may even be better with its security features.

I bet before the end of the year it will be three remote holes in the default install.

Coredumps

I noticed a design error similar to CVE-2007-6206 in DragonFly BSD. It is reported that OpenBSD and FreeBSD exhibit the same.
   

My suggested patch:

--- kern_sig.c  2008-02-14 13:41:12.000000000 +0800
+++ kern_sig-20080216.c 2008-02-16 01:15:01.000000000 +0800
@@ -2066,6 +2066,12 @@ coredump(struct lwp *lp, int sig)
               goto out1;
       }

+        /* Don't dump to files current user does not own */
+       if (vattr.va_uid != p->p_ucred->cr_uid) {
+               error = EFAULT;
+               goto out1;
+       }
+
       VATTR_NULL(&vattr);
       vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
       vattr.va_size = 0;

A DragonFly BSD developer asked me if they should rather remove the file and recreate a new file which then will be owned by root. In my opinion checking for ownership is better and safer. We are avoiding other possible bugs e.g. allowing to read files you don't own but resides on a directory you own. I also find my fix more compact.

By the way as seen in my patch, we wouldn't want to hard code != 0 because DragonFly may implement a type enforcement system or authorization framework in the near future.