Summary:
CVE-2023-31484 is a vulnerability in CPAN.pm—the core Perl module for distribution—where versions before 2.35 did not verify TLS certificates when downloading modules over HTTPS. Let’s break down why this is dangerous, how it happens, what the code looks like, and how you can protect yourself.
What Is CPAN.pm?
CPAN (Comprehensive Perl Archive Network) is the backbone of Perl’s ecosystem. The CPAN.pm module fetches and installs Perl distributions directly from the internet.
Imagine installing Python packages using pip, but without HTTPS verification—any attacker on your network could substitute malicious code.
What Is CVE-2023-31484?
Up to version 2.34, CPAN.pm would fetch Perl modules over HTTPS, but forgot to check if the TLS certificate was legitimate. Anyone could pretend to be a CPAN server if they could intercept your connection (via man-in-the-middle attacks), and CPAN.pm would trust them.
Users could install trojaned or backdoored modules without any warning.
Reference:
- Original CVE Entry
- Metacpan Advisory
How Did It Happen?
The problem was with how CPAN.pm used LWP::UserAgent and HTTP::Tiny, both Perl HTTP clients.
By default, unless told otherwise, many Perl HTTP libraries do not verify HTTPS certificates. This meant that even though your CPAN mirror URL began with “https://”, there was no real proof you were talking to the real thing.
Here's a typical snippet before 2.35
use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $response = $ua->get("https://cpan.perl.org/authors/id/S/SO/SOME_MODULE.tar.gz";);
# ... code to handle $response
Unless you pass extra parameters, no TLS verification happens.
Even with HTTP::Tiny
use HTTP::Tiny;
my $response = HTTP::Tiny->new->get("https://cpan.perl.org/authors/id/S/SO/SOME_MODULE.tar.gz";);
# No cert verification by default pre-2.35
Why This Matters
- Man-in-the-middle attack? Steal the WiFi at a coffee shop. If a Perl dev runs cpan, attacker gives them a poisoned module.
Corporate proxies misconfigured? Same result—danger!
- Open source supply chain compromised. Attackers can take over organizations by poisoning dependencies.
Victim runs cpan install Some::Module.
3. Because there’s no real TLS verification, attacker sends their own fake CPAN response and module archive.
Victim’s machine cheerfully downloads and installs the attacker's module.
No scary code needed—we can abuse standard tools like mitmproxy or ettercap:
# In a real test lab ONLY. Set up a proxy with a self-signed certificate:
mitmproxy --mode transparent --ssl-insecure
Then have the victim run
perl -MCPAN -e 'install Some::Module'
If they’re on CPAN.pm < 2.35, and accept the mitmproxy cert—or if their Perl was built without CA certificates at all—they get the attacker’s module.
The Fix
This commit for CPAN.pm explicitly enables certificate verification:
# New in CPAN.pm >= 2.35:
$ua->ssl_opts(
verify_hostname => 1,
SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_PEER(),
);
Or for HTTP::Tiny
HTTP::Tiny->new(
verify_SSL => 1,
SSL_ca_file => '/etc/ssl/certs/ca-certificates.crt'
);
perl -MCPAN -e 'print $CPAN::VERSION'
`
Make sure it’s 2.35 or later.
- Verify your HTTP client libraries also default to SSL verification.
- Avoid running CPAN as root—use local::lib if possible.
---
## Conclusion
CVE-2023-31484 is a perfect example of how forgetting a “default secure” setting can have huge real-world effects. Dependency security isn’t just about the code *you* write—it’s also about *how* you fetch code. Always verify your sources.
Further Reading:
- NVD Detail
- CPAN.pm changelog
- Perl SSL Documentation
---
Stay safe and keep your toolchains patched!
Timeline
Published on: 04/29/2023 00:15:00 UTC
Last modified on: 05/08/2023 17:11:00 UTC