search

miyagawa / cpanminus

cpanminus - get, unpack, build and install modules from CPAN
http://cpanmin.us
746 stars 213 forks source link

Incomplete fix for the signature verification vulnerabilities #639

Closed thoger closed 2 years ago

thoger commented 2 years ago

A set of CHECKSUMS files signature verification issues were recently reported by Stig Palmquist:

https://blog.hackeriet.no/cpan-signature-verification-vulnerabilities/ http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

The following fixes were applied to Menlo-Legacy in response to this report:

https://github.com/miyagawa/cpanminus/commit/98f43b64165a54e05ce25f9de09284ccb34f4776 - corrects Module::Signature::_verify() return value check https://github.com/miyagawa/cpanminus/commit/3c93db75ccbc75c813c7f12ea0301af20a265f65 - adds support for checking cpan_path attributes now used in CHECKSUMS files

However, the first fix does not sufficiently address the attack vector described in the original report where extraneous $chksum data is added to the CHECKSUMS file before the actual signed content, i.e. before the BEGIN PGP SIGNED MESSAGE. The reason for that is that GPG only verifies the content between BEGIN PGP SIGNED MESSAGE and BEGIN PGP SIGNATURE, and ignores everything before the message BEGIN separator or after the signature END separator. However, verify_checksum() reads the whole CHECKSUMS file an processes usigned content as well.

It seems CPAN.pm author decided to fix this by running GPG again as gpg --verify --output $tmpfile $CHECKUMS_file, which makes gpg write only signed and verified content to a temporary file and read that instead of the full original CHECKSUMS file. Relevant CPAN.pm commits:

https://github.com/andk/cpanpm/commit/46fe910becd5746adca92e18660567c9e8d37eb5 https://github.com/andk/cpanpm/commit/7f9e5e8c52f535c1c13e177595a5ef4710c72058 https://github.com/andk/cpanpm/commit/c03257dbebccd4deeff1987d5efd98113643f717

miyagawa commented 2 years ago

See #638 - the plan is to deprecate and remove this feature, so as not to give the false sense of security by working around the issue, and the recommendation has been and always will be to use the trusted CPAN source (www.cpan.org, etc) over HTTPS.

thoger commented 2 years ago

I assume that means wontfixing this report. Or is it being kept open for a reason?