Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #182261 > unrolled thread

where to submit low security vulnerability in .profile?

Back to article view | Back to linux.debian.user

Contents

  where to submit low security vulnerability in .profile? David Bunch <depb@posteo.net> - 2017-06-18 07:20 +0200
    Re: where to submit low security vulnerability in .profile? Nicolas George <george@nsup.org> - 2017-06-18 11:10 +0200
      Re: where to submit low security vulnerability in .profile? RavenLX <ravenlx@sitesplace.net> - 2017-06-18 14:00 +0200
    Re: where to submit low security vulnerability in .profile? RavenLX <ravenlx@sitesplace.net> - 2017-06-18 14:00 +0200
      Re: where to submit low security vulnerability in .profile? David Wright <deblis@lionunicorn.co.uk> - 2017-06-18 19:10 +0200
    Re: where to submit low security vulnerability in .profile? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-06-19 14:40 +0200
      Re: where to submit low security vulnerability in .profile? Henrique de Moraes Holschuh <hmh@debian.org> - 2017-06-19 18:00 +0200
        Re: where to submit low security vulnerability in .profile? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-06-19 18:10 +0200
          Re: where to submit low security vulnerability in .profile? Nicolas George <george@nsup.org> - 2017-06-19 19:20 +0200
          Re: where to submit low security vulnerability in .profile? Ansgar Burchardt <"Ansgar Burchardt"@43-1.org> - 2017-06-20 01:40 +0200
        Re: where to submit low security vulnerability in .profile? Nicolas George <george@nsup.org> - 2017-06-19 18:10 +0200
        Re: where to submit low security vulnerability in .profile? The Wanderer <wanderer@fastmail.fm> - 2017-06-19 18:40 +0200
          Re: where to submit low security vulnerability in .profile? Henrique de Moraes Holschuh <hmh@debian.org> - 2017-06-19 20:30 +0200

#182261 — where to submit low security vulnerability in .profile?

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.

Kind regards,
-David Bunch

[toc] | [next] | [standalone]

#182266

[Multipart message — attachments visible in raw view] — view raw

Le decadi 30 prairial, an CCXXV, David Bunch a écrit :
> 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.  

If the attacker is able to write in ~/bin, then they are also able to
write in ~/.profile and add anything they want there. Therefore, the
change you suggest does absolutely nothing for security.

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

If a user installs a program in their home that is already available on
the system, it probably means they want to use their version rather than
the system's. The same goes for programs installed by the admin versus
programs installed by the distribution. Hence, the correct order is
really ~/bin, /usr/local/bin then /usr/bin and not the other way around.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#182280

On 06/18/2017 05:05 AM, Nicolas George wrote:
> Le decadi 30 prairial, an CCXXV, David Bunch a écrit :
>> 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.
> 
> If the attacker is able to write in ~/bin, then they are also able to
> write in ~/.profile and add anything they want there. Therefore, the
> change you suggest does absolutely nothing for security.
> 
>> A safer configuration would be PATH=$PATH:'$HOME/bin'.
> 
> If a user installs a program in their home that is already available on
> the system, it probably means they want to use their version rather than
> the system's. The same goes for programs installed by the admin versus
> programs installed by the distribution. Hence, the correct order is
> really ~/bin, /usr/local/bin then /usr/bin and not the other way around.
> 
> Regards,
> 

I can see David's concern though if one puts their own version of 
something and it's compromised.

But now that you mention it, one should now better than to do that. :)

[toc] | [prev] | [next] | [standalone]

#182278

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.
> 
> Kind regards,
> -David Bunch

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.

Then again, I do not create a directory called ~/bin but instead it's a 
symlink to another subdirectory inside a subdirectory in my $HOME 
because of the way I like to arrange things. That probably was why it 
didn't work for me out of the box in "Jessie"? I'll have to test that in 
Stretch.

[toc] | [prev] | [next] | [standalone]

#182288

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.

