Re: /lib/ld-2.2.4.so

["Robert A. Seace" <ras () slartibartfast magrathea com>]

In the profound words of Bill Weiss:
> Olaf Kirch(okir () caldera de)@Tue, Apr 23, 2002 at 09:27:53AM +0200:
> > You can't fix it. You can always do
> >
> >     cp file-with-mode-444-perms ./foobar
> >     chmod +x foobar
> >     ./foobar
>
> Oh?  What about (as the original poster said) if you have user directories
> mounted as noexec?  tmp as well?  Where would you copy the file to so it
> could exec?

        It's silly to think such a system would be secure against
local users running their own arbitrary code...  There are surely
countless ways they could go about it...  Neverminding the likelihood
of exploitable holes in various apps (which normally wouldn't be
considered security-sensitive, and therefore probably aren't given
a lot of attention in that area)...  Or, the ability to create any
scripts they like for any interpreted languages you have installed
on the system (including "/bin/sh", of course)...  (Those need not
be executable to run them...  Just pass the script directly to the
interpreter...)  But, how about creating a shared lib in one of
these writable directories (if you have no compiler, transfer it
from some other system), then LD_PRELOAD'ing it in front of some
innocuous command ("/bin/true" will do fine; just anything that
they are allowed to run), thereby gaining control to execute any
code you like...  I don't think the "noexec" restriction will stop
that...  I just tried, and was able to successfully LD_PRELOAD a
shared lib which had absolutely no execute perms at all...  Read
perms are all that's needed...  So, once you can do that, you can
effectively run any of those wackily 'restricted' commands that you
have read perms to but not execute perms...  (If necessary, you
could just basically write your own "ld.so" clone, to read them into
memory, and execute their contents...)

        It sounds like, to make this wacky scheme work at all, you'd
need to basically eliminate all dynamically linked executables on
the system, and make everything just static...  Then, you might
have a chance...  But, I still wouldn't place much faith in such
a system completely preventing local users from running their own
arbitrary code...

        But, I'm still baffled by what exactly was trying to be
accomplished by taking away users' execute perms, but leaving
their read perms??  Why not take away BOTH, then there's no
problem...  Under what situations would it be useful for users
to be able to READ an executable, but not be able to RUN it??
It just doesn't make a lot of sense to me...

-- 
||========================================================================||
||    Rob Seace    ||               URL              || ras () magrathea com ||
||  AKA: Agrajag   || http://www.magrathea.com/~ras/ || rob () wordstock com ||
||========================================================================||
"And now, at the risk of putting a damper on the wonderful sense of doom
 and futility here this evening, I would like to welcome a few parties"
 - The Restaurant at the End of the Universe