Re: yet another OpenBSD kernel hole ...

["Alexander E. Cuttergo" <cuttergo () gmx net>]

On Tue, Nov 18, 2003 at 04:13:24PM -0500, noir () uberhax0r net wrote:
> > Your code does:
> > if((fd = open("./ibcs2own", O_CREAT^O_RDWR, 0755)) < 0) {
> > How on earth is this going to work against privilege separation ? In each
> > sane setup, a server process is chrooted to a directory with no writable
> > directories.
>
> do you have any idea how many of those chrooted processes have temporary
> directories in their chroot environment ? many of the so called priv
> seperated processes use temoprary files thus having writeable directories
> in there chroot jail. 
I can think of only one - named, it has a writable /var/named/slave, and it
is an exception. Anyway, this is a reminder to mount /var partition 
as noexec,nosuid.
Of course, there are other useful things you can do in a chroot jail, and 
there are methods to prevent you from doing them, but let's not beat this 
dead cow once again.
BTW, what is /var/empty/dev/log left for (on obsd 3.4) ? Syslogd should not 
need it. Irrelevant in this case.

> you might have heard the concept called system
> call/API proxying, you can upload the ibcs2own binary and simulate this
> exploit as if you run it from a shell, not rocket since simple and
> straight forward ...
What does syscall forwarding add to the discussion ? It is only a tool. If 
you can create a binary and execute it, you can exploit this bug with or 
without syscall forwarding. 
Not to mention that Impurity is a superior tool on Unices.

> > Being not a diehard obsd fan, I must notice that 3.4 kernel is built with
> > stack smashing protection, which reduces this hole to pure local DoS only. Can
> > you name any other OS which has any prevention against kernel buffer overflow ?
>
> i can name OSes which do not have these kind of hopeless, amateur bugs.
> just a reminder that propolice protects against stack smashing not heap
> smashing so it would be a joke to claim "prevention against kernel buffer
> overflow" because it simply DO NOT. there are tons of kmem alloctor
> overflows in OpenBSD, go figure ;-) ...
Right, I should have put it "against stack kernel overflows" (BTW I did not
say "all kernel buffer overflows"). Anyway, I wonder if you have any technique 
to genericly exploit heap overflow in kernel land; you have promised in p60-6 
to post one :)

peace,
algo

Attachment: _bin
Description: