On Sun, 24 May 2015 21:03:38 -0600 Bob Proulx <b...@proulx.com> wrote:
> David Wright wrote:
> > Quoting Petter Adsen:
> > > PS: What _are_ the security implications of having a PATH set to
> > > "/foo/bar:"?
> >...
> > $ cd /home/evilperson/malicious-programs/
> > $ emaca (oops, I mistyped emacs. Funny, why are my files
> > disappearing?) (oh dear, their file "emaca" contains rm -f ~/*)
> >
> > or, if the colon is at the start of PATH:
> >
> > $ date (Funny, why...?)
> > (oh dear, their file "date" is a symlink to emaca)
> >
> > $ ls -1 /home/evilperson/malicious-programs/
> > date
> > emaca
>
> You aren't thinking maliciously enough! :-)
>
<snip>
> And it isn't just other local users. Let's go long. Web sites such
> as Wordpress have a long history of being cracked. In their preferred
> installation mode they want to be able to update themselves. Meaning
> they can write to their own files. Meaning that if they to get
> exploited an attacker can write files to the local file system. This
> is often used for cracking the web site but could also be used for
> leaving files such as a compomised 'ls' around too. Just by itself
> maybe they could only drop some files onto the file system owned by a
> non-priviledged www-data user causing web site defacement. But then
> later if the user or worse root had the current working directory in
> PATH and is tricked into running a compromised ls then the remote
> compromise attack succeeds. With LD_PRELOAD_PATH is almost as good
> and has all of the same dangers. This could potentially through a
> sequence of missteps become a remote root compromise to the system.
OK, this is veering off-topic - apologies in advance. From what I
understand, LD_LIBRARY_PATH contains additional places to look for
libraries that aren't in ld.so.conf.
From ld.so(8):
LD_LIBRARY_PATH
A colon-separated list of directories in which to search for ELF
libraries at execution-time. Similar to the PATH environment
variable. Ignored in set-user-ID and set-group-ID programs.
But what order is this information parsed in? Does LD_LIBRARY_PATH
override ld.so.conf? Ie, could I place a modified version of a library
somewhere, point LD_LIBRARY_PATH at it, and every binary that is linked
toward the original library will run functions from the modified one,
or would I also need to remove the original library, so that only the
modified one is found?
The danger would be much clearer if it overrides, since if it doesn't
you will probably notice that the original library has been disabled.
Am I even on the right track, here?
> Some of us would say it is unlikely to happen to *us* but we might all
> agree that it could happen to someone else. A potential if unlikely
> exploit.
Yes, "it would never happen to me". Dangerous attitude when it comes to
security.
Petter
--
"I'm ionized"
"Are you sure?"
"I'm positive."
pgp4Y9MLfbnnu.pgp
Description: OpenPGP digital signature
