Hi, On Fri, 7 Feb 2025 at 14:52, Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > > This is an early draft of something I plan to publish for more open > source projects, but I wanted to send this out here first since I'm > more directly involved. > > Open source projects, especially widely used ones like Maven, need to > be aware of and protect against the growing risk of threat actors > actively seeking committer privileges on projects as a precursor to > installing backdoors in the source code. > > In particular, it seems that one or more nation states are playing the > long game by targeting specific open source projects. Someone (likely > a team of people) begins sending legitimate patches and PRs and > participating in the mailing lists and other fora until they earn > committer privileges. Then they insert the back door using inobvious > code, wait for it to ship, and proceed with the attack against their > targets. > > Last year xz utils was very nearly compromised in this way and only > avoided shipping with the backdoor because one engineer at Microsoft > noticed something funky in a beta release: > > https://en.wikipedia.org/wiki/XZ_Utils_backdoor > > This is not the first time this has happened, and it almost certainly > won't be the last. For all we know there could be active exploits no > one has noticed already shipped by popular open source software. > > What should Maven (and everyone else) do about this? There are a > number of things. > > Most importantly, we need to make sure that all PRs and commits are > reviewed before merge. Directly committing to master (as many people > including myself currently have the ability to do) is not safe. It > makes it far too easy to hide malicious commits. If I were an attacker > I would seek out projects like Maven that allow direct commits without > review or PRs. Every commit needs to go through code review, and we > need to enforce this at the repo level so it cannot be bypassed.
Even we don't strictly enforce PR requirements we have: - each commit is reported on ML - https://lists.apache.org/list.html?comm...@maven.apache.org - before release next version of ASF component we have a VOTE, we can check what is deliverable > > Second, we need to verify the identities of new committers. If > possible, new committers should be met in person at ApacheCon or other > convenient events. That's probably not feasible for everyone involved > in a widely dispersed project like Maven, but a quick video chat > should at least verify that a real person exists. I'm not sure how > long that's likely to help given the rapid advances in genAI > impersonation. Nonetheless, we should do what we can to establish a > chain of trust between actual human beings. > > Third, we should remove commitership from the large numbers of folks > who haven't contributed to the project for 5+ years. They can still > remain official PMC members, and can be reactivated if they one day > decide to participate again. However, right now their Github accounts > and Apache SVN credentials are extra risks we don't need. > Compromising existing committers accounts is another attack vector > that has been used in the past and will be used in the future. We have a simple statistic https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-committers-stats.html To remove somebody we need a procedure for it. > > Fourth, we should require all committer Github accounts to turn on two > factor authentication. We might already be doing this. I don't have > access to check. But if we're not, it's an easy fix to reduce the risk > of hacked and stolen Github accounts being used to compromise us. > > There's one other technical change I'd like to consider to protect > Maven users more than the Maven project itself. We should eliminate, > or at the very least warn, when version ranges are used in dependency > elements. See https://jlbp.dev/JLBP-14 for the rationale for this one. > I don't know of an attack using this vector in Java (yet) but it has > been used multiple times in other ecosystems to steal bitcoins and > install malware. Java has been lucky so far, but we are by no means > immune to it. > > There might be other things we can do to improve our security posture. > This is just what I've seen used elsewhere. Like a lot of security > measures, they're not without inconvenience, but they are necessary > given the evolving threat landscape. We've made more invasive changes > in the past to increase security, most notably requiring https for > downloading artifacts, so I'm confident we can do this too. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Sławomir Jaranowski --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
