Re: Security problem in bashrc and possible fix

[Bob Proulx]

Noam Samuel wrote:
> First of all, I am aware that this bug has been posted before, but I think
> that I have an idea for a possible simple-to-implement fix for this problem
> and similar problems that may arise.

Unfortunately the topic you are bringing up is not really a bug.  You
are talking about basic security paradigms of unix-like systems.
Here on bug-bash is not the right forum for this type of general
operating system design type of discussion.

Really for what you are discussion the SElinux lists would be better
suited.  The types of exploits you are trying to avoid are quite much
more up their topic area.

> The problem is the fact that software run under regular user permissions can
> gain root access by adding an alias of some sort for a commend requiring
> root password or any other password allowing root access (such as su, sudo,
> gksu, gksudo, ksu, ksudo, etc.) to .bashrc or .bash_profile.

Usually the attack vector is through social engineering attacks.
Phishing and other things.  This is nothing new.

> for example, let's say that malscript.sh contains the folowing command: echo
> 'alias "su=su -c \"rm -rf /\"' > ~/.bashrc . the next time the user would su
> to root, his or her whole filesystem would be ereased! Of course, there are
> probably more sophisicated ways to do that.

You would need to trick the non-root user into running your trojan'd
command.  If you try to trick many people certainly some will fall
prey to the attack.  But you will find it difficult to exploit this on
every person.  Most actually are smart enough to avoid these attacks.
And trying to exploit this on demand to any one individual is
particularly hard.

> What I think might help is by adding a new config file, /etc/bash_finalrc ,
> which will be executed after .bashrc or .bash_profile are. by default, the
> file should contain something like this:
> 
> alias su=/bin/su
> alias sudo=/bin/sudo
> 
> (of course, this can  be customized by distro vendors), thus countering any
> possible aliasing/user-rootkiting of the commands.

This is not practical.  You are trying to enumerate all possible
evils.  That set is too large.  It is infeasible to enumerate a
complete list of possible attacks.

Again, the bug-bash mailing list is not a good forum for this type of
discussion.  Unless you have a specific bug related to bash itself or
other discussion related to it then I suggest a different place of
discussion.  Nothing you have suggested would be any different for
ash, zsh, ksh, csh, tcsh, or any of the other shells.

Bob