cpan/cpanm integrity and authenticy checks concerns

hrcerq has asked for the wisdom of the Perl Monks concerning the following question:

Hello, friends of the Monastery.

I'm not (yet) making heavy use of cpan or cpanm tools, and I'm still getting used to them.

Until now, every module I needed I could obtain from operating system repositories. Naturally, these repositories aren't nearly as comprehensive as CPAN as whole, they offer just a small subset of it, so it's just a matter of time until I need to obtain something using cpan/cpanm.

Not that it's a difficult task, but I have some security-related concerns. I'll explain:

According to CPAN module docs:

CPAN supports digital signatures;
however, these are not enforced on new modules;
beyond that, signature checks are disabled by default;
also, for it to be enabled, additional modules are needed (Module::Signature, specifically, and maybe Crypto::OpenPGP, if the gpg program is not available);
and finally, access to the keyservers is expected.

According to cpanm utility docs:

the --verify flag may be used to perform integrity and authenticity checks if checksum and signature files are available;
what happens if these files are not available is not clear (is the installation process aborted?);
again, this option is disabled by default.

A more security-aware developer might want to enable check_sigs flag on cpan or use --verify on cpanm, and install appropriate modules (for cpan), but how many will even consider this? Security is often complex by itself and when it's opt-in, it has a great chance of being overlooked. Not to mention there's not much to do if the module you need wasn't even signed to begin with.

Personally, I take it as a serious threat to CPAN ecosystem. Considering how many mirrors there are out there, I believe it's too much a surface attack to be covered without using crypto signatures. Without it, it might be very difficult to determine if some package on any of the mirrors wasn't tampered at some point in time.

I know this is a very long question, but I had to provide some context (so thank you if you got this far). So, here's my question: am I exaggerating, is there anything I'm not aware of? As I said, I'm not entirely familiar with cpan/cpanm, and I hope this community might provide some insight on this matter.

return on_success() or die;

Comment on cpan/cpanm integrity and authenticy checks concerns

Replies are listed 'Best First'.
Re: cpan/cpanm integrity and authenticy checks concerns by Anonymous Monk on Jul 12, 2021 at 07:01 UTC
You're right, but here's the problem: on the Internet, everyone is an Alice. It's not an Alice and Bob situation where they can engage in some trade-craft and exchange their public key fingerprints during a dinner date because they know each other. If we drop the keyserver access requirement, what's to stop an evil mirror from creating a key pair in the name of the module developer and signing an evil module just for you?	[reply]
Re^2: cpan/cpanm integrity and authenticy checks concerns by hrcerq (Scribe) on Jul 12, 2021 at 23:37 UTC
Indeed, the keyserver has a very important role here (at least while OpenPGP is the chosen approach). I actually believe this part is all right as long as Internet access is avaiable. But my point is that security is not enforced in any way. Seems almost like it's an afterthought. And actually, I think there might be some workarounds (some with OpenPGP, some with other approaches): With OpenPGP approach, maybe some keys from known developers could be shipped together with perl (or maybe in separate packages depending on the operating system). These keys take some time to expire, and could be used to check for new other keys, in a Web of Trust; Outside of OpenPGP approach, however, there are options too. For instance, I like OpenBSD's approach, with signify . Every OpenBSD release contains the key necessary to verify the next release, so indirectly every new key is signed by its predecessor. Maybe this could be applied to every Perl distribution, in the sense that every distribution comes with the necessary key for the next version. That way, at least every update will be safe. It's worth noting these keys are relatively small (thanks to ED25519 algorithm), so shipping them is cheap. That way, only the first install would be unsafe, and a compromised key could be easily detected during updates. I know crypto solutions are not trivial, but I believe there are options. I completely agree with the idea of giving choice to the users, but I think security should be opt-out, not opt-in. return on_success() or die;	[reply]
Re^3: cpan/cpanm integrity and authenticy checks concerns by eyepopslikeamosquito (Archbishop) on Jul 13, 2021 at 02:18 UTC
I agree. This seems to be a hard problem, and broader than Perl's CPAN. PyPI , RubyGems, and Npm, for example, all face similar problems: Malicious modules made it into official PyPI repository Backdoored Ruby gems stole credentials, injected cryptomining code NPM blog on malicious modules Typosquatting package managers blog OT. Malicious software in PyPI by parv (2021) (Update) Malicious module on CPAN by choroba (2020) (Update) sometimes no Perl news is good news by zentara (2021) (Update) CPAN clients exposed to sig-related vulnerabilities by hippo (2021) (Update) Signature Verification Vulnerabilities in CPAN.pm, cpanminus and CPAN::Checksums - Hackeriet blog (Update) Addressing CPAN vulnerabilities related to checksums - blog by Neil Bowers (Update) Re^7: Meaning of XS object version (CPAN and Package Manager Security References) by me (2023) (Update) It might be interesting to compare (and learn from) the security approaches taken by each of these similar mature open source repositories. Update (2023) > I'm not (yet) making heavy use of `cpan` or `cpanm` tools, and I'm still getting used to them In case it helps, a detailed example of installing modules from CPAN securely on Linux, using `cpan` and `cpanm`, can now be found here. Thanks to your question, I now keep a long list of Security References (don't want to disappoint the LanX ;-): Re: Security techniques every programmer should know (Security References)	[reply] [d/l] [select]
Re^3: cpan/cpanm integrity and authenticy checks concerns by Anonymous Monk on Jul 14, 2021 at 16:31 UTC
Thanks for the idea. Shipping a root key with Perl and signing (perhaps via a few intermediaries) the developers' keys with it to let them sign their distributions would solve part of the Alice problem by providing a way for the user to verify that the package has been signed with a key known to the owner of the key (CPAN) which was signed by the root (Perl) key. I agree that having this system is better than not having a way to validate a developer's key and that this should protect from the evil mirror problem if the existing Perl installation is clean (and that latter assumption we just have to trust, see "Reflections on trusting trust" by Ken Thompson). The current situation can be somewhat circumvented by only downloading packages from `https://cpan.org/authors/id/...` (effectively limiting oneself to a single mirror, which doesn't quite scale, and having to trust the HTTPS PKI, which is arguably not as good as a dedicated Perl PKI). It should also be noted that typical supply chain attacks on modules involve typosquatting and taking over unmaintained modules, which, aside the author's public key visibly changing, wouldn't raise any louder alerts: the attacker would look the same as any other CPAN citizen, but the signed code supplied by them would also be malicious. But that's a social problem, likely impossible to solve by purely technical means.	[reply] [d/l]
Re^4: cpan/cpanm integrity and authenticy checks concerns by Anonymous Monk on Jul 14, 2021 at 19:31 UTC
Re^5: cpan/cpanm integrity and authenticy checks concerns by hrcerq (Scribe) on Jul 15, 2021 at 00:49 UTC


Pathologically Eclectic Rubbish Lister
	PerlMonks