Re: Thoughts on protecting against PATH interception via user owned profiles

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Andrew Parker wrote on Sun, Dec 15, 2019 at 14:27:45 +0800:
> I'm curious to hear the community's thoughts on the threat of PATH
> interception in shells. Specifically, it's very easy for a malicious
> process, running as regularly user, to interfere with your profiles and
> there's no fool-proof way to protect against this. For example, a malicious
> binary can easily change a profile to insert something into your PATH. Once
> that's done a privilege escalation is extremely feasible due to the vast
> number of tools that rely on your path and which don't specify full paths
> to binaries they in turn shell out to.

So you're saying is that an attacker that can run arbitrary code as your user
*now* can use this to modify script files (such as ~/.zshenv) to be able to run
arbitrary code as you *later*.

First of all, this is not what's normally meant by a "privilege escalation"
attack.  That generally means "Alice can run code as Bob".

As to your attacker, you could uninstall zsh entirely and he'd still have any
number of ways to run code as you — for example, by editing
~/.config/autostart/, or ~/.xinitrc, or ~/.vimrc, or ~/.gitconfig¹, etc., or by
running crontab(1) or at(1).

The short answer here is that untrusted applications should not be given write
access to files that will be executed by trusted programs.  Traditionally,
untrusted applications would be run under a dedicated unprivileged uid, and
their output sanitized if needed.  Nowadays there are tools such as Qubes
(q.v.).

> My question is whether zsh (and other shells) would ever be interested in
> implementing a solution to this. My suggestion would be something like the
> following (although there may be better alternatives):
> 
> * zsh uses a config file in e.g. /etc directory which much be owned and
> only writable by root
> * The config can be used enable "protected profiles"
> * Once protected profiles are enabled, only profiles which are owned and
> only writable by root can be sourced on startup
> 

I think you've basically reinvented Perl's taint mode ("perl -T").

Anyway, even if you wanted to implement a taint mode in zsh, treating dotfiles
as tainted is simply not enough.  There's any number of ways to mount
a "delayed code execution" attack _against zsh_ without editing the dotfiles.

Cheers,

Daniel

¹ «git <TAB><Esc>which __git_config_option-or-value | egrep -c '_absolute_command_names|_cmdstring'»
  prints 33.