MavenGate claims that some Maven namespaces (for example nl.grons, the namespace I control) are vulnerable to hijacking. If I understand it correctly, the idea is that hackers can place a package with the existing or newer Maven coordinates in the same, or different Maven repository, thereby luring users into using a hacked version of your package. Sounds serious, and it probably is.
However, they then went on to create a list of Maven namespaces that are vulnerable. Unfortunately, they do not say what criteria were used to put namespaces on this list. Is it because the associated DNS domain expired? Because the DNS domain moved to a different owner, or only to another DNS registrar? Is it because the PGP key used to sign packages is not on a known server? Or something else entirely? For some reason my namespace ended up on the list, even though I never lost control of the DNS domain and strictly follow all their recommendations.
Even more unfortunately, this is not even the right way to look at the problem. It is not the namespaces that are vulnerable, it is the Maven repositories themselves! It is the Maven repositories that are responsible for checking the namespace against ownership of the associated DNS domain and link that to a PGP key. Once the key is linked to the namespace, packages signed with a different PGP key should not be accepted. Any exceptions to this rule should be considered very carefully.
Now to my second point, how does this hurt open source? Since my Maven Central account was blocked after MavenGate, I contacted Sonatype, the owners of Maven Central. Luckily, I use Keybase and was therefore easily able to assert I am still owner of the DNS domain and the PGP key that has been used to sign packages. But then Sonatype also wrote this:
It is important to note that, even if we are able to verify your publisher authorization, security software may flag components published under this namespace. It may be worth considering registering a separate, new namespace with a clean-slate reputation.
I am just an individual publishing open source packages in my free time. IMHO it is totally unreasonable to ask people to switch to another domain because some random company on the internet suspects you might be vulnerable! Switching to a new DNS domain is a lot of work and in addition, not everyone is willing or able to bear the costs. I suspect that many people, including me, will give up rather than join a race against 'security software'.
To summarize:
- MavenGate declares Maven namespaces to be vulnerable based on unclear and probably wrong criteria.
- If this is taken seriously, the bar to publishing open source becomes so high that many will give up instead.
Note: I have tried to contact the MavenGate authors, but unfortunately did not receive a reply yet.
and once again sonatype does shitty stuff nobody wants or needs, have you tried offering them money or enterprise agreements?
ReplyDeleteThis is not Sonatype's doing. Sonatype should have checked MavenGate's arguments more carefully before blocking my account, but otherwise they were very helpful in providing information and restoring access.
ReplyDeleteThe source seems to be https://blog.oversecured.com/Introducing-MavenGate-a-supply-chain-attack-method-for-Java-and-Android-applications/. I registered to download their findings (NOTE: I think it's fairly unethical to gate security research findings on a marketing registration like this) and grons.nl is in MavenCentral_vulnerable.txt, indicating (as I read it) that they found your namespace via:
ReplyDelete> Took all the groupId values from mavenCentral and converted them to domains.
Checked these domains to see if they could be immediately purchased or auctioned using the GoDaddy Bulk Domain Search tool.
When I check your domain, GoDaddy explicitly says it's unavailable (but they do offer *.nl addresses). WHOIS data shows your DNS registration was last modified in 2022 so it seems that nothing has changed since this was published early in 2024. My assumption, without further data, would be a bug in the script they wrote to compile this, which would lead me to think there are other errors in their data as well.
Thanks for that analysis Neil. I'll use this if I can get into contact with the MavenGate authors and request to be taken off the list.
DeleteHi there, Brian Fox, Cofounder & CTO - Sonatype here.
ReplyDeleteI agree with what you wrote here. When we were contacted about Maven Gate, we pretty quickly assessed that while we could tighten up some validations on our side, a major part of the thesis was incorrect. Existing validations we had in place for Maven prevented most of the attacks, certainly the ones on existing domains. I wrote a response detailing this at the time, here: https://www.sonatype.com/sonatypes-ongoing-commitment-to-maven-central
From experience though, we know that once a vulnerability is exposed, fast follow threat actors will attempt to exploit it, which is why we flagged all the relevant domains that Maven Gate highlighted to ensure some extra scrutiny was applied to keep the ecosystem safe. It seems like perhaps the MavenGate list incorrectly flagged your domain and we didn't catch that it shouldn't have been. I apologize for that oversight, but hopefully it was a mere speed bump to get your access restored and the extra security was worth it to try and secure the supply chain.
Regarding the comment about changing your coordinates, I hadn't seen this before and I'm with you, I don't support telling everyone to change their coordinates. The intent was to let folks know that other tools might be incorrectly flagging you now as an FYI, but sounds a bit more like an admonishment. We will definitely reword this. Just because some other tool flags you with a false positive doesn't mean you need to change your name, they need to fix their tool!
I hope that helps and as always I encourage folks to reach out to be over socials or email if they have a concern. One advantage we still have with Maven Central is that there are still public people and faces who are here to make hard judgement calls when things like this happens and we don't want users to feel like just another number in the system.
Thanks Brian, that is much appreciated.
Delete