| Summary: | <www-apps/mediawiki-1.25.6: multiple vulnerabilities | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | web-apps |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2015/12/21/8 | ||
| Whiteboard: | B3 [noglsa cve] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 600190 | ||
| Bug Blocks: | |||
Any updates on this Bug? Maintainers, can we have an update on the bug? (In reply to Yury German from comment #2) > Maintainers, can we have an update on the bug? Honestly I'd suggest package masking or even last-riting to force people who care about MediaWiki on gentoo to come out of the woodwork and (proxy-)maintain it. I used to semi-actively bump it even though I never used it, but I have little interest continuing to do so. All reported vulnerabilities were fixed by upstream in v1.25.4 which never hits the Gentoo repository. However we now have v1.25.6 which contains these fixes: https://gitweb.gentoo.org/repo/gentoo.git/commit/www-apps/mediawiki?id=4670a4d7b5e591d2a50673d8213f84614da645c4 @ Maintainer(s): Please tell us how to proceed. Can we stabilize =www-apps/mediawiki-1.25.6 or =www-apps/mediawiki-1.27.1? @zlogene: why did you remove the CVEs from alias fields? these were correctly assigned (In reply to Kristian Fiskerstrand from comment #5) > @zlogene: why did you remove the CVEs from alias fields? these were > correctly assigned Do not we put only first CVE id there? Otherwise it looks long and ugly (In reply to Mikle Kolyada from comment #6) > (In reply to Kristian Fiskerstrand from comment #5) > > @zlogene: why did you remove the CVEs from alias fields? these were > > correctly assigned > > Do not we put only first CVE id there? Otherwise it looks long and ugly The only reason that was done in the past was bugzilla only supported one bug ID, with multiple alias possible this is the correct behavior agreed within security (and dramastically improves lookups without doing quirky searches). (In reply to Kristian Fiskerstrand from comment #7) > (In reply to Mikle Kolyada from comment #6) > > (In reply to Kristian Fiskerstrand from comment #5) > > > @zlogene: why did you remove the CVEs from alias fields? these were > > > correctly assigned > > > > Do not we put only first CVE id there? Otherwise it looks long and ugly > > The only reason that was done in the past was bugzilla only supported one > bug ID, with multiple alias possible this is the correct behavior agreed > within security (and dramastically improves lookups without doing quirky > searches). Thanks, probably I missed this point, Have not filed the bugs for years. GLSA Vote: No tree is clean. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f923da46172598149d2f5b74b9667e92f957e532 |
From ${URL} : We recently released security fixes for MediaWiki. I believe the first five issues should have CVE's assigned. The last issue (T109724) requires that the organization running the wiki also releases detailed page view data publicly, and probably not worth tracking with a CVE. However I'm happy for mitre to assign one of they think this generally qualifies. * (T117899) XSS from wikitext when $wgArticlePath='$1'. Internal review discovered an XSS vector when MediaWiki is configured with a non-standard configuration. <https://phabricator.wikimedia.org/T117899> * (T119309) User::matchEditToken should use constant-time string comparison. Internal review discovered that tokens were being compared as strings, which could allow a timing attack. This should possibly have 2 CVE's assigned, one for the original patch to use hash_equals in https://gerrit.wikimedia.org/r/#/c/156336/5/includes/User.php (released as part of MediaWiki 1.25, and backported to 1.24 and 1.23 as part of this patch) and one to fix T119309, related to the debugging statement. <https://phabricator.wikimedia.org/T119309> * (T118032) Error thrown by VirtualRESTService when POST variable starts with '@'. Internal review discovered that MediaWiki was not sanitizing parameters passed to the curl library, which could cause curl to upload files from the webserver to an attacker. <https://phabricator.wikimedia.org/T118032> * (T115522) Passwords generated by User::randomPassword() may be shorter than $wgMinimalPasswordLength. MediaWiki user Frank R. Farmer reported that the password reset token could be shorter than the minimum required password length. <https://phabricator.wikimedia.org/T115522> * (T97897) Incorrect parsing of IPs for global block. Wikimedia steward Vituzzu reported that blocking IP addresses with zero-padded octets resulted in a failure to block the IP address. <https://phabricator.wikimedia.org/T97897> * (T109724) A combination of Special:MyPage redirects and pagecounts allows an external site to know the wikipedia login of an user. Wikimedia user Xavier Combelle reported a way to identify user, when detailed page view data is also released. <https://phabricator.wikimedia.org/T109724> @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.