It was reported  that libwww-perl (LWP), when using IO::Socket::SSL (the default) and when the HTTPS_CA_DIR or HTTPS_CA_FILE environment variables were set, would disable server certificate verification. Judging by the commit , the intention was to disable only hostname verification for compatibility with Crypt::SSLeay, but the resultant effect is that SSL_verify_mode is set to 0. This code was introduced in LWP::Protocol::https in version 6.04, so earlier versions are not vulnerable.
Potential patches , are being discussed upstream .
Created perl-libwww-perl tracking bugs for this issue:
Affects: fedora-all [bug 1094442]
MITRE assigned CVE-2014-3230 to this issue:
^ also states that additional CVEs may be assigned later.
Created attachment 893659 [details]
This is an automated test. It requires openssl(1) and some Perl modules. It checks how HTTPS_CA_FILE environment variable influences LWP::UserAgent behavior regarding certificate verification.
Created attachment 893881 [details]
Quoting colon in the network address fixed.
Created attachment 894671 [details]
Proposed fix (part 1)
Created attachment 894672 [details]
Proposed fix (part 2)
Created attachment 894747 [details]
Part 1 ported to 6.04
Created attachment 894748 [details]
Part 2 ported to 6.04
Created attachment 895124 [details]
Part3 for 6.04 to restore behavior in F19
This patch is needed for F19 only because there is old IO::Socket::SSL which still defaults to no peer certificate verification.
perl-LWP-Protocol-https-6.04-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
perl-LWP-Protocol-https-6.04-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Vincent Danen from comment #0)
> This issue did not affect the versions of perl-libwww-perl as shipped with
> Red Hat Enterprise Linux 5 and 6.
It should be noted that versions of perl-libwww-perl in Red Hat Enterprise Linux 6 do not perform SSL certificate verification by default (see bug 705044, including an example of how to enable certificate checks in IO::Socket::SSL in bug 705044 comment 7). The change to enable SSL verification by default was made upstream in version 6.0.
Upstream version 6.0 also introduced ways to control certificate verification:
- Via LWP::UserAgent ssl_opts attribute:
These allow specifying a path to file (SSL_ca_file) or directory (SSL_ca_path) with CA certificates, and whether host name verification should be performed (verify_hostname). If these are not set in a script, environment variables are checked in the following order:
- PERL_LWP_SSL_* variables first, including: PERL_LWP_SSL_VERIFY_HOSTNAME, PERL_LWP_SSL_CA_FILE, and PERL_LWP_SSL_CA_PATH
- HTTPS_CA_* if PERL_LWP_SSL_* are not set: HTTPS_CA_FILE, and HTTPS_CA_DIR. When these are used, host name verification is automatically disabled (for backwards compatibility).
The problem here is that when host name verification is disabled, certificate verification is disabled as well (unless explicitly requested using IO::Socket::SSL's SSL_verify_mode). One such example is the use of HTTPS_CA_* environment variables.
LWP::UserAgent documentation is scarce and ambiguous in defining whether verify_hostname 0 is supposed to only disable hostname check, or all certificate checks. The code seems to assume all checks are disabled. However, that's not really compatible with the (undocumented) assumption that HTTPS_CA_* environment variables are meant to enable certificate checks and only disable hostname checks.
Note that use when certificate is checked without checking hostname is usually insecure, as malicious site can obtain SSL certificate from a trusted CA for a different name and still have it accepted as valid for different host.