I did an initial security assessment of this service from the angle of how great the concern is around the security of the module it replaces (service-runner) and just taking an initial look at the service itself from a security perspective.

@Aprum is working on an new rapid assessment process that would allow us to unblock this ticket, we are hoping to get this done by next week.

Is there a target date for deployment? We are trying to decide on priority as we are developing a new process that would help us expedite tickets like this in future, but don't yet have it and are working on developing it.

Hey @mpopov when do you need this done by? We're caught a little between developing a new process that would allow us to expedite approvals like this in future, and whether we need to special case high priority tickets for now with the old or interim process which will take time away from developing the new process.

Maryum gave me a link to the previous service runner: https://github.com/wikimedia/service-runner

Thanks, we should get legal to review the terms before we agree to anything aswell: https://www.cve.org/Legal/TermsOfUse

I think if we aren't sure or there's no easy way to do an IP address restriction, we can skip it as this is low risk.

Thanks @EBernhardson for the productive and interesting meeting yesterday.

Thank you very much, I sent a calendar invite.

I have a plan for fixing this. This is just some notes for myself

• Add myself to the Privacy Engineering phabricator project so that I (hopefully) get emails for any new task
• Setup a gmail rule to forward these emails to Asana
• Document the above process so it could be run by any team member in future by adding themself to the project and configuring the same gmail rule

I'm going to pick this up initially to help prioritize. @EBernhardson would it make sense for us to have an initial meeting to get a sense of the risk involved? Anyone else to invite on your side. I'll invite some folks from product security

@mmartorana could this be actioned since the approval was given?

Regarding this ticket, I would recommend syncing with @MoritzMuehlenhoff as I believe he had ideas and thoughts for scanning and updated running containers. This is different to CI of course, but would be good to be aware and plan the overall approach together.

I like these headings, thank you.

I did create some hacky code that may help, it queries the API for each wiki to determine deployment status of skins/extensions. https://gitlab.wikimedia.org/acooper/extusage. There is a dump from the historical data in october here: https://docs.google.com/spreadsheets/d/1SBU6sPHSrkWmxLbMaUu1WoEVEPVQTmSHUgo_DVT7c4c/edit?usp=sharing

Namely or just the gmail synced address book.

You could also require messages of acknowledgement to be sent across at least two authentication domains to increase the security. So say a slack message (linked in a phab comment) and a phab comment.

Oh and all that is required is for the verifier to also post a message authenticated to their accounted confirming they have verified the identity. The verifier in this case is someone from the persons team or management chain. So its not a fixed identity.

I was assuming finding the person would be easy - it would be maybe their manager? Which is easily available from the address book.

We have concerns that the following code snippet from this feature contains a XSS that might be triggered by a malicious link opened by a user:

On review of the available penetration testing evidence from the vendor it was confirmed appropriate independent testing had taken place and we have now downgraded the risk to medium.

I had another thought about this requirement. Besides the higher level organizational header names, it would be helpful if the risk of those columns could be collectively expressed by a single value.

I'm currently in some discussions with Greg about how to handle the potential risk in this component. Will update the ticket when we have reached a decision on what to do next. For now we will pause the security review until this is decided.

It appears this issue has been (perhaps unintentionally) publically disclosed at https://fluidattacks.com/advisories/blondie/. @sbassett has asked legal to assistance with how to respond regarding the disclosure.

There is also a separate issue which is a configuration based Remote Code Execution vulnerability in the superset.wmcloud.org instance (not the superset.wikimedia.org instance), caused by the use of a guessable secret key in the Flask superset configuration as described in this article: https://www.horizon3.ai/cve-2023-27524-insecure-default-configuration-in-apache-superset-leads-to-remote-code-execution/

I followed these instructions already which requested rsa type (maybe worth updating the instructions if ed25519 is preferred now?)
https://wikitech.wikimedia.org/wiki/Yubikey-SSH

Thanks I added the SSH key.