zsh-users
 help / color / mirror / code / Atom feed
* Thoughts on protecting against PATH interception via user owned profiles
@ 2019-12-15  6:27 Andrew Parker
  2019-12-15  7:14 ` Daniel Shahaf
  2019-12-15  8:41 ` Roman Perepelitsa
  0 siblings, 2 replies; 14+ messages in thread
From: Andrew Parker @ 2019-12-15  6:27 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

Hey guys,

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.

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

N.B. I'm only proposing this config to allow backwards compatibility for
users who don't want this or might face unexpected issues.

I've written some gory details here in this article:
http://modelephant.net/?p=95. Sorry for the self-promotion, that's actually
not my intent. However, I can't really write things down any clearer than I
have done there.

Thoughts welcome on this, in particular

* Did I miss a trick with my analysis?
* Is zsh somehow already protected (I've only really stared hard at bash)
* Is anyone else worried about this sort of threat?
* Does anyone care? :)

Andrew

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  6:27 Thoughts on protecting against PATH interception via user owned profiles Andrew Parker
@ 2019-12-15  7:14 ` Daniel Shahaf
  2019-12-15  7:57   ` Andrew Parker
  2019-12-15  8:41 ` Roman Perepelitsa
  1 sibling, 1 reply; 14+ messages in thread
From: Daniel Shahaf @ 2019-12-15  7:14 UTC (permalink / raw)
  To: Andrew Parker; +Cc: zsh-users

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  7:14 ` Daniel Shahaf
@ 2019-12-15  7:57   ` Andrew Parker
  2019-12-15  8:49     ` Daniel Shahaf
                       ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Andrew Parker @ 2019-12-15  7:57 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-users

