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

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.

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

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.

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

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

#!/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.

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.

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.

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.

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

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.

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

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.

@vorlon has offered to sponsor this for eoan if/when he has time; once that's updated I will upload fixes to the documentation (e.g. man pages) for SRU releases.

This bug was fixed in the package sudo - 1.8.27-1ubuntu2

---------------
sudo (1.8.27-1ubuntu2) eoan; urgency=medium

  * Remove d/p/keep_home_by_default.patch (LP: #1556302)
    - This restores sudo handling of $HOME to what everyone else does

 -- Dan Streetman <email address hidden> Tue, 04 Jun 2019 08:58:02 -0400

manpage patches for SRU releases are in git here:
https://code.launchpad.net/~ddstreet/ubuntu/+source/sudo/+git/sudo

and builds here:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1556302

As this is a manpage-only SRU, it's likely to be rejected if uploaded by itself; if anyone has any bugfix to apply to sudo in the future, please consider including the manpage patches from this bug as well.

Follow up for anyone coming here because of Ubuntu's unique (pre-19.10) behavior of not changing $HOME when calling sudo; if this is causing you problems, you should change your calling of sudo to include the -H param which will force sudo on Ubuntu to change HOME to the target user's homedir, instead of leaving it as the calling user's homedir.

@kibitih, please don't change the bug status without at least providing an upload or some kind of explanation

@lolo, comment #19 applies to you as well