Ubuntu patch to add HOME to env_keep makes custom commands vulnerable by default

[Simon Arlott]

I wanted to allow certain users to execute a python script as another user, so I created the following sudoers config:
Defaults env_reset
source_user ALL=(target_user) NOPASSWD: /home/target_user/bin/script.py

This results in a highly insecure Python environment because the source user can set HOME and override any Python package by putting files in $HOME/.local/lib/python*/site-packages/.

This should be a safe configuration because the default behaviour (as specified in the man page) is that env_reset will replace HOME with the target user's home directory. The "env_reset" option even has special behaviour for bash which has its own potential environment vulnerabilities.

However there is an Ubuntu-specific patch in the package (keep_home_by_default.patch) that makes sudo preserve HOME by default, which negates the correct behaviour of "env_reset". It should not be necessary to explicitly specify the "always_set_home" option in order to negate this patch.

The patch should be removed and the default /etc/sudoers should explicitly add HOME to "env_keep" for the "allow admins to run any command as root" entries, to get the desired behaviour without creating security issues for other sudoers commands.

Note: for quick reference to anyone coming to this bug, this behavior (of sudo keeping the calling user's $HOME) can be disabled by running 'sudo visudo' and adding this line:

Defaults always_set_home

[Simon Arlott (sa.me.uk)]

I can't find a way to make sudo execution of a bash script unsafe but there will be other commands that assume it is safe to read configuration or executable code from $HOME.

[Steve Beattie (sbeattie)]

Hi Steve, since you added the original patch, can you take a look at this? Thanks.

[Steve Langasek (vorlon)]

This change was originally introduced in response to bug #760140.

The upstream change in sudo was never accompanied by a CVE, and the behavior change was never applied to previous releases of Ubuntu, so it didn't seem security sensitive at the time.

I am not opposed to changing this to behave the way Simon describes, but I defer to the Security Team here.

[Simon Arlott (sa.me.uk)]

Proof of concept:
/etc/sudoers contains:
%dns_simon ALL=(dns_zonefiles) NOPASSWD: /home/dns/zonefiles/bin/dns-reload simon

Prepare python code to run automatically as the calling user:
$ mkdir -p "$HOME/.local/lib/python3.5/site-packages/exploit"
$ echo "import subprocess" > "$HOME/.local/lib/python3.5/site-packages/exploit/__init__.py"
$ echo "subprocess.run(['id'])" >> "$HOME/.local/lib/python3.5/site-packages/exploit/__init__.py"
$ echo "import exploit" > "$HOME/.local/lib/python3.5/site-packages/exploit.pth"

Calling user credentials:
$ id
uid=1001(simon) gid=1001(simon) groups=1001(simon),100(users),1007(dns_simon)

Exploit script executing as called user credentials:
$ sudo -u dns_zonefiles /home/dns/zonefiles/bin/dns-reload simon
uid=999(dns_zonefiles) gid=995(dns_zonefiles) groups=995(dns_zonefiles)

Without the Ubuntu patch:
$ sudo -u dns_zonefiles /home/dns/zonefiles/bin/dns-reload simon
Processing example.com...

[Marc Deslauriers (mdeslaur)]

What does your shebang look like in the python script? Does it include -E and -s?

[Simon Arlott (sa.me.uk)]

#!/usr/bin/env python3

If I add -s or -S then the script is safe, but it should be able to trust HOME by default.

[C de-Avillez (hggdh2)]

I think the Ubuntu patch has been obsoleted by common usage now, with pretty much all distros using upstream version (of *not* keeping HOME).

Removing the patch would lower the delta we carry; additionally there is the benefit of having Ubuntu behave as everybody else, lowering the easter-egg count of weird differences between distros.

Given 19.04 has been released, we should remove for u+1. This will give us enough time to find out and clean unsafe usage (if any).

Setting Confirmed/Medium.

[Dan Streetman (ddstreet)]

For additional clarification:

As mentioned already, the Ubuntu patch diverges from upstream sudo.

Additionally, here what other Linux distros do:

ddstreet@debian:~$ printenv | grep HOME
HOME=/home/ddstreet
ddstreet@debian:~$ sudo printenv | grep HOME
HOME=/root

[ddstreet@fedora-workstation ~]$ printenv | grep '^HOME'
HOME=/home/ddstreet
[ddstreet@fedora-workstation ~]$ sudo printenv | grep '^HOME'
HOME=/root

[ddstreet@fedora-server ~]$ printenv | grep '^HOME'
HOME=/home/ddstreet
[ddstreet@fedora-server ~]$ sudo printenv | grep '^HOME'
HOME=/root

[ddstreet@rhel-8 ~]$ printenv | grep HOME
HOME=/home/ddstreet
[ddstreet@rhel-8 ~]$ sudo printenv | grep HOME
HOME=/root

ddstreet@opensuse-15:~> printenv | grep HOME
HOME=/home/ddstreet
ddstreet@opensuse-15:~> sudo printenv | grep HOME
HOME=/root

ddstreet@sles-15:~> printenv | grep HOME
HOME=/home/ddstreet
ddstreet@sles-15:~> sudo printenv | grep HOME
HOME=/root

ddstreet@slackware:~$ printenv | grep HOME
HOME=/home/ddstreet
ddstreet@slackware:~$ sudo printenv | grep HOME
HOME=/root

And even other UNIXes:

ddstreet@netbsd-8: $ printenv | grep HOME
HOME=/home/ddstreet
ddstreet@netbsd-8: $ sudo printenv | grep HOME
HOME=/root

ddstreet@freebsd-12: $ printenv | grep HOME
HOME=/home/ddstreet
ddstreet@freebsd-12: $ sudo printenv | grep HOME
HOME=/root

openbsd$ printenv | grep HOME
HOME=/home/ddstreet
openbsd$ sudo printenv | grep HOME
HOME=/root

We appear to be completely alone in adding HOME to env_keep by default.

[Dan Streetman (ddstreet)]

Further, this behavior causes root-owned files and directories in a user's home directory, e.g.:

ubuntu@lp1556302:~$ ls -l /home/ubuntu/.vim*
ls: cannot access '/home/ubuntu/.vim*': No such file or directory
ubuntu@lp1556302:~$ sudo vim /tmp/test
ubuntu@lp1556302:~$ ls -l /home/ubuntu/.vim*
-rw------- 1 root root 700 May 14 16:31 /home/ubuntu/.viminfo

ubuntu@lp1556302:~$ ls -ld /home/ubuntu/.emacs*
ls: cannot access '/home/ubuntu/.emacs*': No such file or directory
ubuntu@lp1556302:~$ sudo emacs /tmp/test
ubuntu@lp1556302:~$ ls -ld /home/ubuntu/.emacs*
drwx------ 2 root root 4096 May 14 16:32 /home/ubuntu/.emacs.d

bug 1828208

and so on. This problem is true for *any* program/application that creates any files in $HOME, and might be run under sudo.

[Dan Streetman (ddstreet)]

Another example, which can happen in newly deployed containers/vms:

ubuntu@lp1556302:~$ ls -la .bash_history
ls: cannot access '.bash_history': No such file or directory
ubuntu@lp1556302:~$ sudo bash
root@lp1556302:~# exit
exit
ubuntu@lp1556302:~$ ls -la .bash_history
-rw------- 1 root root 5 May 14 16:36 .bash_history

[Dan Streetman (ddstreet)]

The *downside* of reverting our custom patch is that end-users are used to all their personal customization of applications from $HOME working; i.e. currently, when anyone runs vim, emacs, bash, etc. under sudo, any ~/.WHATEVER customization they have will be retained. This is different than, essentially, all other UNIXes, and the fix for this bug would undo that, to put us back in line with all other UNIXes - but would result in behavior change for users, where e.g. 'sudo vim' would not pick up any of their ~/.vimrc configuration (or ~/.emacs.d for emacs, etc...)

Thus, this change, if we do make it, probably should only be done to Eoan and not SRUed.

[Robie Basak (racb)]

There is a mailing list discussion on this topic currently active here: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2019-May/018345.html

[Dan Streetman (ddstreet)]

from the mailing list discussion (linked above by @racb), this response from an upstream sudo developer Todd C. Miller:

On Thu, 16 May 2019 07:48:40 -0400, Dan Streetman wrote:

> I've cc'ed sudo-users, so the question to the upstream sudo list can
> be summarized as:
> How likely would it be for upstream sudo to add HOME to env_keep by default?

Extremely unlikely. Prior to sudo 1.7.4 the HOME and MAIL environment
variables were preserved in the environment by default. This can
lead to programs using config files the original user's home
directory, which has security implications, so the default was
changed in 1.7.4.

In the old days, sudo did little more than change the uid. These
days sudo tries to run the command in an environment that closely
matches what you would get by logging in as that user. This has
proven to be safer as it more closely matches the assumptions other
programs make.

> We ask because Ubuntu carries a patch that adds HOME to env_keep,
> unlike the default upstream, or any other Linux/Unix. We are
> considering removing that patch, to match upstream defaults, of *not*
> including HOME in env_keep.

I would be supportive of that. I believe that resetting HOME is
the safer default.