OpenBSD Local Root Hole Patched

unFKNreal writes "A fellow by the name of Georgi Guninski has discovered a local root compromise in OpenBSD 2.8 & 2.9. He says its due to a race in the kernel, similar to the linux kernel race a few months back." The patch is out as of a few hours ago. Even a BSD newbie like me got his firewall patched and rebooted with no problem, after taking a moment to reread the patching instructions and kernel rebuild FAQ. The bad news: the hole was posted to bugtraq Thursday morning, with exploit code, so the black hats had a jump on you (sadly, note the date Guninski says OpenBSD was informed). If your system has any users you don't fully trust, check it over carefully after you patch! Update 3h later by J : Apparently NetBSD is affected too, and a fix is in-tree.

Comments

waiter I have a fly in my soup.

[ThatField]

Seems to me like some people expect perfection from the OpenBSD crew. Yeah, it's a root exploit, but there's certainly far less exploits for major damage on OpenBSD than any or most any other OS's. I don't understand how someone can complain about a patch coming out 6 days after starting work on it. Knowing what I know about the OpenBSD bunch, I wouldn't be surprised if it took 6 days because they wanted to be sure the patch would totally cover the problem without leaving a hole or causing another hole in the system somewhere. I'm still using OpenBSD as a prefered choice OS. Can't knock the soup or the cook, just because one bowl had a fly in it. BSD still rocks, especially when it's open.

<Dev/>

Re:Weren't the audits supposed to take care of thi

[Tiroth]

If you had ever coded even simple reentrant code you would realize how subtle race conditions can be. And look at the conditions required for the exploit to work:

Works best after reboot - the +s program must not be executed before, seems
executes /tmp/sh
/tmp/su must be a link to +s program
if the +s program has been executed, create and run shell script the size of RAM
You may need to type "fg" if the program receives stop signal
you may need to run the program several times

Even allowing for all of this, the exploit doesn't work every time.

The hardest bugs to spot are the ones that happen rarely. Even harder to spot are exploits...because while they are technically bugs, in practice they generally rely on the author to do things that no sane coder would ever try in a "normal" program.