Semi OT But preemptive security related: libsafe

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

Re: Semi OT But preemptive security related: libsafe

Postby Raf256 » Fri Mar 31, 2006 4:06 pm

mikeeusa wrote:It seems that libsafe is currently in an abandoned state.


Yes, libsafe wes terrible broken (in debian testing/stable), after my bugreport it is sheduled for removing totally since its abondoned.
Raf256
 
Posts: 72
Joined: Mon Sep 19, 2005 8:38 pm

Postby PaX Team » Sat Apr 01, 2006 6:22 am

mikeeusa wrote:I am wondering if the PaX team might ressurect it.
i definitely won't as i see no point in using libsafe, other mechanisms (both kernel and userland) provide better coverage.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby PaX Team » Sat Apr 01, 2006 12:50 pm

mikeeusa wrote:What are the other methods? (I'd like to apply them).
Are there other libsafe similars that can be ld_preloaded etc?
look at what hardened gentoo and lately, RHEL/Fedora do: http://hardened.gentoo.org and "Security" under http://people.redhat.com/drepper/
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby JLO » Mon Apr 03, 2006 1:24 pm

Well after reading this, I went and downloaded src and rpm of libsafe (I think I used a RH fed 1 rpm). I extracted the library ONLY (15k !!) and installed it, exported it through bash but forgetting to create the symlink to match the name to the export...quickly found unresolved lib dependency libsafe...alright fixed that and placed in startup (without even testing in shell first..cross fingers). OK, so it's now up and running, been running for days. I've seen nothing in /var/log/secure (all is well). How can I create a buffer overflow to test?

Also , from what I have read, this has minimal impact upon a system, performance or otherwise. It is curious who was/is behind it (Bell labs & Lucent). It is described as a preventative measure against FUTURE vulnerabilities that may yet to be found...and it does seem interesting. Not buggy at all and I'm using it on a scratched together linux from various sources...so it wasn't even made specifically for my system. As far as other "hardened" distros, I have problems trusting the developers of SELINUX...I would like a full and unbiased security audit of the source please!!!! With grsecurity and now libsafe, I just cross my fingers and hope for the best as far as a security audit of source.

Anyway is there something out there that will test libsafe?

EDIT:

ended up checking the source, found the test suite. compiled and moved over to my server. Found that most of the test suite programs were subverted except for 'canary-exploit'...
[quote]
root@Sievette:~ # /var/log/home/tmp/exploits/t1
This program tries to use strcpy() to overflow the buffer.
If you get a /bin/sh prompt, then the exploit has worked.
Press any key to continue...
Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /var/log/home/tmp/exploits/t1.
uid=0 euid=0 pid=14047
Call stack:
Segmentation fault
root@Sievette:~ # /var/log/home/tmp/exploits/t3
This program will exec() a new program. The new program will
overflow the buffer using strcpy().
If you get a /bin/sh prompt, then the exploit has worked.
Press any key to continue...
Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /var/log/home/tmp/exploits/t3.
uid=0 euid=0 pid=12098
Call stack:
Segmentation fault
root@Sievette:~ # /var/log/home/tmp/exploits/t4
This program will fork() child process, and the child
will overflow the buffer using strcpy().
If you get a /bin/sh prompt, then the exploit has worked.
Press any key to continue...
Libsafe version 2.0.16
Detected an attempt to write across stack boundary.
Terminating /var/log/home/tmp/exploits/t4.
uid=0 euid=0 pid=12717
Call stack:
parent process terminating
root@Sievette:~ # /var/log/home/tmp/exploits/canary-exploit
This program tries to use printf("%n") to overwrite the
return address on the stack.
If you get a /bin/sh prompt, then the exploit has worked.
Press any key to continue...
sh-2.05#

Apr 3 16:16:05 Sievette libsafe.so[12717]: Libsafe version 2.0.16
Apr 3 16:16:05 Sievette libsafe.so[12717]: Detected an attempt to write across stack boundary.
Apr 3 16:16:05 Sievette libsafe.so[12717]: Terminating /var/log/home/tmp/exploits/t4.
Apr 3 16:16:05 Sievette libsafe.so[12717]: uid=0 euid=0 pid=12717
Apr 3 16:16:05 Sievette libsafe.so[12717]: Call stack:
[/quote]
I've tried running as non-root.

It might the glibc problem some people have complained about.

[quote]
sh-2.05$ /lib/libc.so.6
GNU C Library stable release version 2.3.3, by Roland McGrath et al.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.3.
Compiled on a Linux 2.4.29 system on 2005-04-01.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
[/quote]

Any suggestions???
JLO
 
Posts: 12
Joined: Wed Aug 18, 2004 10:23 am

Postby JLO » Mon Apr 03, 2006 5:01 pm

JLO
 
Posts: 12
Joined: Wed Aug 18, 2004 10:23 am


Return to grsecurity support