2
2

So I read in a Linux book that the reason the current directory, aka ".", is not in PATH is because it is insecure to do so. How? What vulnerability does this create?

asked 01 Jul '10, 06:49

Joehillen's gravatar image

Joehillen
1462512
accept rate: 40%




Yes, it is definitely insecure.

If you create a directory with the following contents, it is a security flaw:

# cd evildirectory
# ls
cd

cd is a executeable file with the following content:

#!/bin/bash
rm -rf /

If your PATH variable contains . in the first position and you want to leave the directory via cd .., not /bin/cd will be executed, but evildirectory/cd and you can imagine, what will happen.

So don't put the dot in your PATH.

link

answered 01 Jul '10, 08:28

guerda's gravatar image

guerda
5533515
accept rate: 38%

So why shouldn't we put . at the end of our PATH? That way /bin/cd will be seen first and run instead of ./cd

(01 Jul '10, 11:23) Kevin M

Putting . at the end should not cause problem. But you propably get no message "Command atp-get not found, try apt-get". If a evil directory contains a program you don't have installed, it can harm you PC. So if you don't have got apt-get installed, an evil ./apt-get file is dangerous.

(01 Jul '10, 12:40) guerda

If you are working just as a user, this is not very important. The old "rm -rf /" won't work. It is a huge vuknerability if you are running as root.

Generally, root should never ever have . in the PATH, but users don't have to be so paranoid.

(01 Jul '10, 22:30) codebunny

For sure it's not that harmful as normal user. But it doesn't cost you massive work to say "./mysimpleprogram". And you are sure you are executing the file in the current directory.

(02 Jul '10, 05:41) guerda
1

Plus "rm -rf /" is not the only command that I most definitely do not want to run. How about "rm -rf ~"? If you have recent backups, then it's a significant inconvenience. If you don't have recent backups then it's more than a significant inconvenience.

(02 Jul '10, 12:14) Kevin M
1

While it may not seem that users need to be as paranoid, they in fact do.

You don't have to compromise the most effective security practices, only the weakest of them to get into the box. There are plenty of local vulnerabilities that go ignored because an admin doesn't think it's a risk since only it's accessible to local users. All it takes is one of the users compromised and you have an issue.

Best practices are not just for root.

(13 Jul '10, 19:07) rfelsburg ♦
showing 5 of 6 show 1 more comments

The risk is not worth the reward. In a properly configured Linux environment, all executables should be in a few standard directories. This is part of the FSSTD and is generally considered a good practice as all files with the same function are in the same place.

Unlike the directory structure of Windows, executing a command in a local directory is more of the exception than the rule. Mostly, it will be to run ./configure or something similar. Since doing otherwise is so rare, it causes you to have to stop for a moment and think before doing something stupid.

As for security, you can imagine all the things that could go wrong if any file could be executed at random. Unlike Windows, Linux does not require a special filename extension (.exe, .com, .bat) to be executable. I know that some fs types, such as NTFS, that don't have Linux permissions can be granted all permissions by default. This includes the execute permission. That means that you could wonder into a directory and accidentally execute a file at random by using tab-complete. Mostly, this would just issue a lot of "command not found", but if just the right phrase appeared, you might have trouble. This is just one example that doesn't even require ill intentions. I'll let your imagination figure out some more.

link

answered 02 Jul '10, 05:08

kainosnous's gravatar image

kainosnous
3243
accept rate: 18%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×15
×3

Asked: 01 Jul '10, 06:49

Seen: 1,622 times

Last updated: 02 Jul '10, 05:08

powered by OSQA