[toc] | [prev] | [next] | [standalone]

#182351

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.

[toc] | [prev] | [next] | [standalone]

#182369

On Mon, 19 Jun 2017, Greg Wooledge wrote:
> 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?

The OP was complaining that ~/bin was being *prepended* to PATH, instead
of appended.

When you prepend ~/bin to PATH, it allows one to have a shell script
such as ~/bin/sudo that will be run instead of the system's sudo.  Then,
some use of social engineering might get an admin or some other user to
type in a password to run a command using su or sudo.

That said, no, it is not usually considered a security vulnerability,
because NOT using the full path to run commands such as "su" and "sudo"
in the first place IS considered gross negligence.

So, train your fingers!  There is no "su", it *is* /bin/su.  And there
is no "sudo", it *is* /usr/bin/sudo.  Never trust aliases, PATH, or
anything of the like for this stuff.

Still, IMHO it would be much better if we *appended* ~/bin to PATH,
instead.  I just checked, and "bash" in stretch seems to do the wrong
thing...

> 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.

This is usually coupled to some social engineering to get someone else
that has the password to think (s)he is running the system su/sudo and
type it.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#182370

On Mon, Jun 19, 2017 at 06:00:58PM +0200, Nicolas George wrote:
> Le primidi 1er messidor, an CCXXV, Henrique de Moraes Holschuh a écrit :
> > That said, no, it is not usually considered a security vulnerability,
> > because NOT using the full path to run commands such as "su" and "sudo"
> > in the first place IS considered gross negligence.
> 
> If your account has been compromised so much that an attacker was able
> to add something in ~/bin/, then using the full path of the commands
> does not bring any extra security.

Henrique, I believe, was describing an attack that works like this:

1) Login.
2) PATH=~/bin:$PATH
3) vi ~/bin/su  (insert malicious code); chmod 755 ~/bin/su
4) Call the system administrator, and get him/her to come to your desk.
5) Get the sysadmin to run "su -c something" for you at your desk.
   This runs your password-capturing program, which records the root
   password somewhere you can retrieve it after the sysadmin leaves.

This is not an attack vector I had previously considered, so thanks
to Henrique for pointing it out.  Nevertheless, I don't think this
justifies any requests to change the default PATH in /etc/skel/.profile.
The attack can be carried out as described above regardless of what
Debian does in /etc/skel/.

[toc] | [prev] | [next] | [standalone]

#182374

[Multipart message — attachments visible in raw view] — view raw

Le primidi 1er messidor, an CCXXV, Greg Wooledge a écrit :
> Henrique, I believe, was describing an attack that works like this:
> 
> 2) PATH=~/bin:$PATH
> 3) vi ~/bin/su  (insert malicious code); chmod 755 ~/bin/su
> 4) Call the system administrator, and get him/her to come to your desk.

I do not think so, as the default value set in the distribution has no
relevance for that kind of attack.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#182390

Greg Wooledge writes:
> On Mon, Jun 19, 2017 at 06:00:58PM +0200, Nicolas George wrote:
>> Le primidi 1er messidor, an CCXXV, Henrique de Moraes Holschuh a écrit :
>> > That said, no, it is not usually considered a security vulnerability,
>> > because NOT using the full path to run commands such as "su" and "sudo"
>> > in the first place IS considered gross negligence.
>> 
>> If your account has been compromised so much that an attacker was able
>> to add something in ~/bin/, then using the full path of the commands
>> does not bring any extra security.
>
> Henrique, I believe, was describing an attack that works like this:
>
> 1) Login.
> 2) PATH=~/bin:$PATH
> 3) vi ~/bin/su  (insert malicious code); chmod 755 ~/bin/su
> 4) Call the system administrator, and get him/her to come to your desk.
> 5) Get the sysadmin to run "su -c something" for you at your desk.
>    This runs your password-capturing program, which records the root
>    password somewhere you can retrieve it after the sysadmin leaves.

