I would like to announce the release of MediaWiki 1.17.3. Five security issues were discovered.
It was discovered that the api had a cross-site request forgery (CSRF) vulnerability in the block/unblock modules. It was possible for a user account with the block privileges to block or unblock another user without providing a token.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212
It was discovered that the resource loader can leak certain kinds of private data across domain origin boundaries, by providing the data as an executable JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of CSRF protection tokens. This allows compromise of the wiki's user accounts, say by changing the user's email address and then requesting a password reset.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907
Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF) vulnerability in Special:Upload. Modern browsers (since at least as early as December 2010) are able to post file uploads without user interaction, violating previous security assumptions within MediaWiki.
Depending on the wiki's configuration, this vulnerability could lead to further compromise, especially on private wikis where the set of allowed file types is broader than on public wikis. Note that CSRF allows compromise of a wiki from an external website even if the wiki is behind a firewall.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317
George Argyros and Aggelos Kiayias reported that the method used to generate password reset tokens is not sufficiently secure. Instead we use various more secure random number generators, depending on what is available on the platform. Windows users are strongly advised to install either the openssl extension or the mcrypt extension for PHP so that MediaWiki can take advantage of the cryptographic random number facility provided by Windows.
Any extension developers using mt_rand() to generate random numbers in contexts where security is required are encouraged to instead make use of the MWCryptRand class introduced with this release.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078
A long-standing bug in the wikitext parser (bug 22555) was discovered to have security implications. In the presence of the popular CharInsert extension, it leads to cross-site scripting (XSS). XSS may be possible with other extensions or perhaps even the MediaWiki core alone, although this is not confirmed at this time. A denial-of-service attack (infinite loop) is also possible regardless of configuration.
For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315
Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE LEASE-NOTES;hb=1.17.3 https://www.mediawiki.org/wiki/Release_notes/1.17
Co-inciding with these security releases, the MediaWiki source code repository has moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3) to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the relevant commits for these releases will not be appearing in our SVN repository. If you use SVN checkouts of MediaWiki for version control, you need to migrate these to Git. If you up are using tarballs, there should be no change in the process for you.
Please note that any WMF-deployed extensions have also been migrated to Git also, along with some other non WMF-maintained ones.
Please bear with us, some of the Git related links for this release may not work instantly, but should later on.
To do a simple Git clone, the command is: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
More information is available at https://www.mediawiki.org/wiki/Git
For more help, please visit the #mediawiki IRC channel on freenode.net irc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list at mediawiki-l@lists.wikimedia.org.
********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.tar.gz
Patch to previous version (1.17.2), without interface text: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.17/mediawiki-i18n-1.17.3.patch.gz
GPG signatures: http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.17/mediawiki-1.17.3.patch.gz.sig http://download.wikimedia.org/mediawiki/1.17/mediawiki-i18n-1.17.3.patch.gz. sig
Public keys: https://secure.wikimedia.org/keys.html
I have a quite private 1.17 installation on my own computer, and I use it alone with no access from internet. Am I right that it does not need to be updated because of these bugs?
On Thu, 22 Mar 2012 13:21:16 -0700, Bináris wikiposta@gmail.com wrote:
I have a quite private 1.17 installation on my own computer, and I use it alone with no access from internet. Am I right that it does not need to be updated because of these bugs?
That Upload CSRF bug can be used against private wikis.
On 22/03/12 21:21, Bináris wrote:
I have a quite private 1.17 installation on my own computer, and I use it alone with no access from internet. Am I right that it does not need to be updated because of these bugs?
If you browse the internet from that computer when the wiki is accesible, it could be compromised. It wouldn't be of much use to do it, but better to not give any chance. See the note about "allows compromise of a wiki from an external website even if the wiki is behind a firewall".
On Fri, Mar 23, 2012 at 6:42 AM, Platonides Platonides@gmail.com wrote:
If you browse the internet from that computer when the wiki is accesible, it could be compromised.
No it's not.... Unless you are bindly making your local web server fowarded to the outside network.
On Thu, Mar 22, 2012 at 2:14 PM, K. Peachey p858snake@gmail.com wrote:
On Fri, Mar 23, 2012 at 6:42 AM, Platonides Platonides@gmail.com wrote:
If you browse the internet from that computer when the wiki is accesible, it could be compromised.
No it's not.... Unless you are bindly making your local web server fowarded to the outside network.
It doesn't matter if your web server is accessibly from the outside network or not. If you are logged into your local wiki, and someone knows of its existence, they could attack you from another server outside of your network.
- Ryan
On 22/03/12 22:25, Ryan Lane wrote:
On Thu, Mar 22, 2012 at 2:14 PM, K. Peachey p858snake@gmail.com wrote:
On Fri, Mar 23, 2012 at 6:42 AM, Platonides Platonides@gmail.com wrote:
If you browse the internet from that computer when the wiki is accesible, it could be compromised.
No it's not.... Unless you are bindly making your local web server fowarded to the outside network.
It doesn't matter if your web server is accessibly from the outside network or not. If you are logged into your local wiki, and someone knows of its existence, they could attack you from another server outside of your network.
- Ryan
Exactly. You would need something like Mozilla bug 354493 fixed to be safe. https://bugzilla.mozilla.org/show_bug.cgi?id=354493
Or a webapp not vulnerable to CSRF, which is why we're sending out that fix. :)
wikitech-l@lists.wikimedia.org