Cpanminus HTTP defaults leave downloaded code open to substitution

A package installer has to obtain code before it can build or test it. If that download travels over unauthenticated HTTP, a network attacker can substitute the code that reaches those later stages. Running a distribution's tests does not establish that the distribution came from the intended source. The attacker can replace the tests along with the implementation.

The CPANSec advisory, initially published on 26 August and updated with the CVE reference on 27 August, identifies that problem in cpanminus's defaults. CVE-2024-45321 concerns downloading and installing CPAN code over insecure HTTP without an integrity check that establishes the expected code. The advisory says an upstream patch is not yet available and provides configuration-based mitigations.

I value CPAN as an established way to reuse Perl modules. That makes the download policy consequential even for a language I often use for small, one-off programs. A short script can depend on installed code, and the trust placed in that code begins before its first use statement.

The default predates the advisory

The discussion did not begin this week. Issue 611, opened in June 2020, asks about moving package and metadata downloads to HTTPS, verifying certificates and checking signatures. Those are related protections, but they answer different questions. Choosing an HTTPS URL alone is not a complete description of how a client verifies the response.

The April 2024 proposal is more directly focused on cpanminus's defaults. Its author reports HTTP downloads even on a system with working TLS and proposes HTTPS endpoints while retaining explicit HTTP overrides. The proposal's existence establishes that a concrete default change was available for discussion before the advisory. It does not establish that users of a released executable have received it.

The 1.7047 executable and embedded documentation make the older default visible. Its mirror option documents http://www.cpan.org/ as its default. The executable also contains the implementation and its dependencies in a single distributed file. An installed copy can therefore retain its own endpoint choices even when another part of the machine's Perl environment changes.

That packaging detail matters for remediation. A change in a repository does not update a copied executable. Similarly, changing a separate HTTP library does not automatically rewrite the endpoints embedded in the installer. The relevant question is which executable a particular invocation runs and which source policy that executable selects.

An exclusive mirror changes both lookup and download

The advisory's simplest mitigation uses --from with an HTTPS mirror. The option chooses the supplied mirror and its index as the only source for searching and downloading modules. That exclusive behaviour is important, because the goal is to replace the default lookup and download path.

cpanm --from https://www.cpan.org Try::Tiny

The module name here is an illustrative installation target. The significant part is the explicit source option. It requests the HTTPS mirror in the form described by the advisory, without requiring the user to edit a fatpacked executable.

The embedded cpanminus documentation distinguishes --from from --mirror. A mirror option appends a URL to the list of mirrors. The --from option replaces the list and combines mirror selection with mirror-only lookup. Those operations do not express the same policy, even if they mention the same hostname.

Mirror-only lookup obtains the mirror's package index instead of querying the CPAN Meta DB. That matters because distribution selection involves metadata as well as an archive. A policy that protects only the archive location can leave earlier decisions dependent on another source. The exclusive option gives the mitigation a defined scope across the index and module download described by the documentation.

Persistent options need a defined execution environment

The advisory also recommends PERL_CPANM_OPT for a persistent default. Cpanminus documents that environment variable as a set of default options used for each invocation. A single command can supply it without changing the surrounding interactive shell configuration.

env PERL_CPANM_OPT='--from https://www.cpan.org' cpanm Try::Tiny

This example applies to the invoked process. A shell startup file, a build job and a container recipe can each establish a different environment. Configuring one of them does not prove that the others use the same options. The location where cpanminus runs is therefore part of the practical scope of the mitigation.

The cpanminus documentation says command-line options override the environment defaults. That is useful for intentional configuration, but it also means the variable is a default rather than an enforced restriction on every possible invocation. A command that explicitly selects another source is making another choice. Automation needs its effective arguments read together with its environment.

There is also a difference between configuring future installations and establishing the origin of code already installed. The mitigation changes the source of subsequent requests. It does not retrospectively authenticate the bytes obtained during a previous HTTP session. That follows from the problem the advisory describes, since the missing evidence concerns the transfer that already took place.

The mirror option has a compatibility cost

The advisory notes that selecting --from disables support for downloading old releases from BackPan and development releases. That is a meaningful tradeoff for workflows whose dependency requests extend beyond the selected mirror's normal index. An installation that needs such a release can fail after adopting the mitigation even though the HTTPS endpoint is reachable.

That failure should be understood as a consequence of the chosen source policy. The option deliberately narrows where the installer searches. Treating it as a network problem would miss the reason the requested distribution is unavailable through that path. The advisory gives another mitigation for users who need to retain those capabilities.

Its second approach patches the HTTP endpoints inside the executable to HTTPS. The listed endpoints include BackPan and metadata services, as well as the normal CPAN mirror. The advisory explains that this retains support for the old-release and development-release paths affected by the exclusive-mirror option.

Editing a distributed executable introduces a different maintenance obligation. The local change must remain attached to the executable that automation actually invokes, and replacing that file can replace the change as well. This is an operational consequence of carrying a local modification, separate from the transport protection that the modification supplies.

I prefer the explicit source option where its narrower discovery behaviour fits the job. It is readable at the call site and expresses a concrete choice. For a workflow that requires historical or development releases, that preference has to accommodate the capability the option removes.

A useful distinction for dependency policy is whether a setting identifies the requested package or identifies where the installer may obtain it. A package name can remain identical under two invocations that consult different metadata and download endpoints. Conversely, using an exclusive mirror can change which releases are discoverable without changing the package requested at the command line. Reading both choices together explains the compatibility tradeoff in the mitigation. The name alone does not describe the transfer, and the transport option alone does not specify the release that the project intends to consume.

Transport and package identity are separate questions

HTTPS protects the connection to the selected endpoint when the client verifies that connection correctly. It does not by itself assert that the package's author is trustworthy or that a particular release contains no malicious logic. The issue discussion's separate questions about signatures and certificate verification reflect those different responsibilities.

A checksum has a related limitation when the checksum and archive arrive through a channel an attacker can replace. Comparing the two can detect an accidental mismatch without establishing whose expected value the client used. The advisory classifies the vulnerability around downloading code without an integrity check, which is why the source of the expected information matters alongside the calculation itself.

The immediate scope is consequently specific. An attacker capable of changing the insecure download can influence code that the installer will process as a distribution. This does not require a defect in a module's runtime parser or an application accepting a crafted document. The installation channel itself supplies the substituted input.

The earlier spreadsheet advisories concerned libraries interpreting hostile documents. Here the package manager is obtaining the libraries. They occupy different stages of the same dependency lifecycle, and a fix for one does not address the other. For existing cpanminus users, the advisory supplies a source restriction that can be applied now, with a documented alternative when the exclusive mirror would remove required release-discovery behaviour.