Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

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

 



Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
> On Sat, Jun 16, 2018 at 11:38 AM, Björn Persson <Bjorn@rombobjörn.se> wrote:
> > Nico Kadel-Garcia wrote:  
> >> On Fri, Jun 15, 2018 at 12:55 PM, Till Maas <opensource@xxxxxxxxx> wrote:  
> >> > So the assumption is to have a super sophisticated browser exploit for which
> >> > an attacker most likely spent several days to find it and then the PATH
> >> > setting will make it so much harder that the exploit will not succeed? There
> >> > are a lot more real challenges that attackers have to face.  
> >>
> >> No "browser" sophistication is necessary. The replacement of default
> >> system utilities by anyone who write into that private but
> >> semi-concealed $HOME/.local/bin/  
> >
> > And how did the attacker acquire write access to $HOME/.local/bin/ in
> > the first place? Do you know of a way to do that so easily that
> > appending a line to one of the shell startup files seems sophisticated
> > in comparison?
> >
> > I don't much like the proposed change to PATH, but I'm getting *really*
> > sick of all the security by handwaving that's going on in this thread.
> > Could everybody please discuss *relevant* attack scenarios, instead of
> > scenarios that begin with the attacker already having so much access
> > that the value of PATH doesn't matter?
> >
> > Björn Persson  
> 
> There are many vectors for such attacks that a sensible, locked down,
> secure, monitored environment would not experience. Popular
> vulnerabilities include:
> 
> * Stolen passwords from penetrated hosts, used for SSH connections.

So the attacker already has full control of the user account, and can
read, write and execute whatever they want. I'll assume that the
scenario you're imagining is that the attacker tries to acquire further
privileges, as passphrases that aren't stored on disk is the only thing
the attacker doesn't already have.

Passphrases can be sniffed out in various ways, for example with a
wrapper program around su, or by attaching a debugger to a running
process, but all the methods I can think of are much more sophisticated
than appending a line to one of the shell startup files.

> Copying a file to $HOME/.local/bin requires far less scripting and
> awareness of existing contents than editing of .bashrc or .profile
> that reveals timestamp changes of the edited file,

cat .bashrc malicious >.bashrc.pwned
touch --reference .bashrc .bashrc.pwned
mv .bashrc.pwned .bashrc

Voila! Edited file with no awareness of existing contents and no
timestamp change. That is admittedly a little more scripting than
"scp malicious victim@target:.local/bin/su", but the actual malicious
program will be much longer in either case, so I don't see how that's a
significant hurdle.

> and differs from system defaults.

Hold on a second! Are you now imagining some kind of locked-down
environment where shell startup files are regularly compared to the
system defaults and an alarm is raised if they differ? If users aren't
allowed to edit their own startup files, then wouldn't those files be
root-owned and read-only?

> Since the contents of $HOME/.local/bin are not
> defined or definable, by its very nature, it's harder to audit.

So users in this hypothetical environment aren't allowed to edit their
own startup files, but are allowed to install programs in their home
directory. Is that right?

> * Fileshares of home directories. Many environments, especially
> university environments, use NFSv3 with quite general access. Welcome
> to write access to $HOME/ !!!

Well if they have made a decision to allow any user to write in any
other user's home directory, then they're obviously not worried about
users attacking each other. I would consider that unwise, but in that
context I don't see why they would care about security aspects of the
default PATH.

> And $HOME/.local/bin is notably less
> apparent than $HOME/bin, due to the default lack of "ls" reporting of
> contents of "." prefaced directories,

As .local and .bashrc are both hidden I see no difference in that
aspect.

> and of the difficulty of leaving
> security auditing to check .bashrc, .profile, etc.

If those files are difficult to audit, then they would seem like good
places to hide malicious code, and that code would be independent of
the default PATH.

Björn Persson

Attachment: pgppIK7y6ijEP.pgp
Description: OpenPGP digital signatur

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/44JHJ5BA2N3L6NWS7I56PMZE32TK7ZVJ/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux