I work on the MediaWiki Security Team.
So does the paper actually say anything new? Users choosing terrible passwords is not new. The question is always a risk analysis question. Does the risk of users using stupid passwords outweigh the inconvineance of forcing good passwords? How does this vary with different classes of users? To what extent is it a personal responsibility vs how much of a threat is it to other users (esp. When talking about forcing strong passwords instead of merely suggesting them).
Fri, Jul 20
This was publically disclosed at https://security.stackexchange.com/questions/189940/xss-in-big-wiki-software . Making public since private has no point now
Thu, Jul 19
The output is escaped via json_encode. I dont see any way to exploit this.
My main concerns are:
- What if two people use the same email address
- Would there be any way of leaking that an email address is in use (e.g. By looking for "user does not exist error"). In particular, if attacker is trying to guess what another user is using as email, would he be able to somehow figure it out by setting his email to be the same as the victim (I guess email confirmation would prevent that. Ideally though I'd like to see that attack stopped even if the malicious user somehow manages to confirm his email).
I'm going to backport this, as @UlfrTheRed the red was just complaining about this issue on irc in MediaWiki 1.31
Wed, Jul 18
He's also been here forever. I think he is probably the oldest contributor to mediawiki without +2 at this point.
Tue, Jul 17
So this has been stuck for a while. I decided to look into what else we can do with hopefully less contention.
This is normal behaviour when mediawiki is configured to use image magick's convert(1) for resizing images.
Fri, Jul 13
Copyright statements should be "Copyright [year] Wikimedia Foundation and contributors"
Thu, Jul 12
Wed, Jul 11
OK thanks...!!! Do you know if, as it is, it allows gadgets and user scripts?
We may be adjusting the core csp header
Its kind of rediculously long. We also plan on disabling nonces in the initial rollout. So the core stuff should be considered to be in flux
Tue, Jul 10
Can you give steps to reliably reproduce human editors being attributed to the wrong user? Its unlikely we would be able to fix it unless we can reliably reproduce the issue.
In terms of this ticket, I'm not sure there's much we can do at the moment. Can I close & make public this ticket?
Mon, Jul 9
I personally think we should document the situation carefully, but ultimately this is clients responsibility
@Pamputt Hi. Can you do this yourself at https://wikitech.wikimedia.org/wiki/Special:Preferences#mw-prefsection-openstack ?
[This is considered a low priority in the context of security issues which we prioritize based on severity. My marking it as low should not be taken to mean i think its unimportant or anything like that]
Is this in scope of Anti-Harassment team?
Personally I wish that gerrit just used oAuth and we just used on wiki SUL 2fa.... but i guess its a bit late for that.
This is not a security issue per-se. Making this bug public and moving out of Security
May have to wait until composer.json in mediawiki core is updated to the new version of oojs before we see the results... but this bug is complete now.
it passes locally for me, so once all these things are merged, and a new version of phan-taint-check is tagged, this bug should be done.
Sun, Jul 8
So this is from the CentralNotice CSP, not the mediawiki CSP we are experimenting with.
Sat, Jul 7
Fri, Jul 6
Thu, Jul 5
Not sure what this is about, but after https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Renameuser/+/410876/ and https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Renameuser/+/424495/ seems like it works fine.
It'd be kind of nice if people who are members solely so all commits in wmf repos appear in their contribs graph without having to star every repo, didn't have to have 2fa (and had no rights). But I guess that's not an option.
Tue, Jul 3
Mon, Jul 2
I think this is ok, and I have no objections, with the caveat that (imo), security's role should be ensuring that stuff meets a certain standard or is safe against a certain threat model. I don't entirely feel confident that I'm competent to review something where the criteria of what we're trying to protect against is unspecified. That said, as far as I can tell, the proposal sounds reasonable.
Tue, Jun 26
Sorry for the delay, this kind of got preempted by t194204 but is now next on my todo list.
Mon, Jun 25
Sat, Jun 23
Jun 19 2018
Jun 18 2018
Legal needs to approve as a privacy thing.
Jun 16 2018
Jun 15 2018
I agree with anomie's assesment. If ls_field is on a whitelist and we are sure that ls_log_id references something on the log_type whitelist and is not revdel'ed it should be fine to expose
yeah, we know
Jun 14 2018
Jun 13 2018
If we make too many things require reauth then we run the risk of annoying users. We also run the risk of making entering your password a common occurance which could aid phising attacks
You would also have to be careful about the case where the right is just checked for asethic purposes (e.g. adding a link to the special page if the user has the right to do the action)