On 18 June 2018 at 11:27, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote: >> On 16 June 2018 at 13:50, Björn Persson <Bjorn@rombobjörn.se> wrote: >> > Tomasz Kłoczko wrote: >> >> On Fri, 15 Jun 2018 at 23:21, Björn Persson <Bjorn@rombobjörn.se> wrote: >> >> [..] >> >> > Don't forget that if your proof of concept can be modified to either >> >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate. >> >> >> >> before ~/.bashrc is executed many other scripts executions >> >> already is finished >> > >> > This is true and completely irrelevant. >> > >> >> Whatever you want to do over you account session or profile scripts it >> >> is already _to late_. >> >> Is that clear now? >> > >> > No it's not clear. I have no idea why you're rambling about the order >> > in which Bash executes its startup files. The order doesn't matter, >> > especially since the hypothetical attacker is supposedly unable to >> > modify those files. >> > >> > You claimed to have a proof of concept that would demonstrate how some >> > security hole can be exploited if and only if ~/.local/bin is listed >> > before /usr/bin in PATH. I asked you to post your proof of concept. You >> > didn't. I will therefore conclude that you don't actually have one. >> > >> >> >> Well, two things: >> >> 1. For example, a kiosk mode, where the home directory is wiped each >> login would be made less secure. The profile for the GUI is set at >> login, so writing .bash_profile has no effect on the GUI environment, >> but an attacker able to place files where the user has write >> permission could mask system binaries. > > Even if .bash_profile is not always read, .bashrc is read every time > a shell is started (OK, not "every time", but often enough). So for > example if I open a new tab in the terminal, or run some scripting plugin > from an editor, etc, the effect is the same as overwriting .bash_profile. > But these assume you are only attacking the shell. The system path is used to resolve commands started from the gui too, independent of bash. > But more generally, if one uses a public kiosk that somebody else had > logged into first, for *any* purpose requiring security, that is a > grave mistake already. How would one even know that the gui they are > accessing hasn't been substituted wholesale? > This is a misdirection. We can still worry about an attack on a user logging into a clean profile (the case I was discussing), or from the point of view of the kiosk administrator concerned with ensuring the security of their users, the system itself and the network it's attached to. To put it another way, you probably use a proprietary CPU in your computer, how do you know it's not compromised? Why do we worry at all about security if you can't guarantee that? >> But a more major worry for me here, the reason I'm bothering to reply >> to a thread about setting paths (though to be honest, someone who >> doesn't understand how to do that may not have much business >> installing unpackaged software, particularly when the examples are >> developer tools): >> >> 2. The fact that a proof of concept cannot be provided is not a proof >> that a change you make is secure. Take Spectre; that vulnerability has >> been around for decades with no public proof of concept, or even >> knowledge there was a vulnerability, yet it can be exploited from >> Javascript in a browser. So this repeated insistence on providing a >> proof of concept before a security concern is taken seriously is >> fundamentally wrong, and I would be concerned to see it applied >> elsewhere in Fedora. > > In this case we understand what the change in behaviour means, we just > seem to disagree on how significant this is. We even know how any such > exploit would look. The calls to provide a POC have the intent to take > any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead, > and thus turn the discussion around by showing that $PATH order is > irrelevant to the attack. > Fundamentally flawed approach, since you are assuming you know the constraints an attacker is working under, here you assume that they are able to freely write to all locations the user can access. This may not always be the case. An attacker's first job is to leverage a weakness to gain that control. As I mentioned what worries me most is this attitude that you must be smarter than the attacker and that you do not need to think defensively because of that. -- imalone http://ibmalone.blogspot.co.uk _______________________________________________ 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/OKVKAN4NTSNP5WAWGFSEFLUWUABDU47H/
