Home: When downloading a package, the expected package ID and version should be asserted

[joelverhagen]

Consider the following scenario.

1. All packages on NuGet.org must have a repository signature (i.e. new packages get signed)
2. A malicious actor has hacked into NuGet.org and has the ability to mutate blob storage.
3. The hacker submits EvilNewtonsoft.Json 9.0.1 with some virus in it.
4. Hacker waits for the package to become available on NuGet.org.
5. Hacker replaces the blob of Newtonsoft.Json 9.0.1 with EvilNewtonsoft.Json 9.0.1.

Other customers will restore Newtonsoft.Json 9.0.1 and NuGet.org will happily hand the blob it thinks is Newtonsoft.Json 9.0.1 back to the customer.

To solve this, NuGet.org certainly needs to be running consistency checks against its packages to detect such problems. However suppose the monitoring is not instance (it can't be, realistically). This means some customers will still be impacted.

Client code should verify that the ID and version of the package downloaded matches what is expected. This, in addition to repository signature integrity checks, will ensure the client is getting the correct, untampered package.

[joelverhagen]

/cc @skofman1 @loic-sharma

[PatoBeltran]

@joelverhagen do you think this has been solved with repository signing and client policies? (cc. @dtivel )

[joelverhagen]

No, in my scenario the malicious actor takes a repository signed package from the very same repository and replaces his target.

[PatoBeltran]

I see, nevertheless, if the package is author signed, the malicious actor will not be able to impersonate the author signature, so if the user has signatureValidationMode=require and explicitly trusts Newtonsolft.Json's author this scenario wouldn't be an issue.

[joelverhagen]

Yes, any policy on author signature should prevent this from happening. That being said, this is not the default (right?) so we should protect the majority case with an ID/version verification.

[dtivel]

I think NuGet should perform this validation even if a package is unsigned. If a package is signed, we should perform integrity checks before this verification is performed, but the verification described in this issue is independent of signed package verification.