$PATH discrepency when ~/bin exists

Bug #684393 reported by CharlesA
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bash (Debian)
New
Unknown
bash (Ubuntu)
Incomplete
Low
Unassigned

Bug Description

Binary package hint: bash

Hi,

From the thread here: http://ubuntuforums.org/showthread.php?t=1634980

If you have a bin folder in yer home directory, it adds it to the path.

It currently adds ~/bin to the start of $PATH, which has been brought up as a bit of a security issue. It should add that path to the end of the $PATH variable, not the beginning.

See the thread for a fix.

Thanks.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: bash 4.1-2ubuntu3
ProcVersionSignature: Ubuntu 2.6.32-26.48-generic 2.6.32.24+drm33.11
Uname: Linux 2.6.32-26-generic i686
Architecture: i386
Date: Thu Dec 2 11:29:24 2010
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release i386 (20100816.1)
ProcEnviron:
 LANGUAGE=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: bash

Revision history for this message
CharlesA (charlesa) wrote :
Revision history for this message
Ferenc Czumbil (sisco311) wrote :

patch attached

tags: added: patch
Revision history for this message
Philip Muškovac (yofel) wrote :

Thank you for your bug report. This bug has been reported to Debian Maintainers. You can track it and make comments at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606369

Changed in bash (Ubuntu):
importance: Undecided → Low
status: New → Triaged
tags: added: patch-forwarded-debian
Rhonda D'Vine (rhonda)
Changed in bash (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Rhonda D'Vine (rhonda) wrote :

   Hi!

 Actually I fail to see the security impact of this. If a user creates
the bin directory themself and put stuff in there themself then it's on
their own intention, not? I really fail to see the security part of the
issue. Actually it makes sense to have ~/bin first in PATH to be able to
override system tools intentionally.

 I highly doubt that this will be changed on dubious reasoning and
actually wonder why it was forwarded to Debian.

 To be honest, if a malicious person is able to put an ls program into
~/bin of a user they are also able to change their ~/.profile and put
~/bin first in PATH again, so it gets no additional security, at all.

 Thanks,
Rhonda

Revision history for this message
CharlesA (charlesa) wrote :

If someone was able to access the box, create ~/bin and then drop a malicious script in there, then what would stop them from editing files that the user owns? Nothing.

It seems it's something specific to Debian, as a CentOS 5.5 box I have doesn't have anything like that in .bashrc.

I can understand the convenience factor, if you place a different executable there, since it's first in $PATH, but if you are doing that, why not just edit $PATH manually?

Revision history for this message
CharlesA (charlesa) wrote :

Actually, scratch it, on CentOS 5.5, it's in ~/.bash_profile

However, it adds the personal path to the end of the list:

PATH=$PATH:$HOME/bin

Changed in bash (Debian):
status: Unknown → New
Revision history for this message
MestreLion (mestrelion) wrote :

I strongly oppose the bug request, by the same reasons pointed out by Rhonda:

- It does NOT improve security at all, a malicious user could revert the changes or do worse.

- It would prevent intentional overriding of tools.

By the same reason /usr/local/bin comes before /usr/bin, ~/bin should come first.

User tools should override local tools, which in turn override system tools.

Revision history for this message
Stuart MacDonald (smacdonald-miov) wrote :

Putting ~/bin at the end of the path increases security. That is enough to end the argument.

If the user wants to override system tools, then they can just as easily rearrange their path to have ~/bin at the beginning. In fact, that's congruence: a user savvy enough to install their own tools to ~/bin _and_ want them to override system tools is likely savvy enough to edit their path. A user who isn't savvy isn't going to be able to figure out why "cd <anywhere>" always takes them to /you-got-punked.

Default to more security, not less.

The amount of security gained is irrelevant as there is no cost to doing it right.

The fallacy of "I can't imagine a scenario where ~/bin at the start of the path is a bigger security issue than if it's at the end of the path" is the same fallacy as "I can't break this encryption algorithm I wrote, therefore it's unbreakable."

Ubuntu 14.04 is also broken in that, after ~/bin is created, the user has to a) re-source .profile, or b) logout and login. Ubuntu 16.04 has at least fixed that, despite having the same security issue.

Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :

> does NOT improve security at all

Reason why it does : all the other paths in PATH by default are root-writeable only. If a personal ~/bin folder is at the front by default, all it takes is for someone to exploit you is to e.g. get you to unpack an archive in your HOME that has

a) the files you wanted and

also b) a ./bin folder containing a `cd` program, for example

Installing a persistent override of common system commands only requires user-level access with your ~/bin at the front of PATH.

Yes, you still only need user-level access to add a line to someone's bash profiles to add ~/bin (or any other folder) to the start of PATH. But it's one more little thing to overcome. It might be the difference between you getting pwned or not. Adding a line to the bash profile elevates the difficulty from just tricking a user into plonking files on the filesystem to editing them.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.