[-- Attachment #1: Type: text/plain, Size: 4181 bytes --]

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@daniel.shahaf.name> 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.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  6:27 Thoughts on protecting against PATH interception via user owned profiles Andrew Parker
  2019-12-15  7:14 ` Daniel Shahaf
@ 2019-12-15  8:41 ` Roman Perepelitsa
  2019-12-15  8:49   ` Andrew Parker
                     ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: Roman Perepelitsa @ 2019-12-15  8:41 UTC (permalink / raw)
  To: Andrew Parker; +Cc: Zsh Users

On Sun, Dec 15, 2019 at 7:29 AM Andrew Parker
<andrew.j.c.parker@gmail.com> wrote:
> 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

You can do this by creating /etc/zshenv (owned by root) with the
following content (untested):

  [[ -o no_rcs ]] && return

  () {
    emulate -L zsh -o extended_glob
    local file files=(zshenv)
    [[ -o login       ]] && files+=(zprofile zlogin zlogout)
    [[ -o interactive ]] && files+=(zshrc)
    for file in ${ZDOTDIR:-~}/.$^files; do
      [[ ! -f $file || -n $file(#qNu0g0^W) ]] && continue
      # Either not owned by root:root or world writable.
      echo -E - "skipping zsh user rcs because ${(q)file} is tainted" >&2
      setopt no_rcs
      return 1  # alternatively: exit 1
    done
  }

This checks whether any of the user rc files are tainted (either not
owned by root:root or world-writable) and unsets rc option if so. This
will prevent zsh from sourcing rc files from the user's home
directory. You can take some other action there if you like, such as
exiting the shell.

Roman.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  8:41 ` Roman Perepelitsa
@ 2019-12-15  8:49   ` Andrew Parker
  2019-12-15 14:31   ` Andrew Parker
  2019-12-16  4:10   ` Daniel Shahaf
  2 siblings, 0 replies; 14+ messages in thread
From: Andrew Parker @ 2019-12-15  8:49 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

Oh, amazing - zsh is one step ahead of me!

This is the final nudge I need to make zsh my default shell on macOS (there
were some compatibility issues I'd been too lazy to fix until now). Looks
like this will keep at least me happy. Not sure how much the rest of the
world cares about this, but both myself and my team have been putting a lot
of effort into make sure we can't accidentally ship malware to our
customers, hence the forensic look into issues ("can't" == low probability).

There's still an issue to fix with Terminal(s) as a regular user can easily
change the shell binary used by the terminal. I also think Homebrew may
still have some issues as well (will dig in more). However, these are for
another forum :)

Thanks
Andrew

On Sun, Dec 15, 2019 at 4:41 PM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:

> On Sun, Dec 15, 2019 at 7:29 AM Andrew Parker
> <andrew.j.c.parker@gmail.com> wrote:
> > 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
>
> You can do this by creating /etc/zshenv (owned by root) with the
> following content (untested):
>
>   [[ -o no_rcs ]] && return
>
>   () {
>     emulate -L zsh -o extended_glob
>     local file files=(zshenv)
>     [[ -o login       ]] && files+=(zprofile zlogin zlogout)
>     [[ -o interactive ]] && files+=(zshrc)
>     for file in ${ZDOTDIR:-~}/.$^files; do
>       [[ ! -f $file || -n $file(#qNu0g0^W) ]] && continue
>       # Either not owned by root:root or world writable.
>       echo -E - "skipping zsh user rcs because ${(q)file} is tainted" >&2
>       setopt no_rcs
>       return 1  # alternatively: exit 1
>     done
>   }
>
> This checks whether any of the user rc files are tainted (either not
> owned by root:root or world-writable) and unsets rc option if so. This
> will prevent zsh from sourcing rc files from the user's home
> directory. You can take some other action there if you like, such as
> exiting the shell.
>
> Roman.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  7:57   ` Andrew Parker
@ 2019-12-15  8:49     ` Daniel Shahaf
  2019-12-15 17:42     ` Lewis Butler
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 14+ messages in thread
From: Daniel Shahaf @ 2019-12-15  8:49 UTC (permalink / raw)
  To: Andrew Parker; +Cc: zsh-users

Andrew Parker wrote on Sun, 15 Dec 2019 07:57 +00:00:
> Consider Homebrew. The installation script calls sudo. The root shell 
> inherits my user's env.

There's your problem.  Don't run commands as root with the user's
environment, or with input from user-owned files, without auditing
them first.  (There's a trade-off between security and convenience.)

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

Again, an attacker with the assumed capabilities has so many ways
compromise your setup besides editing your dotfiles that protecting just
them would be completely pointless.

Your larger error here is that you're employing a blacklist approach
rather than a whitelist approach: you found an attack so you're trying
to block it.  This approach doesn't scale because there's always the
possibility of an attack you haven't thought of.  The right approach is
not to prove that specific attacks can't be mounted, but to prove that
*no* outcome can be achieved that isn't permitted.

In any case, we're getting _way_ off topic here.  This list is for
discussing zsh development.  If you'd like to propose implementing
a taint mode in zsh, that would be on topic — but as I said, it would have
to be a _lot_ more comprehensive than just calling fstatat(2) on
dotfiles.  Discussing security in general, however, is better done
elsewhere.

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  8:41 ` Roman Perepelitsa
  2019-12-15  8:49   ` Andrew Parker
@ 2019-12-15 14:31   ` Andrew Parker
  2019-12-15 14:43     ` Roman Perepelitsa
  2019-12-16  4:10   ` Daniel Shahaf
  2 siblings, 1 reply; 14+ messages in thread
From: Andrew Parker @ 2019-12-15 14:31 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

Oh man. Back at keyboard now. I see this is nothing zsh specific. The
solution was right in front of me all the time. Just exit 1 from
/etc/profile will work in bash. guess my brain was thinking about subshells
rather than sourcing :facepalm:

Good to rubber duck sometimes. I could have solved my problems all along :)

Thanks

On Sun, Dec 15, 2019 at 4:41 PM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:

> On Sun, Dec 15, 2019 at 7:29 AM Andrew Parker
> <andrew.j.c.parker@gmail.com> wrote:
> > 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
>
> You can do this by creating /etc/zshenv (owned by root) with the
> following content (untested):
>
>   [[ -o no_rcs ]] && return
>
>   () {
>     emulate -L zsh -o extended_glob
>     local file files=(zshenv)
>     [[ -o login       ]] && files+=(zprofile zlogin zlogout)
>     [[ -o interactive ]] && files+=(zshrc)
>     for file in ${ZDOTDIR:-~}/.$^files; do
>       [[ ! -f $file || -n $file(#qNu0g0^W) ]] && continue
>       # Either not owned by root:root or world writable.
>       echo -E - "skipping zsh user rcs because ${(q)file} is tainted" >&2
>       setopt no_rcs
>       return 1  # alternatively: exit 1
>     done
>   }
>
> This checks whether any of the user rc files are tainted (either not
> owned by root:root or world-writable) and unsets rc option if so. This
> will prevent zsh from sourcing rc files from the user's home
> directory. You can take some other action there if you like, such as
> exiting the shell.
>
> Roman.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15 14:31   ` Andrew Parker
@ 2019-12-15 14:43     ` Roman Perepelitsa
  2019-12-17 13:35       ` Andrew Parker
  0 siblings, 1 reply; 14+ messages in thread
From: Roman Perepelitsa @ 2019-12-15 14:43 UTC (permalink / raw)
  To: Andrew Parker; +Cc: Zsh Users

On Sun, Dec 15, 2019 at 3:31 PM Andrew Parker
<andrew.j.c.parker@gmail.com> wrote:
>
> Oh man. Back at keyboard now. I see this is nothing zsh specific. The solution was right in front of me all the time. Just exit 1 from /etc/profile will work in bash.

Note that /etc/profile is sourced by bash only when starting a login
shell. It's not sourced when connecting over SSH, when running
non-interactively or when starting an interactive shell without
`--login`. Many (most? all?) graphical terminals start non-interactive
shell when opening a new tab.

All zsh processes start by sourcing /etc/zshenv (the actual location
is hard-coded in the binary and can be overridden when building zsh)
but there is no equivalent file for bash.

I don't know if this makes any difference to your defense strategy but
thought it might be worth mentioning.

Roman.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  7:57   ` Andrew Parker
  2019-12-15  8:49     ` Daniel Shahaf
@ 2019-12-15 17:42     ` Lewis Butler
  2019-12-15 18:57     ` Grant Taylor
  2019-12-15 19:47     ` Bart Schaefer
  3 siblings, 0 replies; 14+ messages in thread
From: Lewis Butler @ 2019-12-15 17:42 UTC (permalink / raw)
  To: Zsh Users

On 15 Dec 2019, at 00:57, Andrew Parker <andrew.j.c.parker@gmail.com> wrote:
> 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.

You should le the folks at Brew know about this.

On my system brew does NOT invoked sudo unless I have to install something like bind, and when it does it does not inherit my environment.



-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but what kind of rides do they have in
	Fabioland?”


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  7:57   ` Andrew Parker
  2019-12-15  8:49     ` Daniel Shahaf
  2019-12-15 17:42     ` Lewis Butler
@ 2019-12-15 18:57     ` Grant Taylor
  2019-12-15 19:47     ` Bart Schaefer
  3 siblings, 0 replies; 14+ messages in thread
From: Grant Taylor @ 2019-12-15 18:57 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]

On 12/15/19 12:57 AM, Andrew Parker wrote:
> The privilege escalation comes after the PATH is changed.

Please clearly explain what you think the privilege escalation is.

Changing the PATH does not change privileges.  It likely changes which 
program gets executed.

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

This is why that it is best practice to put the full path to commands 
when when possible.  Particularly in scripts.

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

I don't know about homebrew.  But I do know that this is exactly why 
sudo scrubs (rebuilds) (almost all of) the environment as the target 
user and specifically does NOT copy it from the source user.

If homebrew, or more specifically the sudoers template allowing this, is 
going contrary to all sudo best practices that I've ever read.  Sudo 
should be configured to thwart such an attack.

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

This is one of the reasons that sudo templates specify which command(s), 
including the full path, is (are) allowed to be executed, likely 
including parameters.

Yes, it is the system administrator's job to do the auditing that you 
specify /if/ they care about avoiding the class of things you are asking 
about.  Many ~> most do not.  Or if they do aren't able to audit things 
for one reason or another.

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

Remember that the PATH environment variable is a convenience.  I can 
still specify the full path to a program and run it.  So simply setting 
PATH and then making it read-only won't prevent a determined actor.  It 
may be another picket fence to close and latch.

Aside:  I believe in and advocate closing and latching as many picket 
fences as possible.  But I do question the security value of what I 
understand to be discussed in this thread.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  7:57   ` Andrew Parker
                       ` (2 preceding siblings ...)
  2019-12-15 18:57     ` Grant Taylor
@ 2019-12-15 19:47     ` Bart Schaefer
  2019-12-17 13:34       ` Andrew Parker
  3 siblings, 1 reply; 14+ messages in thread
From: Bart Schaefer @ 2019-12-15 19:47 UTC (permalink / raw)
  To: Andrew Parker; +Cc: Daniel Shahaf, Zsh Users

Daniel has pretty well summed this up, but just one thing:

On Sat, Dec 14, 2019 at 11:58 PM Andrew Parker
<andrew.j.c.parker@gmail.com> wrote:
>
> 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.

That's not how sudo normally works.  In most cases sudo discards the
environment and replaces it with a default system-configured one.  To
run with the user's environment, it is both necessary to invoke "sudo
-E", and for the security policy associated with that user to permit
preserving the environment.

       -E, --preserve-env
                   Indicates to the security policy that the user wishes to
                   preserve their existing environment variables.  The
                   security policy may return an error if the user does not
                   have permission to preserve the environment.

It is the responsibility of the program that escalates the privilege
to make sure it is not making unsafe assumptions, not the
responsibility of the shell (or any other program) in the
non-privileged state.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15  8:41 ` Roman Perepelitsa
  2019-12-15  8:49   ` Andrew Parker
  2019-12-15 14:31   ` Andrew Parker
@ 2019-12-16  4:10   ` Daniel Shahaf
  2 siblings, 0 replies; 14+ messages in thread
From: Daniel Shahaf @ 2019-12-16  4:10 UTC (permalink / raw)
  To: Zsh Users; +Cc: Andrew Parker

Roman Perepelitsa wrote on Sun, Dec 15, 2019 at 09:41:14 +0100:
> On Sun, Dec 15, 2019 at 7:29 AM Andrew Parker
> <andrew.j.c.parker@gmail.com> wrote:
> > 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
> 
> You can do this by creating /etc/zshenv (owned by root) with the
> following content (untested):
> 
>   [[ -o no_rcs ]] && return
> 
>   () {
>     emulate -L zsh -o extended_glob
>     local file files=(zshenv)
>     [[ -o login       ]] && files+=(zprofile zlogin zlogout)
>     [[ -o interactive ]] && files+=(zshrc)
>     for file in ${ZDOTDIR:-~}/.$^files; do
>       [[ ! -f $file || -n $file(#qNu0g0^W) ]] && continue
>       # Either not owned by root:root or world writable.
>       echo -E - "skipping zsh user rcs because ${(q)file} is tainted" >&2
>       setopt no_rcs
>       return 1  # alternatively: exit 1
>     done
>   }
> 

This piece of code should not be used in production; it is insecure.

> This checks whether any of the user rc files are tainted (either not
> owned by root:root or world-writable) and unsets rc option if so. This
> will prevent zsh from sourcing rc files from the user's home
> directory. You can take some other action there if you like, such as
> exiting the shell.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15 19:47     ` Bart Schaefer
@ 2019-12-17 13:34       ` Andrew Parker
  0 siblings, 0 replies; 14+ messages in thread
From: Andrew Parker @ 2019-12-17 13:34 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Daniel Shahaf, Zsh Users

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

I think there's a major difference here in the way Apple's sudo works. It's
simple to check on macOS that *sudo env* preserves PATH (but not other
variables). It can be fixed with *secure_path* in sudoers file. Possibly
other nix systems fix this with *secure_path *by default? Don't have access
to my VMs right now to check.

On Mon, Dec 16, 2019 at 3:48 AM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> Daniel has pretty well summed this up, but just one thing:
>
> On Sat, Dec 14, 2019 at 11:58 PM Andrew Parker
> <andrew.j.c.parker@gmail.com> wrote:
> >
> > 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.
>
> That's not how sudo normally works.  In most cases sudo discards the
> environment and replaces it with a default system-configured one.  To
> run with the user's environment, it is both necessary to invoke "sudo
> -E", and for the security policy associated with that user to permit
> preserving the environment.
>
>        -E, --preserve-env
>                    Indicates to the security policy that the user wishes to
>                    preserve their existing environment variables.  The
>                    security policy may return an error if the user does not
>                    have permission to preserve the environment.
>
> It is the responsibility of the program that escalates the privilege
> to make sure it is not making unsafe assumptions, not the
> responsibility of the shell (or any other program) in the
> non-privileged state.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Thoughts on protecting against PATH interception via user owned profiles
  2019-12-15 14:43     ` Roman Perepelitsa
@ 2019-12-17 13:35       ` Andrew Parker
  0 siblings, 0 replies; 14+ messages in thread
From: Andrew Parker @ 2019-12-17 13:35 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Zsh Users

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Thanks. Info well received! Terminal on macOS starts a login shell for each
tab btw.

On Sun, Dec 15, 2019 at 10:43 PM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:

> On Sun, Dec 15, 2019 at 3:31 PM Andrew Parker
> <andrew.j.c.parker@gmail.com> wrote:
> >
> > Oh man. Back at keyboard now. I see this is nothing zsh specific. The
> solution was right in front of me all the time. Just exit 1 from
> /etc/profile will work in bash.
>
> Note that /etc/profile is sourced by bash only when starting a login
> shell. It's not sourced when connecting over SSH, when running
> non-interactively or when starting an interactive shell without
> `--login`. Many (most? all?) graphical terminals start non-interactive
> shell when opening a new tab.
>
> All zsh processes start by sourcing /etc/zshenv (the actual location
> is hard-coded in the binary and can be overridden when building zsh)
> but there is no equivalent file for bash.
>
> I don't know if this makes any difference to your defense strategy but
> thought it might be worth mentioning.
>
> Roman.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2019-12-17 13:36 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-15  6:27 Thoughts on protecting against PATH interception via user owned profiles Andrew Parker
2019-12-15  7:14 ` Daniel Shahaf
2019-12-15  7:57   ` Andrew Parker
2019-12-15  8:49     ` Daniel Shahaf
2019-12-15 17:42     ` Lewis Butler
2019-12-15 18:57     ` Grant Taylor
2019-12-15 19:47     ` Bart Schaefer
2019-12-17 13:34       ` Andrew Parker
2019-12-15  8:41 ` Roman Perepelitsa
2019-12-15  8:49   ` Andrew Parker
2019-12-15 14:31   ` Andrew Parker
2019-12-15 14:43     ` Roman Perepelitsa
2019-12-17 13:35       ` Andrew Parker
2019-12-16  4:10   ` Daniel Shahaf

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).