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! :-) Almost everyone would run 'ls' without a second thought. Replace it with a variation that lists all of the files in the current directory except for the trojan ls command itself. Then when the command is running set up the user for setuid access to the system. Using "adduser $USER sudo" for example and then it really all looks very legitimate. However that does point back to the user upon an audit. So perhaps simply copy /bin/bash off to a private location and chown root, chmod u+s to it for later access. Do that "on the sly" with no visible difference from what they expect and the root user who was hit with a social engineering attack would probably not immediately detect it. Replace a normally suid command like umount or another and if the root user isn't running other intrusion detection software they won't notice. Therefore having the current directory in PATH due to an empty ":" either first or last or explicitly with '.' isn't a good idea. It leaves one open to being tricked. 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. 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. Bob
Attachment:
signature.asc
Description: Digital signature