Bug 104641

Reported by Michal Zalewski to Vulnwatch on Jul 02 2003

Starting release 9, Red Hat ships and uses pam_timestamp_check.so module
(accompanied by /sbin/pam_timestamp_check setuid helper), a part of the
new pam-0.75 (Pluggable Authentication Modules) package. PAM is a generic
centralized authentication and session management component that is also
shipped by an increasing number of other distributions, so it is
reasonable that the code is about to propagate to other distros.

The module mentioned implements a credential caching functionality, very
closely inspired on a tty ticketing system used in sudo. Most sudo users
are familiar with the fact they are not prompted for password if a
subsequent sudo session is opened shortly after a previous one on the same
terminal - and this is exactly what pam_timestamp_check tries to implement
for other services.

The system used in sudo is somewhat naive and does have its problems, but
the impact caused by an eventual ticket stealing attack is fairly minimal
- the user has to be trusted and listed in /etc/sudoers in the first
place, and the credentials that are cached are for his own account (sudo
users enter their own password, as opposed to root's).

The way Red Hat deployed this mechanism is badly broken, since they use it
to cache root credentials for access to critical components of the system,
and there are no restrictions as to who can use those components. While in
sudo, stealing or spoofing a ticket is worth exactly as much as knowing
the password for the account you already have access to, and the account
has to be trusted, in Red Hat, it is worth root's password almost all the
time, and any user can use it. As such, there should me much more caution
exercised with such a mechanism. But there is not, causing an obvious
exposure.

The way the module (and sudo) works, in essence, is that it gets current
pseudo-terminal name A (which can be trivially spoofed, but this is of no
relevance at the moment), current user name B, and the user for which
credentials are cached, C (usually root for Red Hat applications, user
himself for sudo). Then the code checks for /var/run/sudo/B/A:C (or
/var/run/sudo/B/A if B == C), and if the file is recent, the module
returns success, and enables the user to skip the usual password
authentication.

The mechanism is used in Red Hat to make it easier for users to perform
administrative tasks without having to switch to root via su or sudo,
granted they know the admin password. There is a number of management
applications that can be invoked via a single setuid PAM-enabled wrapper,
/usr/sbin/userhelper, that all have pam_timestamp_check.so included in their
PAM configs. From quite harmless ones, such as redhat-config-mouse,
to pretty much instant root scenarios once the mechanism is compromised
- say, redhat-config-rootpassword, redhat-install-packages, up2date-config,
redhat-config-services, etc.

A noble concept indeed, but there is a nasty issue - since there's no
check for file origin, it should be more than obvious that suddenly, any
insecure file creation problem in an application used by a superuser (or
from privileged scripts, such as boot rc files, crontabs, etc), it is
possible to spoof a ticket in /var/run and bypass root password prompt and
other checks, and perform administrative tasks, easily modifying system
config, installing custom components (say, a rootshell), etc. All this by
crafting a single symlink that is later opened with O_CREAT with no O_EXCL
or O_NOFOLLOW.

The simplest workaround for all concerned users is to first remove all
occurrences of pam_timestamp_check.so from /etc/pam.d, and replace
/sbin/pam_timestamp_check standalone helper, if possible. Perhaps
reconsider the necessity of having /usr/sbin/userhelper mechanism
implemented at all.

For Red Hat, my suggestion is to verify ticket contents. Say, have a
host-wide random key K, and put user_name, expire_time, MD5(K + user_name
+ expire_time) in every ticket. The check code would verify the MD5
signature to make sure the origin of the ticket is sane, and the
originating application performed a specific operation on a not publicly
readable key.

On a side note, the per-terminal ticketing in pam_timestamp_check the way
it is has absolutely no significance and adds no protection, since the A
element of the path can be easily manipulated. Just an example (there are
other possible ways of accomplishing this):

    ln `tty` /tmp/tty1
    /usr/sbin/userhelper -w -t redhat-install-packages </tmp/tty1

As such, those tickets effectively become per-user, and an attacker who
compromised the account can snatch a ticket granted to the legitimate user
who already authenticated. Consider dropping the honor tty system and
granting per-user tickets to avoid giving users a false sense of security.