csteipp added a comment. 1 & 2 are probably related, so I'll add some comment here. Happy to move to another forum if needed.
The threats I've seen laid out, and my (very rough) evaluation of their risk. Happy to be corrected if it seems like I have assumptions that are wrong, or you disagree with my likelihood/impact score. 1. **MITM between composer and packagist** - in my estimation, this has both High likelihood and High impact. It's a trivial technical attack to pull off without composer checking certificates, and allows the attacker to link their own, modified version of any library into the composed codebase. 1. Risk: (using high = 3, med = 2, low = 1, and risk = likelihood x impact ), then 3 x 3 = 9 2. Mitigation: Currently none (adding https certificate checking in composer and requiring all connections to be https shouldn't be too difficult to add and upstream) 2. **MITM between composer and packagist with valid packagist certificate** - In the event that composer start validating the https connection's certificate, is that enough? In my estimation, this is a fairly difficult attack to pull off, for a someone attacking the WMF's infrastructure, so I put the likelihood at Low. For normal developers running `composer update` on their laptop, this is still moderate, since buying an SSL MITM proxy that contains a code-signing certificate is fairly expensive still, so I'm going to say likelihood is Low to Medium. This has the same impact as #1. 1. Risk: Low-Medium (1.5) x High (3) = 4.5 2. Mitigation: Currently none (adding certificate pinning to composer would me moderately expensive, since it doesn't seem that composer would maintain that upstream) 3. **Github is compromised (the entire organization)** - in my estimation, compromising github would be a difficult. They have a security team that seems to be making reasonable choices currently. So I'd guess the likelihood is Low. The impact, aiui, would be High for normal composer usage (where just the tarball of a repo at a certain commit is downloaded, and does not appear to be integrity checked). If composer does get a checksum that it checks, or composer is setup to clone the repo and checkout a sha1-hash (which seems to be hard to forge), the the impact would be reduced. 1. Risk: Low (1) x High? (3) = 3? 2. Mitigation: Currently none (adding certificate pinning to composer would me moderately expensive, since it doesn't seem that composer would maintain that upstream) 4. **Packagist is compromised (the entire organization)** - Packagist concerns me a little more, since I don't know anything about their operational security. I'll do some quick research on that, or if anyone has a citation, happy to evaluate. The impact would again be High, because a attacker could add any code to any library by pointing to their own version of it. 1. Risk: ? x High (3) = ? 2. Mitigation: unknown 5. **Github repo is "compromised" by owner accepting hostile pull request** - The likelihood seems Low to me, since if we've determined the library is of sufficient quality to include in our codebase (A MediaWiki developer has decided this is a good library to include, and the library has passed security review by my team), then I (hope) it's unlikely they would accept a malicious pull request. If it did happen, impact would be High, however. 1. Risk: Low (1) x High (3) = 3 2. Mitigation: Vetting of libraries included in MediaWiki (developer review, security review), updates to vendor are code reviewed 6. **Github repo is compromised by owner having their password stolen** - Github mitigates this with things like mandatory https with HSTS, using OAuth to interact with other services, optional 2-factor authentication for accounts, review and expiration of potentially unsafe ssh keys. However, assuming may library owners are not going to take advantage of the optional security features, we can probably call the likelihood Medium, and the impact High, since it would allow the attacker to add any code to the repo. 1. Risk: Medium (2) x High (3) = 6 2. Mitigation: Updates to vendor are code reviewed TASK DETAIL https://phabricator.wikimedia.org/T105638 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki, csteipp Cc: Spage, greg, tstarling, aude, hoo, daniel, zeljkofilipin, thcipriani, mmodell, bd808, csteipp, Legoktm, Krinkle, hashar, JanZerebecki, Aklapper, Lynhg, Wikidata-bugs, Malyacko, GWicke, Qgil, P.Copp _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