Typing /bin/su instead doesn't help against this attack, for example zsh
allows:

  $ alias /bin/su="echo Hallo"
  $ /bin/su
  Hallo

Or one could just present something that looks and behaves like the
normal shell except when /bin/su is called.  Or use the DEBUG trap in
bash.  Or...

In short, it is never safe to run `su` and enter a password from an
untrusted account.  And one should regard all accounts one uses `su`
from as equivalent to root (for misuse; the password just helps
against breaking some things by accident).

Ansgar

[toc] | [prev] | [next] | [standalone]

#182371

[Multipart message — attachments visible in raw view] — view raw

Le primidi 1er messidor, an CCXXV, Henrique de Moraes Holschuh a écrit :
> That said, no, it is not usually considered a security vulnerability,
> because NOT using the full path to run commands such as "su" and "sudo"
> in the first place IS considered gross negligence.

If your account has been compromised so much that an attacker was able
to add something in ~/bin/, then using the full path of the commands
does not bring any extra security.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#182372

[Multipart message — attachments visible in raw view] — view raw

On 2017-06-19 at 11:59, Henrique de Moraes Holschuh wrote:

> On Mon, 19 Jun 2017, Greg Wooledge wrote:
> 
>> 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?
> 
> The OP was complaining that ~/bin was being *prepended* to PATH,
> instead of appended.
> 
> When you prepend ~/bin to PATH, it allows one to have a shell script
> such as ~/bin/sudo that will be run instead of the system's sudo.
> Then, some use of social engineering might get an admin or some other
> user to type in a password to run a command using su or sudo.
> 
> That said, no, it is not usually considered a security
> vulnerability, because NOT using the full path to run commands such
> as "su" and "sudo" in the first place IS considered gross
> negligence.
> 
> So, train your fingers!  There is no "su", it *is* /bin/su.  And
> there is no "sudo", it *is* /usr/bin/sudo.  Never trust aliases,
> PATH, or anything of the like for this stuff.

Wouldn't that seem to be an argument against installing the real su,
sudo, and so forth, _anywhere_ in $PATH? If running them in any other
way than with the full explicit path is such bad security practice, then
why do we install them in such a way as to facilitate doing so?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#182381

On Mon, 19 Jun 2017, The Wanderer wrote:
> On 2017-06-19 at 11:59, Henrique de Moraes Holschuh wrote:
> > On Mon, 19 Jun 2017, Greg Wooledge wrote:
> >> 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?
> > 
> > The OP was complaining that ~/bin was being *prepended* to PATH,
> > instead of appended.
> > 
> > When you prepend ~/bin to PATH, it allows one to have a shell script
> > such as ~/bin/sudo that will be run instead of the system's sudo.
> > Then, some use of social engineering might get an admin or some other
> > user to type in a password to run a command using su or sudo.
> > 
> > That said, no, it is not usually considered a security
> > vulnerability, because NOT using the full path to run commands such
> > as "su" and "sudo" in the first place IS considered gross
> > negligence.
> > 
> > So, train your fingers!  There is no "su", it *is* /bin/su.  And
> > there is no "sudo", it *is* /usr/bin/sudo.  Never trust aliases,
> > PATH, or anything of the like for this stuff.
> 
> Wouldn't that seem to be an argument against installing the real su,
> sudo, and so forth, _anywhere_ in $PATH? If running them in any other
> way than with the full explicit path is such bad security practice, then
> why do we install them in such a way as to facilitate doing so?

It would.  I don't know of anyone that does that, though, because it is
too painful to be worth it.

The fact is, if we remove them, we will get a lot of complains, and it
will break someone's scripts for sure (note: if these scripts set PATH
to something trusted, they're *not* unsafe).

Besides, it is valid for anything that will ask for passwords or
sensitive data.

One also has to pay attention to not ever "help the logged-in user"
under a terminal tap, rogue screen/tmux session, "script", etc...

-- 
  Henrique Holschuh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web