full-disclosure - Re: yet another OpenBSD kernel hole ...

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.GSO.4.44.0311181813160.2387-100000@sodom.uberhax0r.net>
From: noir at uberhax0r.net (noir@...rhax0r.net)
Subject: 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