Hi,
Am 15.06.2018 um 00:50 schrieb Alois Mahdal:
On 06/14/2018 11:37 PM, Till Maas wrote:
Hi,
On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote:
On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:
What about attack success rate?
But if the attacker is some browser exploit able to take a shot at many
users (not knowing what their OS, let alone default $PATH is), then I
The browser knows the OS, see the User-Agent header, for example:
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Name
Also the PATH would be in the browser environment, so easy to access,
too. However, if this information is not available to the attacker, why
would they know the value of $HOME/bin or $HOME/.local/bin? They would
have to know the user's username for this. IMHO these are not convincing
assumptions.
Those are not assumptions. It would be incorrect to assume that.
I do not follow here because these assumptions are made by you in your
argumentation as far as I can see.
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.
Most users will use .bashrc and since it would be the file that is under
discussion here, only users that use it would be affected by the change.
Also attackers do not need a fancy algorithm, they can just manipulate
several files instead of doing sophisticated checks.
Even manipulating one, let alone several files, is already more
sophisticated than merely dropping one file.
echo echo pwned >> ~/.i18n does both (appending or creating a file, not
really more sophisticated). And this just works regardless of the PATH
setting.
If I was writing malware, I would be much happier with just being able
to drop a file in ~/bin or ~/.local/bin than doing the research on where
PATH is actually being set, and then getting the `sed` right, and all
that **without** being immediately discovered (eg. because I broke the
syntax or caused error).
If the attacker can already call sed, then they do not need to drop a
binary. Also they do not need to research where PATH is actually set.
My point is that security is not a black & white concept.
It's a float, not a bool. And I'm not arguing about the amount, but
merely against the black & white thinking. With all respect, to me it
sounds kinda like saying "why wash my hands when diseases can spread
through air".
The initial theory in this thread was that it is a significant security
risk. And all the arguments for this are either "it's obvious" or are
based on arbitrarily constructed scenarios. If you are saying it just
makes a minor impact, then we do not need to discuss further because
this is good enough for me.
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/6TITAQ6H2ZN25HXMN5B4NIN7FFIG2TYH/
