@bcampbell - Can you provide us with an estimated deployment date for this? Something more specific than "as soon as possible" is desirable, for scheduling purposes. And is there any kind of working test or development environment that the Security-Team can have access to? That would likely be a requirement for this review.

I created a very simple Wikimedia domains validation function for oauthcallback.php, the pull request is here: https://github.com/internetarchive/internetarchivebot/pull/16. It basically checks the same allow list as the Wikimedia URL shortener and throws an exception if someone tries to fuzz a different $_GET['returnto'] value. Additional domains (toolforge.org et al) could be added to the allow list if needed and the exception/oauth flow could possibly be handled more gracefully, but the pull request should minimally address the security issue discussed here.

The Security-Team would currently rate any increase in rate limits for file uploads for this use case as a medium risk, given several of the concerns around resource exhaustion and audibility mentioned within previous comments.

@Daimona @Urbanecm - there's also this one that we should probably deploy soon: T272244. Should be simple to deploy, but it'd be nice to have someone available who could quickly help test it out.

@aaron - makes sense, thanks for the thorough analysis here and the additional performance refactor (admittedly, I don't have expansive knowledge of the intricacies of and optimizations for the wancache.) I'll try to get that tested locally soon and merge the change set, unless you'd like to leave it open a bit longer for further review.

In T266904#6907143, @aaron wrote:

About how large is the IP list that will be stored in cache?

Declining for now per:

PR merged, resolving for now.

Leaving this task open for now since the patch did not cleanly apply to REL1_31 and REL1_35, if it even will at all.

In T277009#6903536, @IN wrote:

I think this task should be a feature request, not a security issue. Can someone change it to FEATURE?

In T269153#6896577, @LarsWirzenius wrote:

I would skip the test step ("git apply --check --3way") that we currently do. It's somewhat inappropriate as it doesn't handle the case of patches building on top of each other.

For "scap test-patches" do the same, except for each repository, make a local clone to a temporary directory, and apply the patch there. This is a more complete test than running "git apply --check", but avoids changing /srv/mediawiki-staging, possibly in a catastrophic manner.

I feel like this doesn't need a pick/deploy to wmf.34 and can wait until next week, unless anyone has more serious concerns.

So for REL1_35, 2.7.4 is the minimum safe version to address the sml CVE? Just wondering if there was any other reason not to bump to 2.8.0 like master.

In T277009#6901240, @DannyS712 wrote:

Untested, but makes sense - assuming that Jenkins wouldn't object, +2 from me - not sure if this needs to be deployed as a security patch or can go through gerrit, I think gerrit would be fine (please add me as a reviewer if done on gerrit)

This will be backported to master once the change set above ^ is merged.

This will be backported to master once this change set is merged: https://gerrit.wikimedia.org/r/670308

As @Aklapper mentioned above, I'm not sure how w.wiki fits into this alleged attack vector. It seems like iabot allows for any arbitrary returnto value, which is what should likely be addressed via an allow list, if the code maintainers so choose.

In T276852#6893765, @sguebo_WMF wrote:

• I think I still need to ping a Phab admin to add me to acl*security_team

In T276843#6893660, @Legoktm wrote:

Given that REL1_31 is on such an old version I think we could just disable sml rather than risk a bunch of potentially breaking changes.

In T269291#6887593, @Jdlrobson wrote:

Just wanted to check in on this one given my target deployment date has passed. No urgency from my side, but I'd like to have a clearer idea on when I can expect to schedule this work.

Mitigation plan (and related subtasks) appear to be created and are being worked upon. This review has also been added to the current risk register. I'm going to resolve this task for now. Thanks, everyone.

@santhosh - thanks for performing this analysis. I think adding @Reedy and myself to any related gerrit change sets where these artifacts might be committed would also be helpful, so that we can perform a security-focused analysis similar to the one performed for this WVUI change set. Thanks.

Holding for the next security release (T270458) - please keep this task private for now. Also tracking as a current production security patch (T276237).

Hello @Gilles and @aaron - I just wanted to see if there was an updated estimated completion date for this review. I wouldn't say that this review is urgent, but if it might not be completed this quarter or next, then I'll want to plan around that information. Thanks.

In T264798#6859999, @daniel wrote:

Tagging the Security-Team to chime in on priority

Stalled on wmfcloud memory issue (see pull request).

This project is for tracking anything related to security awareness training. I'm not entirely sure how useful it is as a Phabricator project since, for now, most of this training is managed internally for Wikimedia Foundation staff. At some point this may become a larger offering to community members, etc. but we aren't quite there yet. Also - @chasemp left the Foundation a while ago and has not really been an active volunteer since.

In T275669#6862906, @Urbanecm wrote:

Merged them.

I kept these as separate patches for the backports so as to (hopefully) make reverting the first patch easier, if and when that's needed. These don't cleanly apply to REL1_35 and REL1_31, mainly due to directory/file name refactoring, but I can work on new patches for those, post them here and then push them up to gerrit for review/merge.

In T275704#6861757, @Urbanecm wrote:

I can add a query to detect whether there are any broken entries, to prevent going it through everything.

+1 to the updated patch above, I assume that'll go through gerrit once T275669 is public (which I plan to do today, along with the backports). Do we have any idea what other projects this might need to be run on besides loginwiki, testwiki and enwiki?

+1 to the patches above. I assume Linker::userLink( $row->cul_target_id, $row->cul_target_text ) in LogPager doesn't need a trim because of https://gerrit.wikimedia.org/g/mediawiki/core/+/21ab535b83b97866cb9b79dcede95e8b7c32858f/includes/Linker.php#914. I guess feel free to deploy these unless you want @Reedy or I to do so instead.