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

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



On Sun 18 Jun 2017 at 07:55:32 (-0400), RavenLX wrote:
> On 06/18/2017 12:56 AM, David Bunch wrote:
> >Hi,
> >
> >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.
> >
> >.profile searches for a ~/bin directory and if it finds it prepends it to
> >PATH like so: PATH='$HOME/bin':$PATH
> >
> >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.
> >
> >A safer configuration would be PATH=$PATH:'$HOME/bin'.
> >This way if malicious copies of systems programs were placed in the user's
> >~/bin directory the uncompromised system copies would be still be run.

I agree with Nicolas, even though I use the latter order; not for
security's sake, but just because I don't make a habit of overriding
system commands. My only exception is "cdeject is aliased to `eject'"
for the simple reason that in a recent Debian version, cdeject would
provoke an I/O error and leave the drive's own button inoperable
whereas eject worked fine.

> That's interesting. I didn't know there was a difference but now
> that I look at it, I think you're right. In Jessie, I had to set
> this manually in ~/.bashrc because it didn't work out of the box for
> some reason.

Check if you use ~/.bash_profile or ~/.bash_login, either of which
will prevent ~/.profile from being read.

~/.bashrc ought be written in a way that allows for repeated calls.
A simple PATH='$HOME/bin':$PATH will keep lengthening the PATH.

The INVOCATION paragraphs in man bash make heavy but essential
reading. AFAIK its tautological "reads and executes commands from
~/.bashrc and ~/.bashrc" is just a typo.

Cheers,
David.


Reply to: