FS#20133 - [coreutils] su not reseting PATH environment variable

Attached to Project: Arch Linux
Opened by aze489 (aze489) - Friday, 09 July 2010, 20:58 GMT
Last edited by Allan McRae (Allan) - Thursday, 29 July 2010, 10:57 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Roman Kyrylych (Romashka)
Allan McRae (Allan)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
I noticed that su is not reseting the PATH environment variable.

$ PATH=/evildir:$PATH su
Password:
# echo $PATH
/evildir:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core

The security implications of this behaviour are easy to understand. If an attacker could overwrite my PATH environment variable, he could become root pretty easily.
I searched for a way to fix this behaviour and the only way i found is to use su with the --login option, that way, su overwrite PATH with a safe value and reset environment variables:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/su.c;h=f8f5b6188a54ca70417790afbef47f9924f6f1a2;hb=HEAD#l243
This is not optimal. I seriously people are always thinking about using this option or even realise the consequences of not using it.

I tested other linux distributions. debian, ubuntu and gentoo, don't have this problem.
(debian and ubuntu use su from the "shadow" package, and it resets PATH using the variables ENV_SUPATH and ENV_PATH defined in /etc/login.defs)




Package name:
coreutils (latest version)

Steps to reproduce:
$ PATH=/evildir:$PATH su
Password:
# echo $PATH
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 29 July 2010, 10:57 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Documented upstream behaviour.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 09 July 2010, 22:37 GMT
Wheel with the same arguments you can view sudo command with this issue, because /etc/sudoers is installed as provided by upstream and does not reset env by default.
Comment by Allan McRae (Allan) - Saturday, 10 July 2010, 03:32 GMT
This is the documented behaviour of su from coreutils so is not a bug.

What are the relative merits of the various su implementations? If the one from shadow is obviously better, then I have happy to remove the one from the coreutils package.

Anyway, if someone gets to have enough permissions on your system that they can change your path, I sure they can get root without having to wait for you to use "su" and run a binary in "/evildir"...
Comment by aze489 (aze489) - Sunday, 11 July 2010, 16:45 GMT
If an attacker gets enough permission exploiting a vulnerability discovered in a software i use, it would probably be easier to exploit this problem with su (or sudo ?) than to try to use a local-root kernel exploit... unless i never update my kernel.

As for the merits of the different su implementations, shadows seems to offer a greater configurability, but i haven't extensively tested it.

Why is su from coreutils shipped with archlinux anyway ? Did someone choose it over shadow's version for a reason ?
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 11 July 2010, 16:58 GMT
>> If an attacker gets enough permission exploiting a vulnerability discovered in a software I use, it would probably be easier to exploit this problem with su

Under the same sufficient condition the attacker can capture your root password or anything that you type on keyboard, so he do not need this issue with su :)
Comment by Leonid Isaev (lisaev) - Sunday, 11 July 2010, 22:33 GMT
Technically, su belongs to the login package in Ubuntu (9.10):
dpkg -S /bin/su
login: /bin/su

But still, I don't see the connection between resetting $PATH and compromising local root. Also, I wonder how is it possible to capture root password: which program has to be vulnerable?

Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 11 July 2010, 23:44 GMT
  • Field changed: Severity (Critical → High)
Under another hypothetical scenario, where a vulnerable program allow to write a ".profile" and insert PATH. Then a daemon or set LD_PRELOAD, can be executed, capture keys, send to, ... (not directly related with "su")
Comment by aze489 (aze489) - Monday, 12 July 2010, 22:56 GMT
@isaev: if you look at the login package, you will see that it is provided by shadow: http://packages.ubuntu.com/karmic/login "Download Source Package shadow"
@djgera: Are you talking about a "keylogger" that would be injected using LD_PRELOAD to intercept keystrike in applications ? you know that LD_PRELOAD has no effect on setuid binaries, (including su/sudo/X...) right ? so i don't see how someone could capture my root password with such a technique.
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 12 July 2010, 23:14 GMT
@aze489: Yes LD_*, this is because I say: "... (not directly related with "su")." (and was just another example)
On the same hypothetical scenario that a vulnerable program allow write to an arbitrary file (for example .profile) can write an entry to it that launches an untrusted shell, etc.
Comment by Allan McRae (Allan) - Thursday, 29 July 2010, 10:56 GMT
Closing this task. It is the documented upstream behaviour.

If the shadow maintainer wants to include the "su" binary from that package, then that can be arranged.

Loading...