This is Debian bug 700729 <http://bugs.debian.org/700729> which I have been asked to report upstream. I am running the Debian packages of Samba (version 2:3.6.6-5) on a Debian Wheezy (testing) installation.
Since installing the latest security update for CVE-2013-0213 and CVE-2013-0214 server password management in SWAT has stopped working. Whatever is entered for the old and new passwords the page just reloads without doing anything. var/log/samba/log. gets lots of lines like this:
[2013/02/16 15:02:30.297508, 0] passdb/secrets.c:76(secrets_init)
Failed to open /var/lib/samba/secrets.tdb
# ls -l /var/lib/samba/secrets.tdb
-rw------- 1 root root 430080 Aug 24 23:30 /var/lib/samba/secrets.tdb
24 August is the date I first installed Samba.
SWAT is being run from stunnel as root.
My smb.conf file looks like this:
workgroup = FUNDAMENTALS
server string = %h server
interfaces = 127.0.0.0/8, bond0
bind interfaces only = Yes
obey pam restrictions = Yes
pam password change = Yes
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
load printers = No
os level = 65
preferred master = Yes
domain master = Yes
dns proxy = No
wins support = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
invalid users = root
comment = Service files
path = /srv/smb/service
read only = No
create mask = 0775
force create mode = 0664
directory mask = 0770
force directory mode = 0770
oplocks = No
level2 oplocks = No
There are several other similar share definitions.
As password changing is a major function of SWAT, in my opinion this qualifies as a major severity bug. If you disagree please revert.
This regression was definitely introduced with the latest security patches. Reverting to the previous Debian packages (2:3.6.6-4) fixes the problem for both me and someone else posting to the Debian bug.
As a workaround, if you can live without the extra-paranoid XSRF patches introduced for CVE-2013-0214, just back out that patch again. The XSRF requires the attacker to know the user's password, and in my opinion you're in trouble at that point already.
SWAT is without a real maintainer at the moment, and nobody had the time to issue a real fix for this issue yet.
For the record, the correct fix would be to check for the random nonce from secrets.tdb before dropping root privileges. Patches are welcome.
swat is removed with 4.1
We're continuing to run the insecure version of Samba in the meantime. Fortunately this server will soon cease to be my responsibility and my nice Linux box will be replaced with something running Windows and Exchange by an external IT support company.
"Insecure" for values of "being logged into SWAT as root while browsing attacker websites".