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. 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, and differs from system defaults. Since the contents of $HOME/.local/bin are not defined or definable, by its very nature, it's harder to audit. * Fileshares of home directories. Many environments, especially university environments, use NFSv3 with quite general access. Welcome to write access to $HOME/ !!! And $HOME/.local/bin is notably less apparent than $HOME/bin, due to the default lack of "ls" reporting of contents of "." prefaced directories, and of the difficulty of leaving security auditing to check .bashrc, .profile, etc. Does that give you enough examples of unnecessarily vulnerable vectors opened by default by the casual assumption that "ohh, they could get in another way, so I don't have to worry about the hole *I* am suggesting opening up!!!" _______________________________________________ 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/HQZTAIOMT5Z357HV2EHRNIN7G7YT6TTQ/
