On Tue, Nov 18, 2003 at 04:13:24PM -0500, [EMAIL PROTECTED] 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
pgp00000.pgp
Description: PGP signature
