[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: where to submit low security vulnerability in .profile?



On Sun, Jun 18, 2017 at 06:56:07AM +0200, David Bunch wrote:
> I'm not sure where or how or even if i should submit a bug small security 
> vulnerability in the default .profile that is created in each users home 
> directory. 

That file comes from /etc/skel/.profile which is in the package...

wooledg:~$ dpkg -S /etc/skel/.profile 
bash: /etc/skel/.profile

... package "bash".

> .profile searches for a ~/bin directory and if it finds it prepends it to
> PATH like so: PATH='$HOME/bin':$PATH

This is not true in stretch:

wooledg:~$ tail -4 /etc/skel/.profile
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

There are double quotes, not single quotes.  The $HOME variable is
correctly expanded.

> A safer configuration would be PATH=$PATH:'$HOME/bin'.

That would be wrong, too.  There must be double quotes, not single quotes.

> This could be a potential security vulnerability because if the user account
> of a uesr with 'su' power, an attacker could place a malicious 'su', 'ls', 
> and 'which' in their ~/bin directory which could give an attacker the root
> password when the user runs the 'su' command.  

You appear to be claiming that putting ~/bin in PATH is somehow inherently
unsafe.  I don't agree.  Under what conditions would this result in any
kind of privilege escalation?

What does "'su' power" mean, anyway?  That the end user has been given
the root password?  If you've given someone the root password, they
already have whatever power they want.

Everyone with any sense puts ~/bin in $PATH.  This is how you as the user
override the stupid crap that your local sysadmin (or your OS vendor)
did, that you don't want, at the external command level.  (Sometimes a
shell function is a better override, but having ~/bin at the start of
PATH gives you both options.)

If you don't like this for some reason, you are free to edit the
/etc/skel/.profile on your computer.  Now you're the local sysadmin
doing stupid crap, and your users can override you by editing their
~/.profile.  Thank goodness the Unix designers put in so many ways for
users to reclaim their power from those who would try to suppress it.


Reply to: