8 ms·

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record i

by jeswin 6y ago

Javas FQDN model is actually pretty bad in practice. Domain names change quite often (I've seen many packages with a dead FQDN), and relying on the TXT record is going to be a security nightmare even worse than the username/password required by npm (since domains expire).

kasperni 6y ago
You only need to validate the domain once using a TXT record. And then you use another authentication mechanism such as a username/password combination.
brabel 6y ago
> Javas FQDN model is actually pretty bad in practice Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.
- littlestymaar 6y ago
  > Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... Oh yes, the differences is necessarily explained by Maven design being better, and absolutely not because there are two orders of magnitude difference in usage between these two systems… There are supply chain attacks in Maven Central too[1], but it's not gonna make the front page of HN… [1] a quick ddg search, just last month https://securityboulevard.com/2021/01/sonatype-stops-software-supply-chain-attack-aimed-at-the-java-developer-community/ https://securityboulevard.com/2021/01/sonatype-stops-softwar...
  - syjer 6y ago
    You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice). To be noted, it makes this kind of attack more difficult, but not impossibile. Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.
  - avereveard 6y ago
    apples and oranges, the name conflict was perfectly disambiguated by the use of the mandatory group identifier. npm design was so bad that you could at the beginning upload over an existing version of your package name and break dependencies retroactively even to people that pinned versions. if you want to try some good old whataboutism, at least try to be in the same ballpark.
    - littlestymaar 6y ago
      Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front. Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java for work, the main security feature against supply chain attack was: “we are getting .jar files individually and not using maven because it's a fucking mess” [1]: not implementation, which is what's make npm arguably a pile of shit
      - stuff4ben 6y ago
        Maven is ubiquitous in the Java world and the de-facto package/dependency management system out there. Has been since the mid-2000's and as of 2018 when I last did Java development (Scala really), it is still widely in use. Getting jar files manually would have me running from whatever company that was doing that. Let me guess, they wrote all their code in Notepad because IDE's are a "fucking mess" too right?
        littlestymaar 6y ago
        You vastly underestimate the level of bureaucracy that can exist in the biggest Java users of this planet (namely banks and public administrations): in these organization (at least a few years ago, the Solarwind attack shows it may not be the case anymore) every single dependency you want to use must be justified, and then is audited by a dedicated team, which ends up handing you the validated .jar. It was a common development practice in these entities (I was working as a contractor, for different customers), most of them have been using computer programs at there core long before the internet went mainstream.
  - oauea 6y ago
    That issue isn't even remotely similar, it's just someone uploading new packages and some people choose to use those instead of the official ones, god knows why. It didn't get pulled in automatically for existing projects. Also, it's cute how you think maven is used orders of magnitude less. Sure, the build systems probably won't CONSTANTLY be redownloading all the modules like NPM does, instead they keep a cache, but come on.
- zaarn 6y ago
  Why would it be infinitely harder to obtain log5j.com compared to typosquatting on npm? .com domains aren't THAT expensive.
  - tl 6y ago
    log5j.online is on sale for $5 / month. What's the expected ongoing cost of a package? If it's $0, then it's literally infinite. At $0.01 / month it's merely 500x more expensive. The real cost is somewhere in-bewteen.
    - zaarn 6y ago
      That's cost, not how much harder it is. Buying a domain is a few clicks and costs little money.
  - didibus 6y ago
    Normally when people squat they squat like 20+ variations of the name. So that would start to add up to hundred of dollars. Also, having the domain doesn't make it available on Maven Central. You need to apply to have your domain become a registered groupID on it. This is a manual review process. They validate your domain through TXT verification to make sure the requester to create the group is the domain owner. Then they look to make sure the library is packaged to it. And finally there's a check that the groupID isn't too similar to any existing ones in name, especially to popular ones. This generally takes 3 to 7 days to get approved. Once you have a groupID you can release many libraries under it, you don't have to go through that process again. Now from the user side, things are simpler too, because every lib has a groupID ownership and the lib name. Similar to how on GitHub you have owner/repo. So it's much easier for me as a user not to confuse org.apache/Log4J with org.malware/Log4J And like I said, even if someone owned the domain apoche.org they most likely wouldn't get approved to register org.apoche on Maven, because the name is too similar. It still isn't fool proof admittedly. But it seems much harder to manipulate. And especially if you're a careful user, much easier to trust the source. As long as you got the groupID correct, it's signed and validated. And you can be sure that what you found on apache.org is going to be org.apache on Maven. Finally, even if the domain changes hands, it doesn't matter. You won't be given access to the Maven repo. Access is given to the Maven user account who registered the group. All you need is to own the domain when you create your groupID. Now if someone transfers their Maven user/pass to a malicious users or become malicious themselves you're still at risk. Also, I believe there is an appeal, again manually reviewed, like in case you believe your account was stolen, where if you can prove that you own the source repo and/or domain and all they might reinstate you. But also artifacts are signed, so if your account gets stolen, the thief would need to steal your signature too so it can publish malicious artifacts to the Maven repo.
