Hi All,
There is a Cross-Site-Scripting user-specified arbitrary JavaScript and HTML injection vulnerability in MediaWiki.
This differs from the XSS vuln noted earlier this month, but the basic concept is the same: malicious data is injected into a specific value which is not sanitized / escaped before being echoed back to the user's browser.
Please note that MediaWiki 1.6 (current stable) does NOT appear to be affected. However current SVN and the live Wikipedia are affected by this vulnerability.
No extension need to be installed, and the user does not need to be logged in.
Proof-of-Concept details have been emailed to Brion / Tim / Rob Church; These details will be released to the public on http://nickj.org/MediaWiki after a suitable delay.
All the best, Nick.
Nick Jenkins wrote:
Please note that MediaWiki 1.6 (current stable) does NOT appear to be affected. However current SVN and the live Wikipedia are affected by this vulnerability.
As I understand it, this was fixed a few hours ago, and was present for just a few hours before that; so if you updated from SVN trunk in the last day, make sure you update again. :)
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Nick Jenkins wrote:
Please note that MediaWiki 1.6 (current stable) does NOT appear to be affected. However current SVN and the live Wikipedia are affected by this vulnerability.
As I understand it, this was fixed a few hours ago, and was present for just a few hours before that; so if you updated from SVN trunk in the last day, make sure you update again. :)
This sort of thing really doesn't need to be reported to wikitech-l. There are transient bugs in the trunk all the time, we make no guarantee about its security or stability. Any security problem on Wikipedia can be fixed in a few minutes by reporting it by private message on IRC.
-- Tim Starling
I wrote:
This sort of thing really doesn't need to be reported to wikitech-l. There are transient bugs in the trunk all the time, we make no guarantee about its security or stability. Any security problem on Wikipedia can be fixed in a few minutes by reporting it by private message on IRC.
Further to that, I would appreciate it if Nick would commit his testing scripts to SVN, and document them fully. It would be easier if we could do this testing before we commit, rather than go through all this rigmarole.
-- Tim Starling
[Brion Vibber wrote]:
As I understand it, this was fixed a few hours ago, and was present for just a few hours before that; so if you updated from SVN trunk in the last day, make sure you update again. :)
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]:
This sort of thing really doesn't need to be reported to wikitech-l.
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]:
Further to that, I would appreciate it if Nick would commit his testing scripts to SVN, and document them fully. It would be easier if we could do this testing before we commit, rather than go through all this rigmarole.
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.
Nick Jenkins wrote:
[Tim Starling wrote]:
This sort of thing really doesn't need to be reported to wikitech-l.
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.
No shit, Sherlock. You have the ability to choose how you behave. You can throw rocks through windows or cry when you don't get your way, or whatever you feel like doing. I'm only suggesting that you have some consideration when you choose your path.
Whenvever you post one of these "OMFG security flaw" posts to a public mailing list, it damages the reputation of MediaWiki as a secure and stable wiki engine. These posts will be archived and available in the search engines forever. Some people are going to search for "mediawiki security" on google and judge it by what they find.
What we would like is for MediaWiki to be judged by the reliability of its release versions, not whatever happens to be at the head of the trunk in any particular second.
Now as you rightly point out, you are free to make these posts. But that doesn't mean you're going to make any friends by doing it. Yes, you are free to annoy as many people as you like, but I think you will find that to be a bitter and unfulfilling path to take in life.
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.
I'm sure we can arrange commit access for you.
-- Tim Starling
On 26/06/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
Whenvever you post one of these "OMFG security flaw" posts to a public mailing list, it damages the reputation of MediaWiki as a secure and stable wiki engine. These posts will be archived and available in the search engines forever. Some people are going to search for "mediawiki security" on google and judge it by what they find.
*cough* And people are going to spot these arguments in the public archive, too. Who was it who asked us all to be decent to people; those we knew, and those we didn't? Common sense, to me.
What we would like is for MediaWiki to be judged by the reliability of its release versions, not whatever happens to be at the head of the trunk in any particular second.
I'd tend to agree, although since we're using Subversion trunk in production on a popular web site, it is, of course, prudent for us to keep it secure against known issues. :)
Might I suggest that Nick continues to (very kindly) advise us in advance of security issues, as he has been doing, via the private channels (emailing two or three of us, or using the security@wikimedia alias; whatever), but holds back on announcing stuff to wikitech-l for an hour or so, and doesn't bother announcing bugs in Subversion trunk that are fixed up?
This means that:
* we still get fair warning of stuff we need to fix * people aren't alerted and panicked and misled when there's little cause for alarm * people *are* given fair notice of problems in the "stable" branch
I'm sure we can arrange commit access for you.
Sounds like a sensible idea to me; he's not going to go off breaking stuff, we can sorta guess that, and we'll benefit from having a bit more testing stuff. :)
Rob Church
Tim Starling wrote:
No shit, Sherlock. [...] I'm only suggesting that you have some consideration when you choose your path.
If you read his posting in its entirety, you will notice that he has actually put a heck of a lot of consideration into this particular decision, *and* he has even gone for the trouble of writing it all up for *your* benefit. You are being very ungrateful in my opinion.
Whenvever you post one of these "OMFG security flaw" posts to a public mailing list, it damages the reputation of MediaWiki as a secure and stable wiki engine.
OMFG my holy and sacred MediaWiki! It is the most secure and stable in the universe and anyone who doubts it is a heretic and must be burnt at the stake!
Seriously, security flaws need to be pointed out. *Especially* in open-source software.
Timwi
On Mon, Jun 26, 2006 at 07:35:00PM +0100, Timwi wrote:
Seriously, security flaws need to be pointed out. *Especially* in open-source software.
One of the big problems I have with a lot of proprietary software is the unwillingness of its vendor to admit flaws and tell us, the users, that there's a problem of which we should be aware. I tend to view open and frank, helpful discussion of security issues to be a net win when I'm evaluating software to determine whether I want to use it, and ominous silences as a sign that if a vulnerability arises, I won't find out until it's too late.
On Mon, Jun 26, 2006 at 01:09:42PM -0600, Chad Perrin wrote:
On Mon, Jun 26, 2006 at 07:35:00PM +0100, Timwi wrote:
Seriously, security flaws need to be pointed out. *Especially* in open-source software.
One of the big problems I have with a lot of proprietary software is the unwillingness of its vendor to admit flaws and tell us, the users, that there's a problem of which we should be aware. I tend to view open and frank, helpful discussion of security issues to be a net win when I'm evaluating software to determine whether I want to use it, and ominous silences as a sign that if a vulnerability arises, I won't find out until it's too late.
And, FWIW, while I think there's a whole lot of overreaction on this thread, on both sides, I come down a bit right of center as well: I believe that it would be useful to have it documented in the archives that there *was* such a problem, at timestamp X, such that if someone is using SVN and happened to pull that particular rev, they have the opportunity to know.
Remember: while running SVN revs in production is not the recommended approach, there are people who do it.
Cheers, -- jra
On 27/06/06, Jay R. Ashworth jra@baylink.com wrote:
Remember: while running SVN revs in production is not the recommended approach, there are people who do it.
*snigger*
Rob Church
On Tue, Jun 27, 2006 at 03:03:14PM +0100, Rob Church wrote:
On 27/06/06, Jay R. Ashworth jra@baylink.com wrote:
Remember: while running SVN revs in production is not the recommended approach, there are people who do it.
*snigger*
/me bows
Cheers, -- jr 'I'm not one of them, of course...' a
On 26/06/06, Nick Jenkins nickpj@gmail.com 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.
I suppose it's time to cough to the fact that I was at fault in the first place? :(
Rob Church
On 26/06/06, Domas Mituzas midom.lists@gmail.com wrote:
I suppose it's time to cough to the fact that I was at fault in the first place? :(
You were not at fault. You were the fault!
*sob* I blame it on E numbers and Doctor Who! Damn those TARDISes and their oh-so-alluring world without htmlspecialchars().
I must rush to the nearest blog and spend a whole hour composing four sentences, PACKED with emo!!!11!one.
Rob Church
These posts will be archived and available in the search engines forever. Some people are going to search for "mediawiki security" on google and judge it by what they find.
Some keyword hits: mediawiki security analysis, personal independent mediawiki security summary.
Dear future google reader:
Before you judge too quickly, please let me say this: Mediawiki seems pretty secure to me. Finding security bugs in the MediaWiki software is hard. Every bug I have found, I have reported (over 50 at last count, only a proportion of which were security related, and of those only 4 were confirmed exploitable). However you should not be alarmed by these numbers, because I am actively trying to break this software in whacky ways, and you won't be. When I report bugs to the developers, they fix security bugs usually within the hour, and they fix general bugs usually within a few days. This is very quick, and it indicates this software is actively being maintained and improved. I am happy to use this software myself for my personal website, and I would not be afraid to use MediaWiki as a general knowledge & collaboration repository on the Internet or an intranet. However, I would suggest not using it to store your bank details or credit card details or suchlike. Later versions always seem more robust than earlier versions to me, so you should try to run the latest stable version if you can. Do not use the development version in subversion unless you are willing to keep up-to-date, because it is always under active development.
Overall, as a potential user, you should feel good about the fact that someone has tried to break this software. It's a definite plus. That might seem paradoxical, because you may feel concerned that bugs may be found. However, that's the wrong attitude: Good software (such as OpenSSH, Linux, apache) has had people systematically trying to break it, and developers actively fixing the stuff they find. For best results, both ingredients are required (breakers & fixers). This software has that. Understand that all software has bugs. Anyone who says otherwise is probably trying to sell you something. But every bug that gets found and fixed is one less bug that you have to worry about. In my opinion, you should be wary of software that has not gone through such a process, because it's probably less secure that it first appears, whilst software that has gone through this process is more secure than it first appears. Bugs generally persist until removed: the only question is whether someone has gone looking for them.
Might I suggest that Nick continues to (very kindly) advise us in advance of security issues, as he has been doing, via the private channels (emailing two or three of us, or using the security at Wikimedia alias; whatever), but holds back on announcing stuff to Wikitech-l for an hour or so, and doesn't bother announcing bugs in Subversion trunk that are fixed up?
That sounds fine, and I happily agree. It seems a reasonable balance to me.
I suppose it's time to cough to the fact that I was at fault in the first place? :(
Don't worry about it, it's an extremely easy thing to miss. It's also partially the name of the variable, $ip, and its implications, as we expect IP addresses to be things like "12.34.56.32", and we simply don't expect an IP address to contain things like '"><script>'.
All the best, Nick.
On 26/06/06, Nick Jenkins nickpj@gmail.com wrote:
Don't worry about it, it's an extremely easy thing to miss. It's also partially the name of the variable, $ip, and its implications, as we expect IP addresses to be things like "12.34.56.32", and we simply don't expect an IP address to contain things like '"><script>'.
No, I should know better; what caused it was damn confusion over the bloody wfMsg* functions. I forgot that wfMsgWikiHtml() doesn't escape parameters.
Rob Church
You're doing a good work, Nick. Bug exploiting is not an easy way, and you've caught quite a lot for the time you've being hunting them. Personally, i *do* like knowing that. It would be much worse if i knew them on option 8! I personally understand you wanting to be on such security-risk mail list ;-) If i tried to figure out from your reports here where the security hole was, it'd probably be fixed when i could begin to _see_ it.
"Nick Jenkins" wrote:
[Brion Vibber wrote]:
As I understand it, this was fixed a few hours ago, and was present for just a few hours before that; so if you updated from SVN trunk in the last day, make sure you update again. :)
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]:
This sort of thing really doesn't need to be reported to wikitech-l.
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:
- 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:
- It acknowledges that you got the original bug report.
- It confirms that there was a problem.
- It tells everyone that the problem is now fixed.
- 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]:
Further to that, I would appreciate it if Nick would commit his testing scripts to SVN, and document them fully. It would be easier if we could do this testing before we commit, rather than go through all this rigmarole.
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.
wikitech-l@lists.wikimedia.org