On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs thekohser@gmail.com wrote:
I was sort of surprised to learn today that Mediawiki software has had 37 security holes identified:
http://akahele.org/2009/09/false-sense-of-security/
Are most of these patched now, or are they still open? If still open, is the Foundation making site & user security more of a priority in 2010?
-- Gregory Kohs _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
I'm pretty sure a lot of this has been fixed (I vaguely remember Tim doing some cleanup to the installer for XSS issues), but I can't say for sure. Forwarding to wikitech-l, this is more of a tech issue than Foundation one.
-Chad
2009/9/15 Chad innocentkiller@gmail.com:
On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs thekohser@gmail.com wrote:
I was sort of surprised to learn today that Mediawiki software has had 37 security holes identified:
http://akahele.org/2009/09/false-sense-of-security/
Are most of these patched now, or are they still open? If still open, is the Foundation making site & user security more of a priority in 2010?
-- Gregory Kohs _______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
I'm pretty sure a lot of this has been fixed (I vaguely remember Tim doing some cleanup to the installer for XSS issues), but I can't say for sure. Forwarding to wikitech-l, this is more of a tech issue than Foundation one.
This has been addressed on foundation-l already, but I'll make it extra clear here: all these vulnerabilities reported by these database are only in there because we discovered, fixed and reported them first. The affected versions of MediaWiki range from old to stone-age.
Roan Kattouw (Catrope)
On Tue, Sep 15, 2009 at 2:21 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
This has been addressed on foundation-l already, but I'll make it extra clear here: all these vulnerabilities reported by these database are only in there because we discovered, fixed and reported them first. The affected versions of MediaWiki range from old to stone-age.
That's not quite fair. We had a Special:Block XSS problem just two months ago:
https://bugzilla.wikimedia.org/show_bug.cgi?id=19693
XSS is our major problem, as with most web apps. It's hard to defend against comprehensively. Unlike some other web apps, we have almost no SQL injections, and MediaWiki XSS is typically impossible to elevate to arbitrary server-side code execution. So MediaWiki's security is pretty good but not perfect. Compare to WordPress, where if you don't keep up-to-date you can get your server taken over and used to send spam (this has been happening recently, I've heard). Not only is that worse for you, it's much more profitable for attackers, so you're likely to see more widespread automatic exploitation. I haven't heard of widespread exploitation of any MW security vulnerability, although it's possible it's happened. Fairly high-profile wikis like wikileaks.org are running extremely outdated software with multiple known vulnerabilities and seem not to have been hacked. (In the case of Wikileaks, it seems to be based on something around 1.9 or 1.10, although maybe they manually patched the known unpatched XSS in those.)
The most promising systematic XSS mitigation for the future looks to be client-side. Newer browsers are beginning to automatically try detecting whether HTML from GET parameters is being injected, and stop it if so. At least Chrome and IE have or are introducing something of this nature, IIRC. Mozilla's CSP is a more comprehensive way to address XSS, but much more difficult to use as well. It will be interesting to see if XSS eventually becomes a minor issue, but for now it's very hard for any big web app *not* to have some XSS vulnerabilities. You can only patch them as fast as possible when reported.
"AG" == Aryeh Gregor Simetrical+wikilist@gmail.com writes:
AG> Compare to WordPress, where if you don't keep up-to-date you can get AG> your server taken over and used to send spam
Mediawiki/Wordpress is like Linux/Microsoft. It will always be an uphill battle to keep WordPress secure. Never content to just answer HTTP requests, install it and it immediately starts making HTTP requests of its own, etc.
On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs thekohser@gmail.com wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities; I can only assume the author meant that the software has _had_ more than its share of vulnerabilities. Even still, that seems like a made-up claim: I suspect that a quantitative study would show that MediaWiki has actually had fewer security vulnerabilities than comparable software (and that's not even counting the disparity in severity/exploitability that Aryeh notes). WordPress, for instane, has 183 entries on the NVD; phpBB has 240. (Analysis using the NVD is somewhat unfair, since it seems to make no distinction between the core software and extensions or derivatives. It's also unclear how comprehensive the NVD is, given that they don't have an entry for the XSS vulnerability Aryeh mentioned.)
Beyond that, I think the article misses the point of open source as regards security. Open source development doesn't automatically prevent holes from appearing (though it can, since code will have more eyes on it before it's deployed); it makes it easier to identify and patch them. Of course, it would be difficult to compare the number of vulnerabilities in open-source software to that in closed-source software, since open-source software developers usually try to publicize vulnerabilities as much as possible, while closed-source software developers usually want to avoid disclosing vulnerabilities.
On Tue, Sep 15, 2009 at 5:12 PM, Aryeh Gregor < Simetrical+wikilist@gmail.com Simetrical%2Bwikilist@gmail.com> wrote:
Compare to WordPress, where if you don't keep up-to-date you can get your server taken over and used to send spam (this has been happening recently, I've heard). Not only is that worse for you, it's much more profitable for attackers, so you're likely to see more widespread automatic exploitation. I haven't heard of widespread exploitation of any MW security vulnerability, although it's possible it's happened.
I haven't even heard of _isolated_ exploitation of MediaWiki security holes, let alone anything widespread. Aren't most MW vulnerabilities discovered through audits, code review, or third-party reporting, rather than demonstrated exploitation?
On Tue, Sep 15, 2009 at 6:36 PM, Benjamin Lees emufarmers@gmail.com wrote:
On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs thekohser@gmail.com wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities
There are. You didn't want us to describe them in our article, did you?
On 15/09/2009, at 11:40 PM, Anthony wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities
There are. You didn't want us to describe them in our article, did you?
I think the appropriate expression here is "put up or shut up".
If you are aware of unpatched security vulnerabilities in MediaWiki, report them to security@wikimedia.org, and to this list if you don't receive a response, and they will be immediately patched.
Otherwise, please stop spreading unsubstantiated FUD.
-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/
On Tue, Sep 15, 2009 at 7:17 PM, Andrew Garrett agarrett@wikimedia.orgwrote:
On 15/09/2009, at 11:40 PM, Anthony wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities
There are. You didn't want us to describe them in our article, did you?
I think the appropriate expression here is "put up or shut up".
If you are aware of unpatched security vulnerabilities in MediaWiki, report them to security@wikimedia.org, and to this list if you don't receive a response, and they will be immediately patched.
If you want to offer some sort of bounty program, then maybe. Otherwise, no thanks.
On Tue, Sep 15, 2009 at 7:26 PM, Anthony wikimail@inbox.org wrote:
On Tue, Sep 15, 2009 at 7:17 PM, Andrew Garrett agarrett@wikimedia.orgwrote:
On 15/09/2009, at 11:40 PM, Anthony wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities
There are. You didn't want us to describe them in our article, did you?
I think the appropriate expression here is "put up or shut up".
If you are aware of unpatched security vulnerabilities in MediaWiki, report them to security@wikimedia.org, and to this list if you don't receive a response, and they will be immediately patched.
If you want to offer some sort of bounty program, then maybe. Otherwise, no thanks. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well thankfully the majority of 3rd party users have a better feeling about reporting bugs when they find them.
-Chad
On Tue, Sep 15, 2009 at 7:33 PM, Chad innocentkiller@gmail.com wrote:
Well thankfully the majority of 3rd party users have a better feeling about reporting bugs when they find them.
I'm not sure where you got the statistics for that statement, but hey, you should publicize it. "Mediawiki - more than half of discovered vulnerabilities are fixed!"
On Tue, Sep 15, 2009 at 4:40 PM, Anthony wikimail@inbox.org wrote:
On Tue, Sep 15, 2009 at 7:33 PM, Chad innocentkiller@gmail.com wrote:
Well thankfully the majority of 3rd party users have a better feeling about reporting bugs when they find them.
I'm not sure where you got the statistics for that statement, but hey, you should publicize it. "Mediawiki - more than half of discovered vulnerabilities are fixed!"
Anthony, that was uncalled for. Nobody has suggested that identified bugs aren't fixed. Nobody has suggested that reported bugs aren't fixed.
You are under no legal responsibility to report new bugs you may be aware of, but if you claim to have any interest in the Wikimedia / Wikipedia communities you should have a moral responsibility to do so. Commercial vendors that charge for software may, at their discretion, offer bug bounties - that's normal. Asking open source developers for bounties is not moral or ethical - there's no fee for using the software, why ask for a fee for helping improve it by reporting bugs?
We can't make you do it, but you should. If you won't, perhaps you should just drop off the project membership emails and find something else to do - someone sitting here on these lists taunting "I know about bugs that you don't", if persistent, would be a gross violation of etiquette.
On Tue, Sep 15, 2009 at 7:49 PM, George Herbert george.herbert@gmail.comwrote:
On Tue, Sep 15, 2009 at 4:40 PM, Anthony wikimail@inbox.org wrote:
On Tue, Sep 15, 2009 at 7:33 PM, Chad innocentkiller@gmail.com wrote:
Well thankfully the majority of 3rd party users have a better feeling about reporting bugs when they find them.
I'm not sure where you got the statistics for that statement, but hey,
you
should publicize it. "Mediawiki - more than half of discovered vulnerabilities are fixed!"
Anthony, that was uncalled for. Nobody has suggested that identified bugs aren't fixed.
I have.
Nobody has suggested that reported bugs aren't fixed.
I've seen instances of that as well. Not something I feel I should publicize, but if you look on this very list you'll see instances of serious bugs which are reported and aren't fixed.
You are under no legal responsibility to report new bugs you may be
aware of, but if you claim to have any interest in the Wikimedia / Wikipedia communities you should have a moral responsibility to do so.
In the case of these particular bugs, no, I have no interest in seeing them fixed, at least not at the present time.
Commercial vendors that charge for software may, at their discretion,
offer bug bounties - that's normal. Asking open source developers for bounties is not moral or ethical - there's no fee for using the software, why ask for a fee for helping improve it by reporting bugs?
I don't see anything immoral or unethical about asking. And I see nothing immoral or unethical about withholding information about them. It would be immoral if I exploited them, or if I told other people how to exploit them without first telling the WMF, but not if I simply sit on the information and do nothing about it.
Why ask for a fee? Why does anyone ask for a fee for anything? Because I might get it. I also think it would have been incomplete for me to have simply answered with "No thanks."
We can't make you do it, but you should. If you won't, perhaps you
should just drop off the project membership emails and find something else to do - someone sitting here on these lists taunting "I know about bugs that you don't", if persistent, would be a gross violation of etiquette.
I only brought it up because someone implied that the organization I am a member of was publishing lies.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Anthony wrote:
On Tue, Sep 15, 2009 at 7:33 PM, Chad innocentkiller@gmail.com wrote:
Well thankfully the majority of 3rd party users have a better feeling about reporting bugs when they find them.
I'm not sure where you got the statistics for that statement, but hey, you should publicize it. "Mediawiki - more than half of discovered vulnerabilities are fixed!"
I like this one a bit better:
"Mediawiki - caring more about fixing bugs then profiting from them!"
On Tue, Sep 15, 2009 at 7:40 PM, Anthony wikimail@inbox.org wrote:
On Tue, Sep 15, 2009 at 7:33 PM, Chad innocentkiller@gmail.com wrote:
Well thankfully the majority of 3rd party users have a better feeling about reporting bugs when they find them.
I'm not sure where you got the statistics for that statement, but hey, you should publicize it. "Mediawiki - more than half of discovered vulnerabilities are fixed!" _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Statistics have absolutely nothing to do with what I said, you're missing the /entire/ point.
-Chad
On Tue, Sep 15, 2009 at 5:26 PM, Anthony wikimail@inbox.org wrote:
On Tue, Sep 15, 2009 at 7:17 PM, Andrew Garrett <agarrett@wikimedia.org
wrote:
On 15/09/2009, at 11:40 PM, Anthony wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities
There are. You didn't want us to describe them in our article, did you?
I think the appropriate expression here is "put up or shut up".
If you are aware of unpatched security vulnerabilities in MediaWiki, report them to security@wikimedia.org, and to this list if you don't receive a response, and they will be immediately patched.
If you want to offer some sort of bounty program, then maybe. Otherwise, no thanks.
This is quite possibly the slimiest thing I've ever read on these lists.
On Wed, Sep 16, 2009 at 9:26 AM, Anthony wikimail@inbox.org wrote:
On Tue, Sep 15, 2009 at 7:17 PM, Andrew Garrett agarrett@wikimedia.orgwrote:
I think the appropriate expression here is "put up or shut up".
If you are aware of unpatched security vulnerabilities in MediaWiki, report them to security@wikimedia.org, and to this list if you don't receive a response, and they will be immediately patched.
If you want to offer some sort of bounty program, then maybe. Otherwise, no thanks.
If you don't believe in responsible disclosure of attacks without being paid, perhaps you will at least publicly disclose the problem.
If you do neither, you're well on your way to being a bottom-feeder.
-- John Vandenberg
On Tue, Sep 15, 2009 at 6:40 PM, Anthony wikimail@inbox.org wrote:
There are. You didn't want us to describe them in our article, did you?
All nontrivial software has unknown security vulnerabilities. The most anyone can realistically ask is that there are as few vulnerabilities discovered as possible, and that they're patched as quickly as possible when that happens. I'm not aware of any reason to believe the MediaWiki is unusually lacking in that respect.
I'm not going to join the people who are saying that refusing to disclose vulnerabilities without payment is unethical per se. Security researchers need to eat as well. I won't comment on whether I think you actually do know about any serious vulnerabilities -- it's both impossible to prove either way, and irrelevant to this list.
I do think we could use improvement in our procedure to respond to security problems. I've had the experience of sending mail to security@wikimedia.org about XSS in the Timeline extension, and having it ignored for a couple of weeks until I pestered the appropriate people on IRC to fix it. Where does that go? Does it just forward to Tim and Brion? It should probably raise alarm bells somewhere and cause someone to be immediately assigned to look into it, but that doesn't appear to happen.
It should be noted, though, that actual demonstrated risk is probably more important to users than theoretical patch response times. For whatever reason, attacks on MediaWiki seem to be comparatively rare. I would be interested in hearing of any real-world attacks anyone knows of -- there must have been *some*, but I've never heard of one.
On Wed, Sep 16, 2009 at 11:14 AM, Aryeh Gregor < Simetrical+wikilist@gmail.com Simetrical%2Bwikilist@gmail.com> wrote:
On Tue, Sep 15, 2009 at 6:40 PM, Anthony wikimail@inbox.org wrote:
There are. You didn't want us to describe them in our article, did you?
All nontrivial software has unknown security vulnerabilities.
Fine, I'm willing to leave it at that. I just felt the need to defend Judd (and, as a board member of the non-profit which published the blog article, myself) against a claim of lying in a blog post.
It should be noted, though, that actual demonstrated risk is probably more important to users than theoretical patch response times. For whatever reason, attacks on MediaWiki seem to be comparatively rare.
I think the "soft security" model is oftentimes a good one. It certainly blurs the lines between what is a "security breach" and what is vandalism, and gives the script kiddies something to do which doesn't constitute a true security breach.
I would be interested in hearing of any real-world attacks anyone knows of -- there must have been *some*, but I've never heard of one.
The only one I can think of that I know of directly would be the IP spoofing one where the attacker pretended to be a proxy and sent a false "IP forwarded" or whatever.
But indirectly I know of many "Grawp" exploits. I guess I know of one of those directly, which is whatever I got hit with on my Mediawiki installation. I never investigated what specifically it was, though.
There's also various forms of nasty once-upon-a-time unrecoverable vandalism like moving a page on top of another which arguably aren't security holes but arguably *are* security holes in the form of design flaws.
On Wed, Sep 16, 2009 at 11:29 AM, Anthony wikimail@inbox.org wrote:
The only one I can think of that I know of directly would be the IP spoofing one where the attacker pretended to be a proxy and sent a false "IP forwarded" or whatever.
That shouldn't work if MediaWiki is configured with a correct list of trusted proxies.
But indirectly I know of many "Grawp" exploits. I guess I know of one of those directly, which is whatever I got hit with on my Mediawiki installation. I never investigated what specifically it was, though.
What were the consequences?
There's also various forms of nasty once-upon-a-time unrecoverable vandalism like moving a page on top of another which arguably aren't security holes but arguably *are* security holes in the form of design flaws.
You can become admin via XSS (or password guessing, MITM, etc.), and move a page over a deleted page, where both have lots of history, then undelete. But 1) that's only really a problem on wikis large enough to have huge histories; 2) it's still reversible, just requires a lot of tedious manual effort or maybe some carefully written queries; and 3) if you can't be bothered to reverse it, you could just copy out the couple hundred most recent revisions and leave the others mixed together, it's not really critical that the old ones are still missing. So it's not a huge deal. There are probably some DOSes you can do as an admin as well; and you could inject arbitrary JavaScript on all page views.
But this is all pretty easy to detect and not terribly hard to reverse. The JS injection is potentially the most damaging, but if the wiki is on its own domain, the worst you could do is stealing some IP addresses, and phishing. Compare to most web software, where if you become admin you can at *least* irrecoverably delete the whole site in a few clicks, and possibly run arbitrary code on the server -- and in the latter case you can almost certainly cover your tracks pretty well, too. So I think we're not doing too badly.
On 16/09/2009, at 4:48 PM, Aryeh Gregor wrote:
On Wed, Sep 16, 2009 at 11:29 AM, Anthony wikimail@inbox.org wrote:
The only one I can think of that I know of directly would be the IP spoofing one where the attacker pretended to be a proxy and sent a false "IP forwarded" or whatever.
That shouldn't work if MediaWiki is configured with a correct list of trusted proxies.
We were checking $_SERVER['X_FORWARDED_FOR'], which reads the X- Forwarded-For header. Unfortunately, it could be overridden by sending an X_Forwarded_For header.
We resolved it by using the apache-specific header retrieval functions instead of PHP's broken internal implementation.
-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/
Andrew Garrett wrote:
On 16/09/2009, at 4:48 PM, Aryeh Gregor wrote:
On Wed, Sep 16, 2009 at 11:29 AM, Anthony wikimail@inbox.org wrote:
The only one I can think of that I know of directly would be the IP spoofing one where the attacker pretended to be a proxy and sent a false "IP forwarded" or whatever.
That shouldn't work if MediaWiki is configured with a correct list of trusted proxies.
We were checking $_SERVER['X_FORWARDED_FOR'], which reads the X- Forwarded-For header. Unfortunately, it could be overridden by sending an X_Forwarded_For header.
We resolved it by using the apache-specific header retrieval functions instead of PHP's broken internal implementation.
The attack documentation: http://en.wikipedia.org/wiki/User:Brion_VIBBER/Cool_Cat_incident_report
Andrew Garrett wrote:
We were checking $_SERVER['X_FORWARDED_FOR'], which reads the X- Forwarded-For header. Unfortunately, it could be overridden by sending an X_Forwarded_For header.
We resolved it by using the apache-specific header retrieval functions instead of PHP's broken internal implementation.
It's not PHP's fault. The HTTP_* environment variables are part of the CGI standard, which provides no way to distinguish between X-Forwarded-For and x_forwarded_for.
http://hoohoo.ncsa.illinois.edu/cgi/env.html#headers
So really it's NCSA's fault for inventing such a broken protocol, and Apache's fault for implementing it. There's not much PHP can do at that point, apart from implementing SAPI-specific workarounds, which is what they did.
-- Tim Starling
2009/9/16 Aryeh Gregor Simetrical+wikilist@gmail.com:
It should be noted, though, that actual demonstrated risk is probably more important to users than theoretical patch response times. For whatever reason, attacks on MediaWiki seem to be comparatively rare. I would be interested in hearing of any real-world attacks anyone knows of -- there must have been *some*, but I've never heard of one.
There was a whacky one a few years ago where one user could spoof another user's IP as far as MediaWiki was concerned, i.e. so that edits by the first users would be attributed in the database as belonging to the second user. I believe that was fixed quick-smart ...
- d.
On Tue, Sep 15, 2009 at 6:36 PM, Benjamin Lees emufarmers@gmail.com wrote:
On Tue, Sep 15, 2009 at 1:38 PM, Gregory Kohs thekohser@gmail.com wrote:
My favorite part of that article: "Even the open source MediaWiki software has more than its fair share of security vulnerabilities." As written, this suggests that there are unpatched security vulnerabilities; I can only assume the author meant that the software has _had_ more than its share of vulnerabilities. Even still, that seems like a made-up claim: I suspect that a quantitative study would show that MediaWiki has actually had fewer security vulnerabilities than comparable software (and that's not even counting the disparity in severity/exploitability that Aryeh notes). WordPress, for instane, has 183 entries on the NVD; phpBB has 240. (Analysis using the NVD is somewhat unfair, since it seems to make no distinction between the core software and extensions or derivatives. It's also unclear how comprehensive the NVD is, given that they don't have an entry for the XSS vulnerability Aryeh mentioned.)
Beyond that, I think the article misses the point of open source as regards security. Open source development doesn't automatically prevent holes from appearing (though it can, since code will have more eyes on it before it's deployed); it makes it easier to identify and patch them. Of course, it would be difficult to compare the number of vulnerabilities in open-source software to that in closed-source software, since open-source software developers usually try to publicize vulnerabilities as much as possible, while closed-source software developers usually want to avoid disclosing vulnerabilities.
On Tue, Sep 15, 2009 at 5:12 PM, Aryeh Gregor < Simetrical+wikilist@gmail.com Simetrical%2Bwikilist@gmail.com> wrote:
Compare to WordPress, where if you don't keep up-to-date you can get your server taken over and used to send spam (this has been happening recently, I've heard). Not only is that worse for you, it's much more profitable for attackers, so you're likely to see more widespread automatic exploitation. I haven't heard of widespread exploitation of any MW security vulnerability, although it's possible it's happened.
I haven't even heard of _isolated_ exploitation of MediaWiki security holes, let alone anything widespread. Aren't most MW vulnerabilities discovered through audits, code review, or third-party reporting, rather than demonstrated exploitation? _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Last point is dead-on. Almost all of our security issues that I can remember come in as bugs--or e-mails to security@wikimedia.org-- that describe a potential attack vector and possibly a use-case to trigger the described issue. This is how almost all of our bugs are reported and fixed. Major security issues (the XSS ones in the installer is a great example) usually get an immediate patch and release. These are almost always backported to the still supported releases.
The thing that the vulnerability list does not take into account is that old releases are no longer supported. I'm sure there's a whole lot of unpatched vulnerabilities in 1.8 or 1.9. These versions are also unsupported. If you come looking for help in #mediawiki and you're running an outdated version, the most help you'll get is helping you upgrade.
We drop old versions after awhile because it's impossible to maintain an infinite number of back releases. I'm sure there's buffer overflow possibilities in Word 97 that don't exist in Word 2007. We don't see people flipping out over that, do we. Upgrade and these issues quickly become non-issues, period.
Current security issues deserve investigation and fixing, bugs from old and unsupported releases don't, and that site is pretty much a list of the the latter.
-Chad
On Tue, 15 Sep 2009 13:51:48 -0400, Chad innocentkiller@gmail.com wrote:
I'm pretty sure a lot of this has been fixed (I vaguely remember Tim
doing
some cleanup to the installer for XSS issues), but I can't say for sure. Forwarding to wikitech-l, this is more of a tech issue than Foundation one.
Please don't bother wikitech-l with such things; that's just a reference to a list of patched vulnerabilities culled from our own security releases.
-- brion
wikitech-l@lists.wikimedia.org