On Fri, Jun 15, 2018 at 06:56:16PM +0200, Alois Mahdal wrote: > > > On 06/15/2018 11:24 AM, Till Maas wrote: > > ...] > > > >> What I'm trying to say is that with these kinds of attack (like viruses, > >> or exploits on massively accessed page), there is inevitably going to be > >> some sort of economic decision on side of author affecting how "smart" > >> they want the code to be. > >> > >> Thus, every little step you're making towards "easier" translates to > >> dumber exploits being able to succeed. Suddenly not just those that did > >> 2 things but also those that did 1 thing. > > > > 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. > > The attacker could have looked up the exploit on the web. If it is a public exploit, then it is usually fixed by updates, especially if the impact is that big. A user not installing security updates is a scenario I consider not worth to explore, since there might be all kinds of serious vulnerabilities. > I think you keep putting some kind of base standard on the hypothetical > attacker and then your argument is "if they can do X then they can do > Y". Because we're both SW engineers, the relation between X and Y is > obvious to us, so yeah, anybody who would do X would totally obviously > also do Y. Sure, we've been there so many times we don't even think > about it. This is a useful way to categorize security vulnerabilities because they should allow an attacker to gain more privileges/possibilities/... And if we assume that a system is secure because people do not know about other possibilities, then it is security by obscurity which does not work in practice. > OTOH, I don't think that's the best way to think about security. There > are no standards. The amount of code (dedicated to Linux) could > totally be just that single line, writing the payload to .local/bin. > By including the path in default $PATH, you are allowing also the > on-bit-dumber attack to succeed (... now with all Fedora users, yay!...) Is this realistic? There a endless other possibilities and there is no reason why an attack to access exactly these directory paths is more likely than the many other possibilities. Also why would attackers choose this path in the first place? Putting a new ~/.i18n file in the user's home directory seems to me to be more likely to succeed. > I'm saying there is some impact. I'm not aware of any meaningful way to > measure it, but I don't think it's necessary: IMHO even making a "minor" > impact is already bad idea. I do not agree because the way you argue could be applied to anything and there could always be the one imaginary exploit that will have a payload that will only work because of $whatever and therefore make in impact. For example from the other changes, what if there is a payload that uses a feature of Golang 1.11 or a bug that is fixed in Binutils 2.31. > Especially if I don't really see any convincing reason why this should > be done. I do not see any reason why a user would put something in ~/bin that would mask something in /usr/bin except to actually mask the binary. It is the same with other user configuration, anyone expects ~/.ssh/config to override /etc/ssh/ssh_config instead of the other way round. Kind regards Till _______________________________________________ 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/Q6NQNBDAXGDD5RX2RKX6HRUHJRXU6I4P/
