From: mose <mo...@ti...> - 2006-07-15 07:42:20
|
le Fri, Jul 14, 2006 at 04:07:24PM -0700 par Chris Finley : > Marcus Better wrote: > > Gunnar Ren=E9 =D8ie wrote: > >=20 > >>http://tikiwiki.org/tiki-index.php does list what has been done, > >=20 > >=20 > > Not really. Skimming through unrelated news announcement to find the = one > > about a security fix, which says only=20 > > "This release fixes a recently declared XSS vulnerability." > > is simply not good enough. > >=20 > > Even > > http://tikiwiki.org/tiki-index.php?page=3DTikiSecurity&bl > > is mostly a clipboard of information of varying relevance, although i= t is a > > good start. > >=20 > > Sorry if I sound a bit negative, but I do think the problem is import= ant and > > can be fixed easily with the proper procedures. (I'm trying to get Ti= kiwiki > > uploaded to Debian, and people are raising concerns about this issue.= ) > >=20 >=20 >=20 > I have been told that I cannot find out about security bugs before they > are fixed, but I should be able to get some information afterwards. Is > there a page for this or mailing list for sys admins? >=20 > I agree with Marcus, we need more than "upgrade to 1.9.4 because it > contains security fixes". >=20 > For one, this feels like blackmail. It takes a great deal of time to > safely upgrade our TikiWiki, apply our customizations and test the whol= e > thing. If I can get the fix, that can be applied within a few hours. >=20 > The TikiWiki for Debian is a great project (I use Debian, naturally :) > You may find some problems with the "upgrade or be unsecure" philosophy= . > To keep packages stable, security fixes are backported to minimize th= e > chance of a new feature breaking someone production server. > Additionally, new features must hang around in "unstable" and the > "testing" for a while. Bug fixes can be fast-tracked, but they are not > suppose to contain new features. >=20 > Please consider a mailing list for security fixes or adding fix > information to the change log (or even security change log). - I understand your concern, so here is the whole story, so you can understand mine (as I'm often the one that runs when there is a security alert). We had several steps of security improvements in the past. When first alerts occured, we spreaded around all information for everybody with every details about how to fix, but also, naturally, how to exploit flaws. What happened is that it resulted in a massive attack on non-upgraded tikis, because kiddies are faster than webmasters, they are subscribed on security mailing-lists, and get more interest in security than actual normal webmaster-users. In 2005 I had to run a security watch, which was more or less following the tracks of kiddies, scanning tikis all around, after collecting urls from various search engine (and from tw.o referers in apache logs). see http://tikiwiki.org/watch.html My script was a sortof white-hat horse, that was using flaws to fix them, when possible. I exploited security flaw to heal more than 300 websites, sending notices to healed sites and advising a fast upgrade. At view on stats of versions of tikiwiki instances I met during that watch, I noticed that upgrade was not done very fast on most sites. Kids are faster than web maintainers. So now I'm not very keen to publish too much information about how to exploit flaws. People that are willing to exploit them are more motivated than people that should fix them at home. I personaly don't think obscurity is good in any way. But for the specific case of the tikiwiki user community, I had to adapt my position.=20 We have a mail alias sec...@ti... gathering trusted long-time tikiwiki developers. We get from time to time security alerts on it,=20 from which some are not even published on http://securityfocus.com or other places like that. When we get such alerts, the priority is to provide a fix and release a new version of tikiwiki. I agree that it's not a perfect situation, as you point out, some advanced platforms maintainers should be able to adapt the fixes to their own customization of tikiwiki. But publishing detailled information has good effect for some, and really bad effect for most. So I consider it's a 'less worse' choice.=20 But, I may be wrong, or maybe there are better solutions to that context and maybe I should let someone else manage security issues another way.=20 Comments are welcome. cheers, mose |