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/
