Page MenuHomePhabricator

Obtain CVE's for 1.27.4/1.29.2 security releases
Closed, ResolvedPublic

Description

T178451: XSS when $wgShowExceptionDetails = false and browser sends non-standard url escaping (CVE-2017-8808)

Flaw

Potential XSS when $wgShowExceptionDetails = false; is set and an exception is encountered depending on client used.

Exploit

Affects

MediaWiki versions
  1.29.x prior to 1.29.2
  1.28.x prior to 1.28.3
  1.27.x prior to 1.27.4
  and unsupported branches 1.20.x, 1.21.x, 1.22.x, 1.23.x 1.24.x, 1.25.x, 1.26.x

Reference

https://phabricator.wikimedia.org/T178451

T128209: Reflected File Download from api.php (CVE-2017-8809)

Flaw

Exploit

Affects

MediaWiki versions
  1.29.x prior to 1.29.2
  1.28.x prior to 1.28.3
  1.27.x prior to 1.27.4
  and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

Reference

https://phabricator.wikimedia.org/T128209

T165846: BotPasswords doesn't throttle login attempts

Flaw

When logging in using a Bot Password, users login are not limited.

Exploit

A malicious user can repeatedly try to login via the api using a Bot Password, ignoring any warnings without any restrictions, making guessing passwords a lot easier. With the throttle in place, users are limited in the number of login attempts in a period of time.

Affects

MediaWiki versions
  1.29.x prior to 1.29.2
  1.28.x prior to 1.28.3
  1.27.x prior to 1.27.4

Reference

https://phabricator.wikimedia.org/T165846

T134100: On private wikis, login form shouldn't distinguish between login failure due to bad username and bad password (CVE-2017-8810)

Flaw

On a private wiki, the list of its users is also private. Error messages given upon login with an incorrect password make it possible to distinguish if a user has an account on the wiki or not.

This information should not be exposed to an anonymous user.

Exploit

A malicious user can easily find out if the account they are trying to login in as exists on the wiki. This means they can distinguish that they know the account exists, and as such, just need to work out the password.

Affects

MediaWiki versions
  1.29.x prior to 1.29.2
  1.28.x prior to 1.28.3
  1.27.x prior to 1.27.4
  and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

Reference

https://phabricator.wikimedia.org/T134100

T176247: It's possible to mangle HTML via raw message parameter expansion (CVE-2017-8811)

Flaw

When $wgExperimentalHtmlIds is set to true (false by default), certain characters in section IDs don't get percent encoded, including $ which is used for parameter substitution.

Exploit

It is possible to combine this with raw localization message parameter expansion to create malformed HTML. While escalation to full-blown XSS hasn't been demonstrated so far, it remains a possibility.

Affects

MediaWiki versions
  1.29.x prior to 1.29.2
  1.28.x prior to 1.28.3
  1.27.x prior to 1.27.4
  and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

Reference

https://phabricator.wikimedia.org/T176247

T125163: id attribute on headlines allow raw > [Possible issue in combination with language converter] (CVE-2017-8812)

Flaw

A wikipage with a header containing > in it, may generate a span with an id attribute that has > in it in certain (non-default) configs. This in itself is not an issue, but sometimes people try to parse the resulting html using regular expressions instead of a proper html parser. In such cases this can lead to an XSS. As a hardening measure against people doing such things, we no longer allow raw > in quoted attributes.

Affects

1.29.x prior to 1.29.2
1.28.x prior to 1.28.3
1.27.x prior to 1.27.4
and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

T124404: language converter can be tricked into replacing text inside tags by adding a lot of junk after the rule definition (CVE-2017-8814)

Flaw

Stored XSS: Language converter splits the page into components to convert based on a regular expression. Certain input can cause the regex to backtrack excessively. If the backtracking exceeds pcre.backtrack_limit, then it is possible to inject html due to incorrect splitting into translation components.

Exploit

Set $wgLangaugeCode = 'sr'; in LocalSettings.php
set pcre.backtrack_limit = 10 in php.ini

Put the following in a page

-{H|big=>sr-el:script}- foo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

<big>alert(1)</big>

View page, with url parameter variant=sr-el

Affects

MediaWiki versions

1.29.x prior to 1.29.2
1.28.x prior to 1.28.3
1.27.x prior to 1.27.4
and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

T119158: Language converter: unsafe attribute injection via glossary rules (CVE-2017-8815)

Flaw

In certain code paths, langauge converter glossary rules will get expanded inside attributes. This can lead to XSS on wikis that have language converter enabled

