The Samba Vulnerability [LWN.net]

[This article was contributed by Tom Owen]

Samba.org's announcement of 2.2.8 last week had a eerie familiarity. Here's a release prompted by heap overflow in a major open source server component. A fortnight ago it was sendmail -- this time it's Samba, the free SMB/CIFS server. The vulnerability was spotted by the reliably hard-nosed security team at SuSE. Samba team members say there's a risk of remote root compromise; all sites are urged to plan an urgent upgrade. The LWN vulnerability entry has links to distributions' patches, and the new version 2.2.8 which contains the fix.

The vulnerability dates back to 2.0.x, which is over four years old. This is the Samba version which introduced domain logon for Windows NT clients. If your server has been updated since 1999, or looks like a domain controller for NT clients then it is vulnerable.

The vulnerability is described as a buffer overflow in smbd's message fragment assembly code. Any exploit would send crafted SMB fragments to TCP port 139. Also fixed in the new release is a locally exploitable race condition.

Even in a tightly-run site, this vulnerability is a serious threat, potentially allowing root access to local users. What gets plain scary is that there are sites which expose SMB to the Internet. This can't ever be the right thing to do whether the server is Samba or Windows. The problem is not the servers but the protocol. The MS network neighbourhood browser can be easy to use but the price is that anyone can connect to a server and list users, servers and shares -- perfect background for social hacking, and an easy route to find any share which, by error or design, has less than perfect security settings. Security is easier to control down with Samba than Windows,but it is best simply not to expose it to the net at all.

The announcement goes into detail on the precautions any Samba site should be taking. They have little to do with the vulnerability -- they don't protect against a local attack -- and every site ought to be doing them anyway.

The first step is to make sure that ports for SMB and WINS are blocked at the Internet gateway. This risk is so well understood that many cheap routers include a standardised filter set (typically called something like NETBIOS) to block ports 137, 138 and 139. This is good as far as it goes, but Microsoft is moving away from these ports. More recent Microsoft servers offer SMB directly on TCP at port 445, so this is one more port to block. Samba 2.2 doesn't use 445 but the upcoming 3.0 will.

Samba's daemons are not normally run under inetd.conf and so can't be protected by TCP wrappers. The announcement shows how to use smb.conf directives to get similar control:

One of the simplest fixes in this case is to use the 'hosts allow' and 'hosts deny' options in the Samba smb.conf configuration file to only allow access to your server from a specific range of hosts. An example might be:

        hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
        hosts deny = 0.0.0.0/0

The above will only allow SMB connections from 'localhost' (your own computer) and from the two private networks 192.168.2 and 192.168.3. All other connections will be refused connections as soon as the client sends its first packet. The refusal will be marked as a 'not listening on called name' error.

It seems rash to put a file server on to your Internet gateway, but a lot of home and small business hosts are setup that way. These sites can control their exposure with 'interfaces=' and 'bind interfaces only = yes' but a cheap basic filtering router is probably a better plan.

Samba servers have one extra risk not shared by Windows servers. The Samba Web Administration Tool (SWAT) runs under inetd, normally via TCP wrappers. Care is needed in inetd.conf and hosts.allow to restrict access to SWAT to the local network, and not on the Internet. Alternatively, there are instructions on how to offer SWAT over SSL.

One way this Samba vulnerability stands out from Sendmail earlier this month is that it's a bit of surprise. Despite Samba's long history and wide use, it has shown few vulnerabilities which are not a consequence of the SMB protocol. The other way is that malicious exploits appear to have been tested or used before the announcement. SuSE saw anomalous crashes in one of their public servers. Analysis of the logs was enough to persuade the Samba team to bring 2.2.8 release forward -- a truly alarming response. Site administrators should act soon, first to make sure that their SMB is not visible on the Internet, and then to upgrade Samba to 2.2.8.

(Thanks to Jeremy Allison for assistance with this article).

(Log in to post comments)