Sabau Daniel wrote: > lrwxrwxrwx 1 root root 11 Apr 15 12:01 /lib/ld-linux.so.2 > -> ld-2.2.4.so > > This file gives users the ability of running binaries on witch the > user doesn't have the permission to execute, it is enough to have read > ability on the file in order to execute it: > > -rwxr-xr-- 1 root root 45948 Aug 9 2001 /bin/ls > > but using the /lib/ld-2.2.4.so file i can execute the ls command: > Remember, when the binary is +r, you can always copy it anywhere else and chmod it +x. > [08:51:36][draven@Zero:~]:$/lib/ld-2.2.4.so /bin/ls / > bin bzImage bzImage3 bzImage5 dev home lib mnt proc sbin > usr > boot bzImage2 bzImage4 bzImage6 etc initrd misc opt root tmp ... > > The most interesting part is running binaries on partitions mounted with > noexec, lets take this partition: > > /dev/sda9 on /home/friends type ext2 > (rw,noexec,nosuid,nodev,usrquota,grpquota) Same case as above. > > the important thing is to include a full path in the binary name to be > able to execute it. > in the same way i've managed to run the ptrace exploit on a nosuid > partition > i'm running a 2.4.18 kernel with grsecurity-1.9.4 patch on a Red Hat > Linux 7.2 box, but i've succeded running this file on different linux > boxes and i've been succesfull, please if anyone know how to eliminate > this hole in my security give me a replay. If i try to change the mode on > /lib/ls-2.2.4.so to 700, the users will not be able to login on my linux > box, so this is not a solution:) This is not a bug at all. /lib/ld.so is a helper program to load, prepare and run ELF binaries. All it actually needs is the permission to read the binary into memory. If you don't want your users to run certain binaries, make these -r also. Making binaries -x while keeping them +r is pointless. Bye, -- Michal Podsedník podsednikat_private (+420) 0603 105 261
This archive was generated by hypermail 2b30 : Wed Apr 24 2002 - 14:51:35 PDT