On 06/16/2018 01:17 PM, Nico Kadel-Garcia 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. > 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!!!" I know there was a statement against "if they can do X then they can do Y" statements previously. However: I don't think that prioritizing user-controlled path directories is giving a hypothetical attacker an advantage since they can even re-implement this with the equivalent of: echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc I think it is appropriate to say that this is no more inappropriate than user-controlled files (like .bashrc or .profile) being executed during session startup or shell startup in the first place. _______________________________________________ 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/PW5EW7SRZ4CNH442LRMDC52YEF46U5ET/