tarruda 6y ago
I believe the TXT record validation is only an additional measure, eg to prevent a random developer from registering/uploading a package like org.apache.http2. Surely other authentication methods are used in practice. I find it hard to believe any high profile organization would allow their domains to expire, or else they would also lose e-mail and websites, right?
- chmod775 6y ago
  > I find it hard to believe any high profile organization would allow their domains to expire Off the top of my head I remember both Microsoft (hotmail.co.uk) and Foursquare forgetting to renew their domains.
  - ric2b 6y ago
    And a few years ago some guy was able to buy google.com for a few minutes or hours, I don't quite recall.
didibus 6y ago
Hum... I think you're misunderstanding something. You have a username/password to Maven Central and you also have a private key to it. But in order to be granted a groupID (think of it as an account), you need to prove at the time of account creation that you own the domain that matches the groupID (think account name). So if you try to register com.foo on Maven Central, at that time you need to own foo.com, otherwise you'll be rejected. If you do own it at that time, well your account is approved and now you have a username/password to it and a private key you need to use to sign artifacts when you publish them. If your domain expires and is later bought by someone else, that doesn't make them the new owner of your Maven Central groupID.

by jeswin 6y ago

kasperni 6y ago

You only need to validate the domain once using a TXT record. And then you use another authentication mechanism such as a username/password combination.

brabel 6y ago

> Javas FQDN model is actually pretty bad in practice Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... oh, wait?! NO! The kind of simple attacks you see routinely on npm (typo squatting, ownership transfers to malicious authors, now this) just doesn't happen on Maven Central at all.

littlestymaar 6y ago
> Right, that's why we see this kind of attack all the time on Maven Central, but never on npm... Oh yes, the differences is necessarily explained by Maven design being better, and absolutely not because there are two orders of magnitude difference in usage between these two systems… There are supply chain attacks in Maven Central too[1], but it's not gonna make the front page of HN… [1] a quick ddg search, just last month https://securityboulevard.com/2021/01/sonatype-stops-software-supply-chain-attack-aimed-at-the-java-developer-community/ https://securityboulevard.com/2021/01/sonatype-stops-softwar...
- syjer 6y ago
  You may notice that in the linked article, only the artifact id has been spoofed. In maven you need to declare both groupId and artifactId for your dependency (and a fixed version, a range is generally considered a bad practice). To be noted, it makes this kind of attack more difficult, but not impossibile. Especially the mix public/private artifacts. I guess it will force a lot of companies to at least lock their groupId on maven central, if they never bothered to do so.
- avereveard 6y ago
  apples and oranges, the name conflict was perfectly disambiguated by the use of the mandatory group identifier. npm design was so bad that you could at the beginning upload over an existing version of your package name and break dependencies retroactively even to people that pinned versions. if you want to try some good old whataboutism, at least try to be in the same ballpark.
  - littlestymaar 6y ago
    Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front. Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java for work, the main security feature against supply chain attack was: “we are getting .jar files individually and not using maven because it's a fucking mess” [1]: not implementation, which is what's make npm arguably a pile of shit
    - stuff4ben 6y ago
      Maven is ubiquitous in the Java world and the de-facto package/dependency management system out there. Has been since the mid-2000's and as of 2018 when I last did Java development (Scala really), it is still widely in use. Getting jar files manually would have me running from whatever company that was doing that. Let me guess, they wrote all their code in Notepad because IDE's are a "fucking mess" too right?
      - littlestymaar 6y ago
        You vastly underestimate the level of bureaucracy that can exist in the biggest Java users of this planet (namely banks and public administrations): in these organization (at least a few years ago, the Solarwind attack shows it may not be the case anymore) every single dependency you want to use must be justified, and then is audited by a dedicated team, which ends up handing you the validated .jar. It was a common development practice in these entities (I was working as a contractor, for different customers), most of them have been using computer programs at there core long before the internet went mainstream.
