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