The PollNY extension for MediaWiki through 1.35 allows XSS via an answer option for a poll question, entered during Special:CreatePoll or Special:UpdatePoll.
CVE: (none) => CVE-2020-29003
No fixed version available yet. Will push when there is. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29003
Version: 7 => CauldronSummary: [Update Request] mediawiki CVE-2020-29003 => mediawiki new security issue CVE-2020-29003Source RPM: mediawiki-1.31.10-1.mga7.src => mediawiki-1.35.0-2.mga8.src.rpm
Hi, thanks for reporting this. As there is no maintainer for this package I added the committers in CC. (Please set the status to 'assigned' if you are working on it)
Assignee: bugsquad => pkg-bugsCC: (none) => luigiwalser, tmb
Upstream has announced versions 1.31.11 and 1.31.12 on December 17 and 18 (today): https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-December/000268.html https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-December/000269.html They fix several security issues (1.31.12 is a regression fix). Debian has issued an advisory for this today (December 18): https://www.debian.org/security/2020/dsa-4816 Updated packages uploaded for Mageia 7 and Cauldron. Advisory: ======================== Updated mediawiki packages fix security vulnerabilities: In MediaWiki before 1.31.11, the messages userrights-expiry-current and userrights-expiry-none can contain raw HTML. XSS can happen when a user visits Special:UserRights but does not have rights to change all userrights, and the table on the left side has unchangeable groups in it. The right column with the changeable groups is not affected and is escaped correctly (CVE-2020-35475). MediaWiki before 1.31.11 blocks legitimate attempts to hide log entries in some situations. If one sets MediaWiki:Mainpage to Special:MyLanguage/Main Page, visits a log entry on Special:Log, and toggles the "Change visibility of selected log entries" checkbox (or a tags checkbox) next to it, there is a redirection to the main page's action=historysubmit instead of the desired behavior in which a revision-deletion form appears (CVE-2020-35477). MediaWiki before 1.31.11 allows XSS via BlockLogFormatter.php. Language::translateBlockExpiry itself does not escape in all code paths. For example, the return of Language::userTimeAndDate is is always unsafe for HTML in a month value (CVE-2020-35479). An issue was discovered in MediaWiki before 1.31.11. Missing users (accounts that don't exist) and hidden users (accounts that have been explicitly hidden due to being abusive, or similar) that the viewer cannot see are handled differently, exposing sensitive information about the hidden status to unprivileged viewers. This exists on various code paths (CVE-2020-35480). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35475 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35477 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35479 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35480 https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-December/000268.html https://lists.wikimedia.org/pipermail/mediawiki-announce/2020-December/000269.html https://www.debian.org/security/2020/dsa-4816 ======================== Updated packages in core/updates_testing: ======================== mediawiki-1.31.12-1.mga7 mediawiki-mysql-1.31.12-1.mga7 mediawiki-pgsql-1.31.12-1.mga7 mediawiki-sqlite-1.31.12-1.mga7 from mediawiki-1.31.12-1.mga7.src.rpm
Assignee: pkg-bugs => qa-bugsVersion: Cauldron => 7Source RPM: mediawiki-1.35.0-2.mga8.src.rpm => mediawiki-1.31.10-1.mga7.src.rpmCVE: CVE-2020-29003 => (none)Summary: mediawiki new security issue CVE-2020-29003 => mediawiki new security issues fixed upstream in 1.31.11URL: https://nvd.nist.gov/vuln/detail/CVE-2020-29003 => (none)
As for CVE-2020-29003, upstream says it's Resolved. Not sure why it wasn't listed in the release announcement, or if 1.31.x was affected.
Testing procedure: https://wiki.mageia.org/en/QA_procedure:Mediawiki
Keywords: (none) => has_procedure
After installing mediawiki and restarting the apache's httpd service, I get the following error messages: ######################### jan 13 11:28:47 marte systemd[1]: Starting The Apache HTTP Server... jan 13 11:28:47 marte httpd[29188]: AH00526: Syntax error on line 20 of /etc/httpd/conf/sites.d/mediawiki.conf: jan 13 11:28:47 marte httpd[29188]: Invalid command 'php_admin_flag', perhaps misspelled or defined by a module not included in the server configuration jan 13 11:28:47 marte systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE jan 13 11:28:47 marte systemd[1]: httpd.service: Failed with result 'exit-code'. jan 13 11:28:47 marte systemd[1]: Failed to start The Apache HTTP Server. ######################### After commenting the "line 20 of /etc/httpd/conf/sites.d/mediawiki.conf" and restarting the httpd service, I get the following error messages: ######################### jan 13 11:29:35 marte systemd[1]: Starting The Apache HTTP Server... jan 13 11:29:35 marte httpd[29201]: AH00526: Syntax error on line 33 of /etc/httpd/conf/sites.d/mediawiki.conf: jan 13 11:29:35 marte httpd[29201]: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration jan 13 11:29:35 marte systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE jan 13 11:29:35 marte systemd[1]: httpd.service: Failed with result 'exit-code'. jan 13 11:29:35 marte systemd[1]: Failed to start The Apache HTTP Server. ######################### After commenting the "line 33 of /etc/httpd/conf/sites.d/mediawiki.conf" and restarting the httpd service, the httpd server starts without errors. After a search, it seems php_* are only supported if mod_php is loaded. This system is using php-fpm, hence the errors. I suggest wrapping those lines in IfModule directives, like the following: ######################### <IfModule mod_php.c> php_admin_flag engine off </IfModule> ######################### $ uname -a Linux marte 5.10.6-desktop-1.mga7 #1 SMP Sat Jan 9 20:09:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep mediawiki | sort mediawiki-1.31.10-1.mga7 mediawiki-mysql-1.31.10-1.mga7 $ systemctl status httpd.socket httpd.service php-fpm.socket php-fpm.service ● httpd.socket - httpd server activation socket Loaded: loaded (/usr/local/lib/systemd/system/httpd.socket; enabled; vendor preset: disabled) Active: active (running) since Wed 2021-01-13 09:18:35 WET; 2h 13min ago Listen: [::]:80 (Stream) [::]:443 (Stream) Tasks: 0 (limit: 4695) Memory: 8.0K CGroup: /system.slice/httpd.socket jan 13 09:18:35 marte systemd[1]: Listening on httpd server activation socket. ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2021-01-13 11:29:56 WET; 2min 13s ago Main PID: 29212 (httpd) Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec: 0 B/sec" Tasks: 66 (limit: 4695) Memory: 28.4M CGroup: /system.slice/httpd.service ├─29212 /usr/sbin/httpd -DFOREGROUND ├─29214 /usr/sbin/httpd -DFOREGROUND └─29215 /usr/sbin/httpd -DFOREGROUND jan 13 11:29:56 marte systemd[1]: Starting The Apache HTTP Server... jan 13 11:29:56 marte systemd[1]: Started The Apache HTTP Server. ● php-fpm.socket - php-fpm Server Socket Loaded: loaded (/usr/local/lib/systemd/system/php-fpm.socket; enabled; vendor preset: disabled) Active: active (listening) since Wed 2021-01-13 09:18:35 WET; 2h 13min ago Listen: /var/lib/php-fpm/php-fpm.sock (Stream) CGroup: /system.slice/php-fpm.socket jan 13 09:18:35 marte systemd[1]: Listening on php-fpm Server Socket. ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled) Active: inactive (dead)
CC: (none) => mageia
Ping?
CC: (none) => ouaurelien
MGA7-64 MATE on PeaqC1011 No installation issues I didn't have the issue on httpd, as this was also installed brandnew. Followed test procedure using mysql and tip from bug 25986, Created first wikipage. OK for me.
Whiteboard: (none) => MGA7-64-OKCC: (none) => herman.viaene
(In reply to PC LX from comment #6) > After a search, it seems php_* are only supported if mod_php is loaded. This > system is using php-fpm, hence the errors. > > I suggest wrapping those lines in IfModule directives, like the following: > > ######################### > <IfModule mod_php.c> > php_admin_flag engine off > </IfModule> > ######################### Is that a regression, or was that problem present in the existing version? If it's an existing bug, the security fix should be ok'd and a new normal bug opened for that problem.
CC: (none) => davidwhodgins
I'm sure it isn't new, but it's a PHP problem, not a MediaWiki problem. Also, our web app packages tend to be designed to work out of the box with mod_php. If you want to use fpm, that's on you.
Advisory committed to svn. Validating the update.
CC: (none) => sysadmin-bugsKeywords: (none) => advisory, validated_update
(In reply to Dave Hodgins from comment #9) > (In reply to PC LX from comment #6) > > After a search, it seems php_* are only supported if mod_php is loaded. This > > system is using php-fpm, hence the errors. > > > > I suggest wrapping those lines in IfModule directives, like the following: > > > > ######################### > > <IfModule mod_php.c> > > php_admin_flag engine off > > </IfModule> > > ######################### > > Is that a regression, or was that problem present in the existing version? > > If it's an existing bug, the security fix should be ok'd and a new normal bug > opened for that problem. I is not a regression, at least from the previous version mediawiki-1.31.10-1.mga7 but I'm only installing it for testing so I only noticed it now. (In reply to David Walser from comment #10) > I'm sure it isn't new, but it's a PHP problem, not a MediaWiki problem. It is a configuration problem in a file in the mediawiki package. > Also, our web app packages tend to be designed to work out of the box with > mod_php. If you want to use fpm, that's on you. The small change I showed in comment 6 solves the issue with php-fpm. Should I open a bug report for this?
It's not a configuration problem in the MediaWiki package, the configuration is correct. If fpm has a problem with it, it's a bug in fpm, which is a part of the php package.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2021-0086.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
(In reply to David Walser from comment #13) > It's not a configuration problem in the MediaWiki package, the configuration > is correct. If fpm has a problem with it, it's a bug in fpm, which is a > part of the php package. This issue is not in php-fpm. It is the apache configuration file in mediawiki that has the issue. The issue occurs when mod_php is not enable. The php directives are only supported in the apache configuration when mod_php is enabled. If mod_php is not enabled and mediawiki is installed, the issue will ocurr and apache will fail to start.
I do not agree on Comment 15. I had a fresh install of apache to do this test just with it default dependencies, it hadn't been on this installation before. The httpd started without any problem, and the whole mediawiki installation and operation went without a glitch.
well this is mostly bikeshedding. yes, most of our default configs are matched with mod_php, and has been for ages, so no surprise that other setups gets an hiccup... but that does not prevent us to update the default config so it works with other packages we officially provide in our repos, especially in cases where the changes are not conflicting with mod_php setups like the simple fix this one needs... <IfModule mod_php.c> php_admin_flag engine off </IfModule> this is the same thing we do with several other apache and other modules in various places... basically check if the module is there before actually "sending commands to it"...