exploit

Assuming you have an image named example.png uploaded to your wiki.

Set $wgLanguageCode = 'sr';

Put on a page

-{H|abc=>sr-el:" onfocus="alert(1)" onload="alert(2)" data-foo="}-

{{special:Contributions|target=-{}-abc-{}-}}

[[File:Example.png|100px|alt=-{n}-abc-{}-]]

visit the page with the url parameter variant=sr-el set.

affects

1.29.x prior to 1.29.2
1.28.x prior to 1.28.3
1.27.x prior to 1.27.4
and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

Related Objects

StatusAssignedTask
Resolveddemon
ResolvedReedy
ResolvedReedy
ResolvedBawolff
ResolvedAnomie
ResolvedBawolff
ResolvedBawolff
ResolvedMaxSem
ResolvedMoritzMuehlenhoff
ResolvedMaxSem
ResolvedReedy
ResolvedReedy
DeclinedNone
DeclinedNone
ResolvedLegoktm
ResolvedBawolff
ResolvedBawolff
ResolvedAnomie

Event Timeline

Reedy created this task.Nov 2 2017, 7:37 PM
Reedy created this object with visibility "Custom Policy".
Reedy updated the task description. (Show Details)Nov 2 2017, 10:49 PM
Reedy updated the task description. (Show Details)
MaxSem updated the task description. (Show Details)Nov 2 2017, 11:06 PM
Reedy updated the task description. (Show Details)Nov 3 2017, 12:11 AM
Reedy updated the task description. (Show Details)Nov 3 2017, 12:14 AM
MaxSem updated the task description. (Show Details)Nov 3 2017, 8:10 PM
dpatrick triaged this task as Normal priority.Nov 8 2017, 6:15 PM

How does it work for CVE's for T180231?

The PHPUnit part itself has a CVE of CVE-2017-9841...

I don't think that will get another CVE since it's the exact same vulnerability?

I don't think that will get another CVE since it's the exact same vulnerability?

It is... But it's "under" MW.. So I dunno how this really works... @MoritzMuehlenhoff ? :)

I'm assigning CVE IDs from the Debian CNA pool:

T178451: XSS when $wgShowExceptionDetails = false and browser sends non-standard url escaping => CVE-2017-8808
T128209: Reflected File Download from api.php => CVE-2017-8809
T134100: On private wikis, login form shouldn't distinguish between login failure due to bad username and bad password => CVE-2017-8810
T176247: It's possible to mangle HTML via raw message parameter expansion => CVE-2017-8811

T180231 is covered by the existing CVE-2017-9841, no need for a specific mediawiki one.

I'm not really sure about "T165846: BotPasswords doesn't throttle login attempts", could use some background: Was the lack of throttling an oversight (or did we even document that throttling applied everywhere e.g.?) Otherwise this is borderline to a security enhancement and those don't get CVE IDs assigned usually.

Reedy added subscribers: Anomie, Tgr.Nov 13 2017, 2:19 PM

Thanks!

T180231 is covered by the existing CVE-2017-9841, no need for a specific mediawiki one.

As per the comments above, we didn't know how this worked. Thanks for clarifying.

I'm not really sure about "T165846: BotPasswords doesn't throttle login attempts", could use some background: Was the lack of throttling an oversight (or did we even document that throttling applied everywhere e.g.?) Otherwise this is borderline to a security enhancement and those don't get CVE IDs assigned usually.

Yeah, I believe it was an oversight. https://www.mediawiki.org/wiki/Manual:$wgPasswordAttemptThrottle has been around since MW 1.14 (circa 2009) and has been providing a layer of attack security (of course, it doesn't stop people switching IP addresses, as we've seen) but

The documentation is a little vague - Limit password attempts per IP per address. but it would be a reasonable assumption to presume that this included BotPasswords (which was a new feature)

But that throttling only occurs after the BotPassword login is attempted, so an attacker could ignore the throttling messages to keep attempting to attack a BotPassword.

Maybe @Anomie or @Tgr can clarify further as implementers of the feature and the AuthManager code too :)

Reedy added a comment.Nov 13 2017, 2:23 PM

Bah. Looks like I didn't add T125163 to the list when it was added to the parent task...

Reedy updated the task description. (Show Details)Nov 13 2017, 2:25 PM
Reedy updated the task description. (Show Details)Nov 13 2017, 6:18 PM
Reedy updated the task description. (Show Details)
Reedy updated the task description. (Show Details)Nov 13 2017, 6:30 PM
Reedy updated the task description. (Show Details)
Reedy updated the task description. (Show Details)Nov 13 2017, 7:32 PM
Anomie added a comment.EditedNov 13 2017, 8:09 PM

