Samba problems (new release available)

[Andrew Tridgell]

I have released a new version of Samba (version 1.9.18p6) which fixes
the potential buffer overflow problem pointed out by Drago. The new
release (and patches against previous releases) is available from
ftp://samba.anu.edu.au/pub/samba/

The fix I used was to write a slprintf() function that works much like
snprintf() but always null terminates the string. This replaced
sprintf in many places in the Samba source.

slprintf() is implemented in terms of vsnprintf() if
available. Otherwise is uses a memory area allocated with memalign
with the last page of the memory area protected from writes using
mprotect(). So on systems without vsnprintf() Samba will harmlessly
segfault on a buffer overflow (this is not a DOS attack because each
client gets their own copy of smbd)

Interestingly, when I looked into the problem further I found that our
previous efforts at buffer overflow prevention should have been
catching the exploit as it was posted here. The symptoms would have
been that smbd would have failed leaving the following in the log
file:

	  ERROR: string overflow by %d in pstrcpy [%.50s]

Drago, can you check if this happened? I'm interested in knowing
whether you just missed this in the logfile or if for some reason it
wasn't happening. The pstrcpy() of the filename in all the affected
routines should have ensured that the above got logged. Maybe you
didn't check the logs carefully and just assumed that a disconnected
drive == segv == exploitable?

In either case the new release replaces the sprintf with a
slprintf. The code definately did need fixing, the question is merely
whether it was in fact exploitable. It needed fixing because although
the string lengths were checked it did not check that the sum of the
length of the directory name and the filename did not exceed the
buffer size.

Cheers, Andrew