Bug 12931 - mediawiki new security issues fixed upstream in 1.22.3
Summary: mediawiki new security issues fixed upstream in 1.22.3
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/590191/
Whiteboard: MGA3TOO advisory mga3-64-ok MGA4-32-O...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2014-03-04 14:07 CET by David Walser
Modified: 2014-03-10 18:03 CET (History)
4 users (show)

See Also:
Source RPM: mediawiki-1.22.2-3.mga5.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2014-03-04 14:07:32 CET
CVEs have been issued for three security issues fixed in MediaWiki 1.22.3:
http://openwall.com/lists/oss-security/2014/03/01/2

This version was announced on February 28:
http://lists.wikimedia.org/pipermail/mediawiki-announce/2014-February/000141.html

Reproducible: 

Steps to Reproduce:
Comment 1 David Walser 2014-03-04 14:30:39 CET
Updated packages uploaded for Mageia 3, Mageia 4, and Cauldron.

Advisory:
========================

Updated mediawiki packages fix security vulnerabilities:

MediaWiki before 1.22.3 does not block unsafe namespaces, such as a W3C XHTML
namespace, in uploaded SVG files.  Some client software may use these
namespaces in a way that results in XSS.  This was fixed by disallowing
uploading SVG files using non-whitelisted namespaces (CVE-2014-2242).

MediaWiki before 1.22.3 performs token comparison that may be vulnerable to
timing attacks.  This was fixed by making token comparison use constant time
(CVE-2014-2243).

MediaWiki before 1.22.3 could allow an attacker to perform XSS attacks, due
to flaw with link handling in api.php.  This was fixed such that it won't
find links in the middle of api.php links (CVE-2014-2244).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2242
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2243
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2244
http://lists.wikimedia.org/pipermail/mediawiki-announce/2014-February/000141.html
http://openwall.com/lists/oss-security/2014/03/01/2
========================

Updated packages in core/updates_testing:
========================
mediawiki-1.22.3-1.mga3
mediawiki-mysql-1.22.3-1.mga3
mediawiki-pgsql-1.22.3-1.mga3
mediawiki-sqlite-1.22.3-1.mga3
mediawiki-1.22.3-1.mga4
mediawiki-mysql-1.22.3-1.mga4
mediawiki-pgsql-1.22.3-1.mga4
mediawiki-sqlite-1.22.3-1.mga4

from SRPMS:
mediawiki-1.22.3-1.mga3.src.rpm
mediawiki-1.22.3-1.mga4.src.rpm

URL: (none) => qa-bugs@ml.mageia.org
Version: Cauldron => 4
Source RPM: mediawiki-1.22.2-2.mga5.src.rpm => mediawiki-1.22.2-3.mga5.src.rpm
Whiteboard: (none) => MGA3TOO

