Re: /lib/ld-2.2.4.so

[Pavel Kankovsky <peak () argo troja mff cuni cz>]

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."