On Mon, 22 Apr 2002, 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: Yes. This is a well known feature, perhaps a problematic one, of most, if not all, interpreters (including sh, perl, python). ld.so, the dynamic linker is a kind of interpreter as well (in fact, the section of an ELF binary where a path of ld.so is stored is known as ".interp"). Is is a real problem? Maybe. But there is a good reasons why any attempt to change this behaviour would be a waste of time: it is lame to base the security of your system on the inability of users to run arbitrary code under their own accounts. There are millions of ways to run less or more arbitrary code (from various features of ld.so, to programs like gdb, to any installed program having a buffer overflow exploitable by the user running it (*)). (*) I mean programs whose vulnerabilities (and features) are "mostly harmless" because the only subject able to exploit the is the subject the run under. But when you separate subjects--users from their programs, you introduce a new security boundary and turn all those things into harmful vulnerabilities. Try reading Schneier & Shostack's "Breaking Up Is Hard to Do: Modeling Security Threats for Smart Cards". > in the same way i've managed to run the ptrace exploit on a nosuid > partition But the question is: were you able to exploit this with a suid binary on a nosuid filesystem? I suspect you were not because suid and sgid bits of a program are not taken into account when the program is started via (explicit) invocation of ld.so. > 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:) Yes, indeed. They cannot run any programs if you make the dynamic linker unavailable. You can try removing the x-bit from it but you might have to modify the kernel (because the standard kernel *might* insist on ld.so being executable). But as I have already said, you would be wasting your time (for instance, you'd have to check your ld.so cannot be tricked to load "non-executable code" with LD_* variable). --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "Resistance is futile. Open your source code and prepare for assimilation."
This archive was generated by hypermail 2b30 : Wed Apr 24 2002 - 14:10:27 PDT