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: [global] 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 [Service] 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. Thanks.
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".