1

Scenario:

  • Typical Linux desktop setup: unprivileged user but with sudo capabilities to do basically everything
  • For the sake of argument let's forget about X11 and its way to allow trivial keyloggers, so let's say the distro is using Wayland or whatever
  • Path is defined in bash profile so that ~/bin comes last, so running "firefox" should run the default firefox and not a custom "firefox" installed by the user in their home directory.
  • .bashrc, .profile, .bash_profile, .bash_logout, etc. (all those kinds of files) are only writable by root, so the user needs to use sudo to edit them.

The attacker then gives the user a malicious file, the user runs it without privileges (without sudo), and... what could the attacker achieve? At the moment I can only think of "plain phishing", that is, the malicious code will try to imitate another application, for example telling you a system update is required, and asking for your sudo/root password. But I suspect there are much more possible vectors.

I'm asking this question because I read that preventing the abuse of bashrc and similar config files is useless if the attacker can run arbitrary code on your computer. Yet I can't think of all the things an attacker could do in practice in this situation. I'd like some practical examples.

closed as too broad by forest, Xander, NULLZ, M'vy, Serge Ballesta Jul 2 '18 at 13:25

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    This is way too broad. It seems like it might be simple, but I kind of gave up after 10 different techniques came to mind. What is your threat model?. What do you want to prevent, and from whom? – forest Jun 17 '18 at 11:49
  • What makes you think the targets are only OS things? How about your bank account, SSH keys, etc.etc.? – deviantfan Jun 17 '18 at 13:19
  • I think the question is clear, and vidarlo wrote an example of a valid answer, showing that protecting bashrc and similar files is useless in a scenario when the attacker can run arbitrary code, even though the malicious code is run without privileges. – reed Jun 17 '18 at 13:23
  • @reed - it is a clear question, but there are no simple answers, other than "anything" - which makes it a very broad question, which may get closed for that reason. – Rory Alsop Jun 21 '18 at 8:32
  • @RoryAlsop, it's not really true the attacker can do "anything". They have no privileges to do so. They should first try to get the privileges. How? Apart from an exploit allowing escalation of privileges (and they probably need a zero-day if the system is fully patched), I don't see too many other obvious options. Vidarlo showed me that locking the bashrc file is useless, for example. So yeah, on second thought I might have worded the question a little better or in another way, but asking good questions in this community seems to be pretty hard anyway. – reed Jun 21 '18 at 15:51
4

Path is defined in bash profile so that ~/bin comes last, so running "firefox" should run the default firefox and not a custom "firefox" installed by the user in their home directory.

Variables can be overwritten in runtime. Shortcuts on desktop and in menus can be overwritten. Aliases can be defined. Instruct the desktop environment to start your code every time it starts... As forest writes; there's too many to list them all. Consider your account compromised!

.bashrc, .profile, .bash_profile, .bash_logout, etc. (all those kinds of files) are only writable by root, so the user needs to use sudo to edit them.

Let me show you something:

[/tmp/foo]$ touch bar
[/tmp/foo]$ sudo chown root bar
[/tmp/foo]$ ls -la
total 24
drwxr-xr-x   2 vidarlo users  4096 Jun 17 14:13 .
drwxrwxrwt 131 root    root  20480 Jun 17 14:13 ..
-rw-r--r--   1 root    users     0 Jun 17 14:13 bar
[/tmp/foo]$ chmod 777 bar
chmod: changing permissions of 'bar': Operation not permitted
[/tmp/foo]$ rm bar
rm: remove write-protected regular empty file 'bar'? y
[/tmp/foo]$ 

As long as you have write permission for the directory (which you pretty much need for ~), you can remove files you do not own. An attacker can trivially do cat .bashrc > /tmp/foo && rm -f .bashrc && cat /tmp/foo > .bashrc, effectively recreating the files.

In addition, local privilege escalation attacks on a desktop solution is not exactly unheard of.

  • 1
    Note that making $HOME a sticky directory prevents this. – forest Jun 18 '18 at 0:50
  • 1
    @forest most certainly. But that's an uncommon mode for a home directory afaik. – vidarlo Jun 18 '18 at 20:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.