Ubuntu patch to add HOME to env_keep makes custom commands vulnerable by default
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Release Notes for Ubuntu |
Undecided
|
Unassigned | ||
| sudo (Ubuntu) |
Medium
|
Dan Streetman | ||
| Xenial |
Low
|
Unassigned | ||
| Bionic |
Low
|
Unassigned | ||
| Cosmic |
Low
|
Dan Streetman | ||
| Disco |
Low
|
Dan Streetman | ||
| Eoan |
Medium
|
Dan Streetman |
Bug Description
[impact]
sudo does not set HOME to the target user's HOME
[test case]
ddstreet@thorin:~$ sudo printenv | grep HOME
HOME=/home/ddstreet
[regression potential]
this is a significant behavior change. As mentioned in comment 11 (and later, and other bugs duped to this, and the mailing list discussion, etc) users of Ubuntu so far have been used to running sudo with their own HOME set, not root's HOME. Therefore, it's inappropriate to change this behavior for existing releases; this should be changed starting in Eoan, and only the sudo and sudoers man pages changed in previous releases to indicate the actual behavior of sudo in those releases.
[other info]
Shortly after upstream changed the behavior, the patch to keep HOME as the calling (instead of target) user was added in bug 760140.
For quick reference to anyone coming to this bug, the pre-19.10 behavior (of sudo keeping the calling user's $HOME) can be disabled by running 'sudo visudo' and adding this line:
Defaults always_set_home
or, run sudo with the -H param.
--
original description:
--
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_
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/.
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_
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.
summary: |
- Ubuntu patch to add HOME to env_keep makes Python commands vulnerable by + Ubuntu patch to add HOME to env_keep makes custom commands vulnerable by default |
Simon Arlott (sa.me.uk) wrote : | #1 |
Steve Beattie (sbeattie) wrote : | #2 |
Hi Steve, since you added the original patch, can you take a look at this? Thanks.
Steve Langasek (vorlon) wrote : | #3 |
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) wrote : | #4 |
Proof of concept:
/etc/sudoers contains:
%dns_simon ALL=(dns_zonefiles) NOPASSWD: /home/dns/
Prepare python code to run automatically as the calling user:
$ mkdir -p "$HOME/
$ echo "import subprocess" > "$HOME/
$ echo "subprocess.
$ echo "import exploit" > "$HOME/
Calling user credentials:
$ id
uid=1001(simon) gid=1001(simon) groups=
Exploit script executing as called user credentials:
$ sudo -u dns_zonefiles /home/dns/
uid=999(
Without the Ubuntu patch:
$ sudo -u dns_zonefiles /home/dns/
Processing example.com...
Marc Deslauriers (mdeslaur) wrote : | #5 |
What does your shebang look like in the python script? Does it include -E and -s?
Simon Arlott (sa.me.uk) wrote : | #6 |
#!/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.
information type: | Private Security → Public Security |
C de-Avillez (hggdh2) wrote : | #7 |
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.
Changed in sudo (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in sudo (Ubuntu): | |
assignee: | nobody → Ubuntu Security Team (ubuntu-security) |
Dan Streetman (ddstreet) wrote : | #8 |
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@
HOME=/home/ddstreet
[ddstreet@
HOME=/root
[ddstreet@
HOME=/home/ddstreet
[ddstreet@
HOME=/root
[ddstreet@rhel-8 ~]$ printenv | grep HOME
HOME=/home/ddstreet
[ddstreet@rhel-8 ~]$ sudo printenv | grep HOME
HOME=/root
ddstreet@
HOME=/home/ddstreet
ddstreet@
HOME=/root
ddstreet@sles-15:~> printenv | grep HOME
HOME=/home/ddstreet
ddstreet@sles-15:~> sudo printenv | grep HOME
HOME=/root
ddstreet@
HOME=/home/ddstreet
ddstreet@
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@
HOME=/home/ddstreet
ddstreet@
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) wrote : | #9 |
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@lp1556302:~$ sudo vim /tmp/test
ubuntu@lp1556302:~$ ls -l /home/ubuntu/.vim*
-rw------- 1 root root 700 May 14 16:31 /home/ubuntu/
ubuntu@lp1556302:~$ ls -ld /home/ubuntu/
ls: cannot access '/home/
ubuntu@lp1556302:~$ sudo emacs /tmp/test
ubuntu@lp1556302:~$ ls -ld /home/ubuntu/
drwx------ 2 root root 4096 May 14 16:32 /home/ubuntu/
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) wrote : | #10 |
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) wrote : | #11 |
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.
description: | updated |
Robie Basak (racb) wrote : | #12 |
There is a mailing list discussion on this topic currently active here: https:/
Dan Streetman (ddstreet) wrote : | #13 |
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.
Dan Streetman (ddstreet) wrote : | #14 |
tags: | added: patch |
description: | updated |
Dan Streetman (ddstreet) wrote : | #15 |
@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.
Changed in sudo (Ubuntu Eoan): | |
status: | Confirmed → In Progress |
assignee: | Ubuntu Security Team (ubuntu-security) → Dan Streetman (ddstreet) |
Changed in sudo (Ubuntu Disco): | |
status: | New → In Progress |
Changed in sudo (Ubuntu Cosmic): | |
status: | New → In Progress |
Changed in sudo (Ubuntu Bionic): | |
status: | New → In Progress |
Changed in sudo (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in sudo (Ubuntu Disco): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in sudo (Ubuntu Cosmic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in sudo (Ubuntu Bionic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in sudo (Ubuntu Xenial): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in sudo (Ubuntu Disco): | |
importance: | Undecided → Low |
Changed in sudo (Ubuntu Cosmic): | |
importance: | Undecided → Low |
Changed in sudo (Ubuntu Bionic): | |
importance: | Undecided → Low |
Changed in sudo (Ubuntu Xenial): | |
importance: | Undecided → Low |
description: | updated |
Launchpad Janitor (janitor) wrote : | #16 |
This bug was fixed in the package sudo - 1.8.27-1ubuntu2
---------------
sudo (1.8.27-1ubuntu2) eoan; urgency=medium
* Remove d/p/keep_
- This restores sudo handling of $HOME to what everyone else does
-- Dan Streetman <email address hidden> Tue, 04 Jun 2019 08:58:02 -0400
Changed in sudo (Ubuntu Eoan): | |
status: | In Progress → Fix Released |
Dan Streetman (ddstreet) wrote : | #17 |
manpage patches for SRU releases are in git here:
https:/
and builds here:
https:/
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.
Dan Streetman (ddstreet) wrote : | #18 |
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.
Changed in sudo (Ubuntu Disco): | |
status: | In Progress → Won't Fix |
Changed in sudo (Ubuntu Cosmic): | |
status: | In Progress → Won't Fix |
Changed in sudo (Ubuntu Bionic): | |
assignee: | Dan Streetman (ddstreet) → nobody |
Changed in sudo (Ubuntu Xenial): | |
assignee: | Dan Streetman (ddstreet) → nobody |
Changed in ubuntu-release-notes: | |
status: | New → Confirmed |
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.