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

[Andrew Parker <andrew.j.c.parker@xxxxxxxxx>]

Hey Daniel

Thanks for the response

The privilege escalation comes after the PATH is changed. The problem
effectively is me, the developer. I run another program which escalates and
inherits the PATH variable. That program then executes commands without
specifying the full path to the binary. Here's an example

Consider Homebrew. The installation script calls sudo. The root shell
inherits my user's env. Brew them executes numerous commands that can be
intercepted. My system is now forever compromised.

It's easy to argue that this is a homebrew issue. However what about the
100s if not 1000s of "reasonable quality" tools that do similar things. As
a modern developer how am I supposed to handle this? Do I have to audit
every tool I use before allowing escalation? That's maybe a reasonable
argument as well, but that's a hell of an overhead. Then what about
upstream dependencies? Just because I audited homebrew today doesn't mean
it'll be good tomorrow. Do we expect every developer to do this? Not
really. Even if I do this, do I expect that I'll remember or get it right
every time? Not really.

So my view is that a defence in depth strategy is the best approach. A
relatively cheap and simple change would, at least as far as I can see,
potentially add a lot of benefit to a lot of people.

Took a quick look at taint btw. Not a perl user. Seems interesting but
seems much broader in scope. Will check more later. AFK at the moment

Andrew

On Sun, 15 Dec 2019, 15:14 Daniel Shahaf, <d.s@xxxxxxxxxxxxxxxxxx> wrote:

> 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.
>