In T303433#9945363, @kostajh wrote:

• Enable a global abuse filter for showing a CAPTCHA on all projects
• Create two local abuse filters on enwiki and jawiki

Which doesn't sound that bad. Just trying to avoid the need to build new software for this, if it can be easily solved with something we've already got.

In T303433#9945321, @kostajh wrote:

I see, thanks. The example patch in the task description is enabling CAPTCHA for just one wiki. Are there circumstances where we want to set $wmgEmergencyCaptcha across all projects without involving SREs? If not, then the AbuseFilter + showcaptcha consequence seems like it would suffice for the use case described in this task.

In T367205#9941551, @SDeckelmann-WMF wrote:

Hey! I get the emails, so no relaying required :)

And, done.

In T367205#9938963, @Aklapper wrote:

Per Security's SOP, "Set up Two-Factor Authentication for your Phabricator account under Settings → Authentication → Multi-Factor Auth" is required.
This has not happened thus reopening this ticket.

Write-up of some of this quarter's work is here: T335892#9936225

Hey all -

I've gone ahead and made T366554 public as, at worst, I think it's a low-risk issue.

In T355161#9919029, @Iniquity wrote:

@sbassett Hi! Are you able to check the extension next quarter?

Example of a template keeping track of cumulative bash error codes: https://gitlab.wikimedia.org/repos/security/gitlab-ci-security-templates/-/blob/7102fe1332c371f52d5e0800701d60a81a7e104c/php-security-checker/php-security-checker-ci.yml#L24-L70

@Chocapikk1337 - you've now been added to our hall of fame: https://security.wikimedia.org/hall-of-fame/

Stalled on completion date. If that's not proper, we can set the status to something else. The Security-Team also has a calendar invite set for this next year.

In T337305#9916137, @Grunny wrote:

Was I caught up in this cleanup by chance @sbassett? I noticed my access seems to be gone. If so, could I be readded? I use the access for Fandom for pre-release access and checking for any crossover with our bug bounty program we run.

In T340189#9911190, @Ladsgroup wrote:

Given that more than ninety days have passed since this bug got fixed, we don't have any logs of who might have accessed the private files. I suggest closing this and filing follow ups for fixing setZone and other issues?

In T364302#9908817, @Bugreporter wrote:

Note: github.com/wikimedia is not the only place that Wikimedia codes are located - see https://www.mediawiki.org/wiki/Gerrit/GitHub#Other_GitHub_organizations. Some are semi-official, such as toolforge related repos which may be co-maintained by WMF and volunteers. There are a number of WMDE repos too which is used in production.

Security Review Summary - T360070 - 2024-06-17
Last commit reviewed: be78eb0148

For active, I was just meaning "not archived", per gerrit's definition.

Quick update on this: I plan to post the review next Monday or Tuesday. I haven't really found anything concerning at all.

Ok, if we can keep it simple but all-encompassing, then I'd probably go with something like: "Any active code repository hosted under gerrit.wikimedia.org, gitlab.wikimedia.org or github.com/wikimedia that is not a fork of an upstream project or otherwise unmaintained by the WMF or Wikimedia Community".

In T335892#9891420, @sguebo_WMF wrote:

@sbassett, as a next step I'd probably use your idea of detecting TPR use by searching for things like import, importScript, mw.loader.load, xmlhttprequest, jquery.load, url for css, et al. Glad to hear if you think there's a cleaner way to avoid false positives.

In T364302#9893759, @Mstyles wrote:

"Vulnerabilities in MediaWiki core (https://gerrit.wikimedia.org/r/admin/repos/mediawiki/core,general), skins and extensions hosted on gerrit.wikimedia.org, gitlab.wikimedia.org or github.com/wikimedia along with wikimedia microservices hosted here: https://gerrit.wikimedia.org/r/admin/repos/q/filter:mediawiki/services"

At the very least I think we'd also want to include MediaWiki skins (as opposed to just extensions) since WMF folks are largely the maintainers of Vector et al. Personally, I think we'd also want to include things like the various Wikimedia microservices that support some production-deployed MediaWiki extensions, etc. as we are pretty much the sole maintainers of those. Beyond that, we do write a lot of additional, proprietary Wikimedia code (SRE, Data Engineering, etc.) but we've never traditionally requested many CVEs for many of those codebases, so maybe we aren't worried about those as much. I'd also prefer to at least have the ability to issue CVEs for non-Wikimedia-deployed extensions and skins, as many of those comprise the quarterly supplemental security releases that we still manage.

In T364555#9889741, @MHorsey-WMF wrote:

Oh, yes sorry. I can confirm it's all about that package.

In T365298#9886304, @Tgr wrote:

...something like https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin which is potentially confusing or suspicious...

In T364555#9888341, @MHorsey-WMF wrote:

@sbassett so are we safe to go ahead?

Ok, let's call this resolved then, as Wikimedia wikis are unaffected. I guess the only thing we'd need to worry about is if mathoid-mathjax ever updates the version of mathjax from which they are forked (assuming this only affects mathjax v3) and texvcjs ever becomes more lax in the commands/functions it allows.

Interesting - they were added to WMF-NDA, but none of the acl*security groups. I've gone ahead and added them to acl*security_management, so they should be able to see all current security issues tracked in Phab (some of these are public if they're low-risk, etc.)

Any concerns, @Marostegui? If not, happy to make these tasks public now.

So CVE-2023-39663 looks like it refers to two regular expression DoS vectors. It looks like this issue might be tracked within these two issues:

1. https://github.com/mathjax/MathJax/issues/3129 (original)
2. https://github.com/mathjax/MathJax/issues/3241 (duplicate)

There is a work-around posted under the first issue (safe mode) but I'm not seeing a CVE. A commenter also noted that this issue is fixed within v4, but that version is still in beta. So we might want to explore the safe mode config for v3, if we don't currently have that enabled.

I received approval from WMF-Legal to make this public and for @Chocapikk1337 to write a public blog post (or whatever) about this issue. Also, @Chocapikk1337, let us know if you'd like to be added to the Wikimedia security hall of fame.

Looks like @Reedy and @tstarling answered your questions, @MarkAHershberger? Did you need anything else right now or can we resolve this?