Advisory Name: PamSlam
Advisory Released: [01/04/00]
Application: userhelper and PAM on Redhat Linux 6.0/6.1
Severity: A local user can gain root access.
Status: Vendor contacted. Fix provided by vendor.
Advisory released.
Author: dildog@l0pht.com
WWW: http://www.l0pht.com/advisories.html
Overview:
Both 'pam' and 'userhelper' (a setuid binary that comes with the
'usermode-1.15' rpm) follow .. paths. Since pam_start calls down to
_pam_add_handler(), we can get it to dlopen any file on disk. 'userhelper'
being setuid means we can get root.
Description:
The combination of the fact that both userhelper and PAM follow ..
paths allows us to craft up a file that causes userhelper (by way of PAM) to
dlopen any shared object we want as root. The exploit is simple, and utilizes
the '-w' option of userhelper, which lets us specify a program to run with the
privileges designated by PAM. This tries to only execute programs that have
entries in /etc/security/console.apps, but since we get to specify the name,
something like ../../../tmp/myprog gets us a file open path that looks like
/etc/security/console.apps/../../../tmp/myprog. "strcat" is not a good way to
keep a filename below a directory!
After this hurdle, PAM is called to start up the binary, and it does
the same thing, looking for the filename in /etc/pam.d. If we've placed a rogue
pam.d configuration file in /tmp/myprog, then it can be pointed to
/etc/pam.d/../../../tmp/myprog. In the pam.d configuration file, we get to pick
a few shared libraries to dlopen, so at this point, we get root.
The following exploit demonstrates this vulnerability by creating a
'rootshell library' that creates a shell when dlopened, creating a pam.d-style
configuration file, and then running userhelper with the appropriately dotted
path.
