lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: cuttergo at (Alexander E. Cuttergo)
Subject: Re: yet another OpenBSD kernel hole ...

On Tue, Nov 18, 2003 at 04:13:24PM -0500, 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 :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

Powered by blists - more mailing lists