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?

In T179609#3752117, @Legoktm wrote:

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.

Thanks!

In T179609#3753781, @MoritzMuehlenhoff wrote:

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.

In T179609#3753781, @MoritzMuehlenhoff wrote:

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 :)

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

In T179609#3753781, @MoritzMuehlenhoff wrote:

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.

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 > 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

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.

Works for me.