- oauea 6y ago
  That issue isn't even remotely similar, it's just someone uploading new packages and some people choose to use those instead of the official ones, god knows why. It didn't get pulled in automatically for existing projects. Also, it's cute how you think maven is used orders of magnitude less. Sure, the build systems probably won't CONSTANTLY be redownloading all the modules like NPM does, instead they keep a cache, but come on.
zaarn 6y ago
Why would it be infinitely harder to obtain log5j.com compared to typosquatting on npm? .com domains aren't THAT expensive.
- tl 6y ago
  log5j.online is on sale for $5 / month. What's the expected ongoing cost of a package? If it's $0, then it's literally infinite. At $0.01 / month it's merely 500x more expensive. The real cost is somewhere in-bewteen.
  - zaarn 6y ago
    That's cost, not how much harder it is. Buying a domain is a few clicks and costs little money.
- didibus 6y ago
  Normally when people squat they squat like 20+ variations of the name. So that would start to add up to hundred of dollars. Also, having the domain doesn't make it available on Maven Central. You need to apply to have your domain become a registered groupID on it. This is a manual review process. They validate your domain through TXT verification to make sure the requester to create the group is the domain owner. Then they look to make sure the library is packaged to it. And finally there's a check that the groupID isn't too similar to any existing ones in name, especially to popular ones. This generally takes 3 to 7 days to get approved. Once you have a groupID you can release many libraries under it, you don't have to go through that process again. Now from the user side, things are simpler too, because every lib has a groupID ownership and the lib name. Similar to how on GitHub you have owner/repo. So it's much easier for me as a user not to confuse org.apache/Log4J with org.malware/Log4J And like I said, even if someone owned the domain apoche.org they most likely wouldn't get approved to register org.apoche on Maven, because the name is too similar. It still isn't fool proof admittedly. But it seems much harder to manipulate. And especially if you're a careful user, much easier to trust the source. As long as you got the groupID correct, it's signed and validated. And you can be sure that what you found on apache.org is going to be org.apache on Maven. Finally, even if the domain changes hands, it doesn't matter. You won't be given access to the Maven repo. Access is given to the Maven user account who registered the group. All you need is to own the domain when you create your groupID. Now if someone transfers their Maven user/pass to a malicious users or become malicious themselves you're still at risk. Also, I believe there is an appeal, again manually reviewed, like in case you believe your account was stolen, where if you can prove that you own the source repo and/or domain and all they might reinstate you. But also artifacts are signed, so if your account gets stolen, the thief would need to steal your signature too so it can publish malicious artifacts to the Maven repo.

tarruda 6y ago

I believe the TXT record validation is only an additional measure, eg to prevent a random developer from registering/uploading a package like org.apache.http2. Surely other authentication methods are used in practice. I find it hard to believe any high profile organization would allow their domains to expire, or else they would also lose e-mail and websites, right?

chmod775 6y ago
> I find it hard to believe any high profile organization would allow their domains to expire Off the top of my head I remember both Microsoft (hotmail.co.uk) and Foursquare forgetting to renew their domains.
- ric2b 6y ago
  And a few years ago some guy was able to buy google.com for a few minutes or hours, I don't quite recall.

didibus 6y ago

Hum... I think you're misunderstanding something. You have a username/password to Maven Central and you also have a private key to it. But in order to be granted a groupID (think of it as an account), you need to prove at the time of account creation that you own the domain that matches the groupID (think account name). So if you try to register com.foo on Maven Central, at that time you need to own foo.com, otherwise you'll be rejected. If you do own it at that time, well your account is approved and now you have a username/password to it and a private key you need to use to sign artifacts when you publish them. If your domain expires and is later bought by someone else, that doesn't make them the new owner of your Maven Central groupID.