Re: ld.so

[Sabau Daniel <draven () UBBCluj Ro>]

> michael forwarded me your email to vuln-dev.

10x four your mail, i'm try to prevent users from running binaries on my 
system, but binnaries compiled by them on mine or on other systems, i 
found ld.so recently and i was a bitt surprized seeing that user execut 
binaries through ld-linux.so, is just that my company policy doesn't allow 
users to run anything in their home directory:( and i have to force users 
in doing so, since i can't change mod to o= on ld-2.2.4.so nore remount 
the / partition as noexec:) i need another way to eliminate this 

i wasn't useing the ACL, nore TPE till now, i'll recompile my kernel with 
the acl system, 10x four the advice

> I'm not sure if you understand what ld.so is really doing.  I've
> discovered the behavior a long time before you have.  Here's what it
> does:
>
> ld.so mmaps the file you give as its argument into memory with the
> PROT_EXEC bit set.  This allows execution directly off memory.  ls.do
> then "becomes" the executable you give as its argument.  It does not
> call do_execve in the kernel, since it doesn't do any actual executing,
> and that allows it to bypass most things.  There are several ACL systems
> that don't check this...I've discussed the issue on my mailing list. 
> The only ACL systems not vulnerable to this is RSBAC and SELinux.
>
> In grsecurity we've stopped your ability to do that.  If you're using
> TPE or the ACL system, TPE will deny that ld.so attack attempt if you're
> trying to mmap a file for execution that you couldn't exec normally (ie
> it has to be in root owned non-world-writable directories).  For the ACL
> system we enforce this for every proccess acl, so whatever you say can
> be executed is all that can be executed.
>
> The reason why we don't stop it alltogether is because there's nothing
> stopping you from copying the file to a place where you can execute
> programs, and execing it there.  Therefore we only put the restrictions
> when there was some kind of additional restrictions on the user as to
> what they could execute.  Hope this answers your questions.
>
>
> [sharon@grsecurity ~] /lib/ld-2.2.4.so ./sh
> ./sh: error while loading shared libraries: ./sh: failed to map segment
> from shared object: Permission denied
>
> Apr 23 08:09:32 grsecurity kernel: grsec: denied exec of sh by
> (ld-2.2.4.so:13685) UID(527) EUID(527), parent (bash:30685) UID(527)
> EUID(527) reason: tried to mmap binary
>
>
> Feel free to forward this mail onto vuln-dev.
>
> -Brad

-- 


"From all the things I lost, 
My mind, I miss the most!"

echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc