exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Mar 19, 2004
Authored by Shaun Colley aka shaun2k2

smbprint insecurely writes to files in /tmp allowing for a symbolic link attack. Full details on exploitation included.

tags | exploit
SHA-256 | 5f8fabd4db56afb335dc8f91646c031c7ae3fbc783d0d675174bdc907f203a29


Change Mirror Download

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
Email: shaunige@yahoo.co.uk
WWW: http://www.nettwerked.co.uk



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

Thank you for your time.

Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
Login or Register to add favorites

File Archive:

December 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    11 Files
  • 2
    Dec 2nd
    0 Files
  • 3
    Dec 3rd
    0 Files
  • 4
    Dec 4th
    32 Files
  • 5
    Dec 5th
    10 Files
  • 6
    Dec 6th
    14 Files
  • 7
    Dec 7th
    0 Files
  • 8
    Dec 8th
    0 Files
  • 9
    Dec 9th
    0 Files
  • 10
    Dec 10th
    0 Files
  • 11
    Dec 11th
    0 Files
  • 12
    Dec 12th
    0 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By