Comment 2 David Walser 2014-03-04 14:41:51 CET
I did it again :o(  QA is not a URL.

Updated packages uploaded for Mageia 3, Mageia 4, and Cauldron.

Advisory:
========================

Updated mediawiki packages fix security vulnerabilities:

MediaWiki before 1.22.3 does not block unsafe namespaces, such as a W3C XHTML
namespace, in uploaded SVG files.  Some client software may use these
namespaces in a way that results in XSS.  This was fixed by disallowing
uploading SVG files using non-whitelisted namespaces (CVE-2014-2242).

MediaWiki before 1.22.3 performs token comparison that may be vulnerable to
timing attacks.  This was fixed by making token comparison use constant time
(CVE-2014-2243).

MediaWiki before 1.22.3 could allow an attacker to perform XSS attacks, due
to flaw with link handling in api.php.  This was fixed such that it won't
find links in the middle of api.php links (CVE-2014-2244).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2242
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2243
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2244
http://lists.wikimedia.org/pipermail/mediawiki-announce/2014-February/000141.html
http://openwall.com/lists/oss-security/2014/03/01/2
========================

Updated packages in core/updates_testing:
========================
mediawiki-1.22.3-1.mga3
mediawiki-mysql-1.22.3-1.mga3
mediawiki-pgsql-1.22.3-1.mga3
mediawiki-sqlite-1.22.3-1.mga3
mediawiki-1.22.3-1.mga4
mediawiki-mysql-1.22.3-1.mga4
mediawiki-pgsql-1.22.3-1.mga4
mediawiki-sqlite-1.22.3-1.mga4

from SRPMS:
mediawiki-1.22.3-1.mga3.src.rpm
mediawiki-1.22.3-1.mga4.src.rpm

URL: qa-bugs@ml.mageia.org => (none)
Assignee: bugsquad => qa-bugs

Comment 3 David Walser 2014-03-04 15:27:09 CET
Up and running just fine on my production wiki at work (Mageia 3 i586).
Comment 4 Marc Lattemann 2014-03-04 20:00:42 CET
possible PoC?
https://bugzilla.wikimedia.org/show_bug.cgi?id=60771

CC: (none) => marc.lattemann

Comment 5 Marc Lattemann 2014-03-05 21:37:49 CET
Poc does not work so testing updating installed wiki and installation of new wiki.

Tested successfully on Mageia 4 32bit for sqlite, mysql and postgresql

Whiteboard: MGA3TOO => MGA3TOO MGA4-32-OK

Comment 6 Marc Lattemann 2014-03-05 23:08:31 CET
Tested successfully on Mageia 4 64bit for sqlite, mysql and postgresql
Marc Lattemann 2014-03-05 23:08:53 CET

Whiteboard: MGA3TOO MGA4-32-OK => MGA3TOO MGA4-32-OK MGA4-64-OK

Comment 7 claire robinson 2014-03-06 17:42:18 CET
Advisory from comment 2 uploaded.

Whiteboard: MGA3TOO MGA4-32-OK MGA4-64-OK => MGA3TOO advisory MGA4-32-OK MGA4-64-OK

Comment 8 claire robinson 2014-03-07 17:44:28 CET
Testing complete mga3 64 mysql, pgsql & sqlite

Installed, configured, saved LocalSettings.php to /etc/mediawiki/ & browsed the new wiki. Updated and confirmed the Mediawiki Updater runs.

Preparing...                     ###
      1/2: mediawiki-mysql       ###
      2/2: mediawiki             ###
MediaWiki 1.22.3 Updater

Going to run database updates for my_wiki
Depending on the size of your database this may take a while!
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...already have interwiki table
...indexes seem up to 20031107 standards.
...hitcounter table already exists.
...etc

Wiki is still ok after the update.

If installing remotely it's necessary to alter the two 'Require local' lines in /etc/httpd/conf/sites.d/mediawiki.conf to something less restrictive
eg. 'Require all granted' and then reload httpd service.

Remember to delete /etc/mediawiki/LocalSettings.php between installations for the various databases.

Whiteboard: MGA3TOO advisory MGA4-32-OK MGA4-64-OK => MGA3TOO advisory mga3-64-ok MGA4-32-OK MGA4-64-OK

Comment 9 Dave Hodgins 2014-03-07 20:37:27 CET
As comment 3 indicates it's been tested on Mageia 3 i586, I'll go ahead and
validate the update.

Someone from the sysadmin team please push 12931.adv to updates.

Keywords: (none) => validated_update
Whiteboard: MGA3TOO advisory mga3-64-ok MGA4-32-OK MGA4-64-OK => MGA3TOO advisory mga3-64-ok MGA4-32-OK MGA4-64-OK mga3-32-ok
CC: (none) => davidwhodgins, sysadmin-bugs

Comment 10 Marc Lattemann 2014-03-07 21:09:06 CET
tested for mga3 32bit update of existing and installation of new wiki for sqlite, mysql and postgresql.

following issue found in the journalctrl log:
Mar 07 20:04:06 MGA3_32bit suhosin[4128]: ALERT - script tried to disable memory_limit by setting it to a negative value -1 bytes which is not allowed (attacker 'REMOTE_ADDR not set', file '/usr/share/mediawiki/maintenance/Maintenance.php', line 555)

I see, Dave has already validated it :)
Comment 11 Thomas Backlund 2014-03-07 21:16:30 CET
Update pushed:
http://advisories.mageia.org/MGASA-2014-0124.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED

Comment 12 David Walser 2014-03-07 21:24:34 CET
(In reply to Marc Lattemann from comment #10)
> tested for mga3 32bit update of existing and installation of new wiki for
> sqlite, mysql and postgresql.
> 
> following issue found in the journalctrl log:
> Mar 07 20:04:06 MGA3_32bit suhosin[4128]: ALERT - script tried to disable
> memory_limit by setting it to a negative value -1 bytes which is not allowed
> (attacker 'REMOTE_ADDR not set', file
> '/usr/share/mediawiki/maintenance/Maintenance.php', line 555)

Just in case anyone's wondering about that, we discussed this on IRC.  I'm glad Marc pointed that out, because we like to deal with suhosin errors where we can.  We can often add php_flag/value settings to the apache config file to allow the things the software normally does.  Their script really shouldn't be trying to disable the memory_limit completely though, so they'd need to fix that upstream before we could do anything about it downstream.
David Walser 2014-03-10 18:03:33 CET

URL: (none) => http://lwn.net/Vulnerabilities/590191/


Note You need to log in before you can comment on or make changes to this bug.