Re: [Wikitech-l] Cross-Site-Scripting arbitrary JavaScriptexecution and HTML insertion vulnerability in the live Wikipedia.

[Brion Vibber wrote]: Yes, I hadn't looked at the code at all until after it was fixed, and I want to say thanks and kudos most especially to Rob Church for getting the fix in so quickly. Looking back at what happened, the timeline roughly went like this: 2006-06-23 13:15:59: Bug accidentally introduced by small change. 2006-06-23 19:30:00: Current SVN checked out by me. 2006-06-23 19:45:00: Test script started, and after a few minutes reports unexpected results. 2006-06-23 20:55:00: Me narrowing down the problem. 2006-06-23 20:05:00: Details sent by me to devs. 2006-06-23 20:13:57: Bug fixed and checked into SVN. So within 7 hours it was accidentally introduced, found, reported, and fixed - which I think is an amazingly quick cycle ... and of these steps, the slowest part of all was me! ;-) [Tim Starling wrote]: Whoa! Time out for a reality check. Let me say this very simply: YOU DON'T GET TO MAKE THAT DECISION. The ONLY person who gets to choose how a bug is reported is THE PERSON WHO FINDS IT. If I find a bug, then I, and only I, get to choose what to do with that information. Now, there are a very wide variety of responses to finding bugs. Some of them include: 1) Do nothing. I could find a bug, and just sit on it. I don't have to tell anybody. (For example, I never bother reporting bugs to Microsoft any more). 2) Report it to bugzilla. 3) Report it to the developers directly via email. 4) Report it to a technical mailing list about that product, with very limited or no details. 5) Report it to a technical mailing list about that product, with Proof-of-Concept code. 6) Mail it straight it to bugtraq, together with Proof-of-Concept code. 7) Post it anonymously on a script-kiddies bulletin-board. 8) Sit on it, and store up exploits until there is critical number (e.g. 10), and then combine them into some kind of MediaWiki-worm that knows how to attack all 10 exploits + change a few words / numbers in random articles, and then release it anonymously without warning at 3 PM on a Wednesday afternoon at peak server load, and then sit back and watch the resulting car crash. That's 8 possible responses, from the nice to the incredibly antisocial, from the indifferent through to the illegal. There are more responses, and of course some of the responses can be combined. But all of those responses have one thing in common: None of those decisions are made by you. Now, as a general rule I choose to do option 3 (mail the devs) for non-security related bugs, and option 3 + option 4 (mail the devs + mail a heads up to wikitech-l) for security bugs that have a working Proof-of-Concept attack. I choose to do this because I think it is most positive and constructive thing to do with that information. It gives those with the capacity to fix the problem the details they need in order to know how to fix it; and it gives those who may be affected by the problem the information to know that they will probably want to update shortly and to be wary of exploits, whilst not giving attackers the details they need to be harmful. In particular, I think mailing wikitech-l a quick email with details of which version(s) are affected, the general category of the security bug, but no specific details, is useful. The reason it is useful is because if someone chooses to run a particular tree (in spite of suggestions that they shouldn't), they will know that there is a particular type of security issue, and then they can update to keep themselves protected; Also the users of those sites can be aware of potential exploits until the problem is resolved. Last but not least, if _I_ was running an affected MediaWiki install, then I would want to know: so telling people this to me is a case of treating others how you would have them treat you. Now, if you or anyone else doesn't like those heads-up notices, then there's a simple answer: Don't read them! I don't know about you, but I get hundreds of spam emails per day, and I'm quite capable of completely ignoring them, and not reading them. So if heads-up notices about security issues in software you're involved with bother you, then don't read them. That's YOUR response, which YOU GET TO CHOOSE. Of course, in my personal opinion, the best response is probably sending a reply like this to wikitech-l: ------------------------------------- Thank you for your MediaWiki bug report. We believe the issue that you reported has now been fixed in SVN revision 14990 http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-June/015970.html ). Updated releases of the stable tree are released periodically as tarballs, and release announcements are sent to the MediaWiki-announce mailing list. Current snapshots of the development tree can be grabbed by doing an svn checkout/update of the current development source code. Thank you for your report and for helping us to make MediaWiki even better. ------------------------------------- Sending that to wikitech-l in response to a security heads-up on the same list gets you several things: 1) It acknowledges that you got the original bug report. 2) It confirms that there was a problem. 3) It tells everyone that the problem is now fixed. 4) It sends the clear message that "this software is well maintained and we respond promptly to security issues". 5) It tells any affected site admins which release / version they need to update to order to be protected from the problem. 6) It thanks the reporter - because although you mightn't realise it, finding these types of problems can be hard work, and a little thanks never goes astray. [Tim Starling wrote]: I shall be happy to email yourself and Brion an updated version of the script that I'm using (you'll have to check it in, as I don't have commit privileges). I'll endeavour to get it you today, but failing that some time this week. As with all software I'm sure it can be improved, but it's probably better to have something more current checked in to the tree than the old version that is there currently. Please note however that the script mightn't be quite what you think it is: For example, I didn't have a test for this specific IpBlockList problem ready to go just waiting for this exact problem. Rather I had a script that generates tests, runs those tests, and if it fails keeps the tests. So I ran it for a few minutes, it generated a specific IpBlockList test that failed, and then I took a closer look at the generated test that failed, and said "Oh, that's interesting". So it's a test generator and runner and result-checker, not a set of predefined static tests. As such, as a constructive suggestion, one possibility might be to add a cronjob similar to how parserTests gets run nightly and the results are mailed to wikitech-l. Currently the script runs until stopped with CTRL-C, and it prints out progress information as it goes. So as a possibility, you could perhaps update it to accept some command line parameters (such as adding a silent mode that only prints out real errors to make it less chatty, and adding something so that you could specify to run for a specific amount of time [e.g. 1 hour] instead of indefinitely, and maybe also a maximum number of errors to report). Then the resulting nightly output could be emailed to wikitech-l, or you could set up a separate private mail alias if you wanted (I'd be happy to be included on this, as it may or may not require some explaining at first about what it's upset about, and it might require a bit of tweaking to get the right level of information from the script). That way you'd get an additional different and complementary type of continuous nightly testing to help catch any regressions or other problems. All the best, Nick.