True. Although you can still do a lot of interesting things by unsetting suid bits and loading your own libraries to override specific functions. Sharefuzz (see www.atstake.com) does this for environment variables, which is still quite interesting on, say, Solaris, HP-UX, Irix, Tru64, but not very interesting on Linux or BSD. ;> Even better, you can override, say, xdr_string(), with Sharefuzz, and then just go through a normal transaction (say, just log into CDE and open a few programs so that ttdbserverd gets accessed a bit - but now every time it loads a string variable from the network (through xdr_string()) that string is a long string of %n's. When ttdbserverd crashes, you know you've found something worth really digging into. :> -dave Dom De Vitto wrote: > This was an old flaw, patched linkers ignore LD_* for > setuid exe's... > > You've got the right idea though... > > Dom > > -----Original Message----- > From: Aycan Irican [mailto:aycanat_private] > Sent: 20 October 2001 12:13 > To: pen-testat_private > Cc: vuln-devat_private; muttyat_private; > aydinat_private; evrimat_private > Subject: KEYWORDS: shared objects, dynamic linking, > > *** PGP Signature Status: unknown > *** Signer: Unknown, Key ID = 0x2D002BBF > *** Signed: 20/10/2001 12:13:30 > *** Verified: 20/10/2001 23:00:13 > *** BEGIN PGP VERIFIED MESSAGE *** > > Hi there, > When I'm trying to understand how executables related to shared objects, > some > questions appeared in my mind(trap)... > > I'm giving some examples here from the UNIX side... > 1. > $ uname -a > OpenUNIX feeddead 5 8.0.0 i386 x86at Caldera UNIX_SVR5 > $ ls -al /usr/dt/bin/dtterm > -r-sr-xr-x 1 root bin 60892 Jun 10 05:03 > /usr/dt/bin/dtterm > > here dtterm is suid bit set. To see which shared objects it needs, > > $ ldd /usr/dt/bin/dtterm > /usr/dt/bin/dtterm needs: > libDtTerm.so.1 => /usr/dt/lib/libDtTerm.so.1 > ....... > /usr/lib/libc.so.1 > > it's dynamic section includes this, > Dynamic Section: > NEEDED libDtTerm.so.1 > ...... > RPATH /usr/dt/lib:/usr/lib > ...... > so when it runs, I'm understanding that say "first look /usr/dt/lib for > loading libDtTerm.so.1". > > if it doesn't defined here I think I can overwrite the LD_LIBRARY_PATH > environment so I could make this system to load MY OWN > libDtTerm.so.1magically :) > > but in Linux side say /usr/X11R6/bin/xlock > [aycan@mars doc]$ uname -a > Linux deadbeef 2.4.12 #13D SMP Wed Oct 17 11:54:46 CEST 2001 i586 unknown > [aycan@mars doc]$ ls -al /usr/X11R6/bin/xlock > -r-sr-xr-x 1 root root 1406536 May 3 12:49 /usr/X11R6/bin/xlock > > I couldn't see any path when I looked at objdump output ...so I think I can > export my LD_RUN_PATH variable to inject MY OWN libXpm.so.4 magically :) > > what I'm doing wrong here? > is it possible to inject suspicious shared objects so suid program is > compromised? > any ideas? > > tnx... > -- > Aycan rican > Systems Engineer > Prosoft Communication Systems Ltd. > Resit Galip Cad. 85/2 Gaziosmanpaa 06700 Ankara > Tel:+90-312-446-6616 Fax:+90-312-446-2423 > > *** END PGP VERIFIED MESSAGE *** ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Sun Oct 21 2001 - 01:39:39 PDT