I'm not really sure about "T165846: BotPasswords doesn't throttle login attempts", could use some background: Was the lack of throttling an oversight (or did we even document that throttling applied everywhere e.g.?) Otherwise this is borderline to a security enhancement and those don't get CVE IDs assigned usually.

The lack of throttling was an oversight. BotPasswords was created as an alternative login code path that bypasses the interactive checks that were going to be added in AuthManager, and when implementing that alternative login code path I forgot to put throttling anywhere in there to match the existing throttling in the main code path.

Tgr added a comment.Nov 13 2017, 8:53 PM

Mind you, bot passwords use thirty-something character random generated passwords, so there isn't any need for throttling, unless you are worried about DoS attacks (but I'm sure we have worse DoS vectors than password checks).

More specifically, 32 characters from a base-32 character set, generated by PasswordFactory::generateRandomPasswordString(), so ideally 160 bits of randomness.

In addition to the botpassword one if it qualifies for a CVE. we need three more additonally CVEs (sorry about not listing these from the get-go. That was my bad for adding them late)

T125163: id attribute on headlines allow raw > [Possible issue in combination with language converter] (CVE-2017-8812)

Flaw

A wikipage with a header containing &gt; in it, may generate a span with an id attribute that has > in it in certain (non-default) configs. This in itself is not an issue, but sometimes people try to parse the resulting html using regular expressions instead of a proper html parser. In such cases this can lead to an XSS. As a hardening measure against people doing such things, we no longer allow raw > in quoted attributes.

Affects

1.29.x prior to 1.29.2
1.28.x prior to 1.28.3
1.27.x prior to 1.27.4
and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

T124404: language converter can be tricked into replacing text inside tags by adding a lot of junk after the rule definition (CVE-2017-8814)

Flaw

Stored XSS: Language converter splits the page into components to convert based on a regular expression. Certain input can cause the regex to backtrack excessively. If the backtracking exceeds pcre.backtrack_limit, then it is possible to inject html due to incorrect splitting into translation components.

Exploit

Set $wgLangaugeCode = 'sr'; in LocalSettings.php
set pcre.backtrack_limit = 10 in php.ini

Put the following in a page

-{H|big=>sr-el:script}- foo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

<big>alert(1)</big>

View page, with url parameter variant=sr-el

Affects

MediaWiki versions

1.29.x prior to 1.29.2
1.28.x prior to 1.28.3
1.27.x prior to 1.27.4
and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

T119158: Language converter: unsafe attribute injection via glossary rules (CVE-2017-8815)

Flaw

In certain code paths, langauge converter glossary rules will get expanded inside attributes. This can lead to XSS on wikis that have language converter enabled

exploit

Assuming you have an image named example.png uploaded to your wiki.

Set $wgLanguageCode = 'sr';

Put on a page

-{H|abc=>sr-el:" onfocus="alert(1)" onload="alert(2)" data-foo="}-

{{special:Contributions|target=-{}-abc-{}-}}

[[File:Example.png|100px|alt=-{n}-abc-{}-]]

visit the page with the url parameter variant=sr-el set.

affects

1.29.x prior to 1.29.2
1.28.x prior to 1.28.3
1.27.x prior to 1.27.4
and unsupported branches 1.21.x, 1.22.x, 1.23.x, 1.24.x, 1.25.x, 1.26.x

Reedy updated the task description. (Show Details)Nov 14 2017, 12:43 AM

There we go for the three new arrivals:

T125163: id attribute on headlines allow raw > => CVE-2017-8812
T124404: language converter can be tricked into replacing text inside tags by adding a lot of junk after the rule definition => CVE-2017-8814
T119158: Language converter: unsafe attribute injection via glossary rules => CVE-2017-8815

In case you're wondering about CVE-2017-8813, that one got rejected since another distro meant to use CVE-2017-8831, but instead send out CVE-2017-8813.

I'd say let's skip a CVE ID for "BotPasswords doesn't throttle login attempts" since it has no practical (or marginal at best) security implications.

Reedy added a comment.Nov 14 2017, 3:35 PM

Works for me.

Reedy closed this task as Resolved.Nov 14 2017, 5:23 PM
Reedy assigned this task to MoritzMuehlenhoff.
Reedy changed the visibility from "Custom Policy" to "Public (No Login Required)".Nov 15 2017, 12:03 AM