[Full-Disclosure] Re: yet another OpenBSD kernel hole ...
On Mon, Nov 17, 2003 at 20:23:12 -0500 (EST), [EMAIL PROTECTED] wrote:
noir attached exploit will get you uid=0 and break any possible chroot jail
noir your parent process might be in, works on all 2.x and 3.x upto 3.3.
noir
noir priv seperation, chroot jail, systrace yeah yeah right ;P theo and niels
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.
noir so i hope, some of you openbsd loving losers will finally get the truth
noir behind your cult. it is a big LIE, aloha
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 ?
Yes, this bug is hopeless, but stay objective.
peace,
algo
pgp0.pgp
Description: PGP signature
Re: [Full-Disclosure] Re: yet another OpenBSD kernel hole ...
Hi! noir so i hope, some of you openbsd loving losers will finally get the truth noir behind your cult. it is a big LIE, aloha 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. _IF_ the stack smashing protection works it will reduce this bug into a pure local DoS yes. I have seen no proof so far that the SSP stack smashing protection is 100% effective against all types of overflows. Can you name any other OS which has any prevention against kernel buffer overflow ? The Adamantix kernels are compiled with SSP (aka propolice), which is the same thing used to compile the OpenBSD kernel. It protects against some, but not all, overflows. Groetjes, Peter Busser -- The Adamantix Project Taking high-security Linux out of the labs, and into the real world http://www.adamantix.org/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: yet another OpenBSD kernel hole ...
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. 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 ...
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 ;-) ...
regards,
- noir
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: yet another OpenBSD kernel hole ...
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
pgp0.pgp
Description: PGP signature
Re: [Full-Disclosure] Re: yet another OpenBSD kernel hole ...
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. there is anonymous ftp and sftp assuming incoming/ directories. how about sendmail ? and many similar MTAs. Also bugs like select() does not require any writable directory so wrapping the select-alike exploits with MOSDEF or your Impurity will break chroot, get root and spanwn a shell if you like ... ; 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. yep, there are other public and unpublic techniques to break chroot other than kernel overflows. once you gain execution, chroot slightly raises the bar but does not prevent successful exploitation. 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. syscall forwarding makes life simpler in uploading/downloading and executing remote binaries, nothing more. there are definetely better solutions like MOSDEF and Impurity which allow you to do even more complex stuff in a remote exploitation context, such as kernel exploits ... 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 :) as i claimed in p60-6 and recently in bugtraq ( http://www.securityfocus.com/archive/1/344889/2003-11-15/2003-11-21/0 ), yes i got working technique ;) later, - noir ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
