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]
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



Powered by blists - more mailing lists