Weekly Edition
Return to the Development page
| ||||||||||||||||||||||
Samba developers considering removing SWAT
As most of you would have noticed, we have now had 3 CVE-nominated security issues for SWAT in the past couple of years. At the same time, while I know many of our users use SWAT, we just don't have anybody to maintain it inside the Samba Team. Kai has made a valiant effort to at least apply the XSS and CSRF guidelines when folks make security reports, but by his own admission he isn't a web developer - none of us are! There are many other parts of Samba that have not been substantially maintained in years, but few have the level of security exposure that SWAT does (most are bits of library and utility code that we apply elsewhere, but which just quietly does it's own job). The issue isn't that we can't write secure code, but that writing secure Web code where we can't trust the authenticated actions of our user's browser is a very different modal to writing secure system code. Frankly it just isn't our area. Therefore, it was suggested on a private list that we just drop SWAT. I want to start a public discussion on that point, prompted by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700729 which reminds us why we didn't apply the specific CSRF hardening we applied in 4.0.2 to SWAT in the first place. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org (Log in to post comments)
Samba developers considering removing SWAT Posted Feb 20, 2013 16:20 UTC (Wed) by cmorgan (subscriber, #71980) [Link]
Sounds like a prudent idea. If people are interested in picking it up they will, if not at least it won't be a Samba sanctioned application that is exposing their systems to exploits.
CSRF Posted Feb 20, 2013 16:27 UTC (Wed) by epa (subscriber, #39769) [Link]
I wondered what CSRF was - it stands for cross-site request forgery and happens when the site allows actions to happen from a GET request. Then the hostile site just includes an <img> or other http: hyperlink, which triggers the GET request. But surely the fix is straightforward - every operation which changes something (rather than just displaying info) must check first of all that it is being invoked as POST.
CSRF Posted Feb 20, 2013 16:36 UTC (Wed) by mms (subscriber, #11532) [Link]
Unfortunately, things are not that simple. You can trigger CSRF with POST too, and it's really not that complex. All you have to do is fool someone into clicking on a hidden form submit button.
The real fix is non trivial, but most modern frameworks will do it for you.
CSRF Posted Feb 20, 2013 19:42 UTC (Wed) by josh (subscriber, #17465) [Link]
You don't even need to trick them; you can easily submit a hidden form via Javascript.
CSRF Posted Feb 21, 2013 8:37 UTC (Thu) by epa (subscriber, #39769) [Link] All you have to do is fool someone into clicking on a hidden form submit button.Ah, you're right! And by default the browser allows it, and the web server doesn't check either, so the program has to have all sorts of checks about where the form came from.
CSRF Posted Feb 21, 2013 2:23 UTC (Thu) by geofft (subscriber, #59789) [Link]
CSRF has nothing to do with GET vs. POST. The archetypal CSRF is when I write a form using POST that has the action pointing to some other site. The request is sent with the cookies (or other authentication context, like Basic auth or client certs) your browser has for the other site, but I'm in full control of what the parameters are.
One of the standard ways to defeat CSRF is to include a token as a hidden field in all legitimate forms, and check that the token is present valid when the form is received. But there are usually clever ways to retrieve the token and include it in your fake form, so the naive approach is insufficient.
CSRF Posted Feb 24, 2013 22:32 UTC (Sun) by butlerm (subscriber, #13312) [Link]
Presumably every self respecting web browser restricts access by scripts running in one domain of cookies and other data associated with another domain, i.e. implements a same origin policy. Without such protection, secure web access would be an oxymoron.
CSRF Posted Feb 24, 2013 23:00 UTC (Sun) by butlerm (subscriber, #13312) [Link]
I surprised, however, that browser developers haven't dropped the transmission of all third party session cookies. Even better would be to adopt a standard requiring cookies to be marked with a cross site submission requested attribute to ever be submitted on a third party basis. That would close thousands of these vulnerabilities overnight - at least for users running updated browsers.
CSRF Posted Feb 26, 2013 6:59 UTC (Tue) by speedster1 (subscriber, #8143) [Link]
http://www.h-online.com/open/news/item/Firefox-22-to-bloc...
This could help, except in cases where user has previously visited the attacker's website ("third-party cookies from sites which have created a cookie for themselves when the user has previously visited them" are an exception)
Samba developers considering removing SWAT Posted Feb 20, 2013 16:45 UTC (Wed) by fest3er (guest, #60379) [Link]
I'd say it's just as well. I never particularly liked SWAT and never found it particularly usable.
If a GUI control interface is needed for Samba, it should be designed from scratch, implemented anew.
Samba developers considering removing SWAT Posted Feb 20, 2013 17:04 UTC (Wed) by raven667 (subscriber, #5198) [Link]
I agree, much could be done with a new interface organized around workflow rather than the options themselves. Not necessarily a set of wizards but an interface that recognizes many of the options are inter-related and to achieve a particular effect often requires coordinated changes. It's the effects such as support for *nix clients or mutual authentication, central authentication, encryption, etc. that are important, not the individual settings that get you there.
Samba developers considering removing SWAT Posted Feb 20, 2013 19:12 UTC (Wed) by Gollum (subscriber, #25237) [Link]
"make menuconfig", perhaps?
SWAT is one of the great things about Samba Posted Feb 20, 2013 19:59 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
SWAT doesn't manage all the interactions between all actions, but it shows you what all the config options are, along with a handy help link so that you can pull up the explanation of what they mean and what values they accept (in many cases SWAT has a pull-down menu for the values)
This is incredibly valuable when configuring samba, there are so many config options that you frequently aren't gong to know where to start looking in the manual, but in swat you can just scan down the list for things that sound like they are relevant.
SWAT is one of the great things about Samba Posted Feb 21, 2013 11:16 UTC (Thu) by tonyblackwell (subscriber, #43641) [Link]
Agree SWAT is _very_ useful, a great shame to retire it without graphical replacement. Graphical environments do grow on you...
SWAT is one of the great things about Samba Posted Feb 22, 2013 4:51 UTC (Fri) by rahvin (subscriber, #16953) [Link]
I personally think they should do what they've done for awhile. Include it, disable it, and require some nasty explanations of the risk to be read to enable it.
SWAT is perfectly fine if you stick it in a secure network where the only way to access it is via an authenticated SSH tunnel or being on the local subnet. I suppose it's still vulnerable to a targeted attack on a users machine that has access but that's well beyond the scope of what they are trying to protect against. They've been warning for years not to use SWAT on a internet facing connection and you'd have to be foolish to ignore that.
|
||||||||||||||||||||||