Bug 1094440 (CVE-2014-3230) - CVE-2014-3230 perl-libwww-perl: incorrect handling of SSL certificate verification
Summary: CVE-2014-3230 perl-libwww-perl: incorrect handling of SSL certificate verific...
Alias: CVE-2014-3230
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: https://github.com/libwww-perl/lwp-pr...
Depends On: 1094442
Blocks: 1094441
TreeView+ depends on / blocked
Reported: 2014-05-05 17:05 UTC by Vincent Danen
Modified: 2021-02-17 06:35 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-27 15:12:13 UTC

Attachments (Terms of Use)
Test case (3.19 KB, text/plain)
2014-05-08 15:16 UTC, Petr Pisar
no flags Details
Test case (3.19 KB, text/plain)
2014-05-09 08:32 UTC, Petr Pisar
no flags Details
Proposed fix (part 1) (959 bytes, patch)
2014-05-12 12:27 UTC, Petr Pisar
no flags Details | Diff
Proposed fix (part 2) (1.56 KB, patch)
2014-05-12 12:28 UTC, Petr Pisar
no flags Details | Diff
Part 1 ported to 6.04 (959 bytes, patch)
2014-05-12 14:46 UTC, Petr Pisar
no flags Details | Diff
Part 2 ported to 6.04 (1.13 KB, patch)
2014-05-12 14:47 UTC, Petr Pisar
no flags Details | Diff
Part3 for 6.04 to restore behavior in F19 (1.72 KB, patch)
2014-05-13 12:50 UTC, Petr Pisar
no flags Details | Diff

Description Vincent Danen 2014-05-05 17:05:04 UTC
It was reported [1] 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 [2], 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 [3],[4] are being discussed upstream [5].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746579
[2] https://github.com/dagolden/lwp-protocol-https/commit/bcc46ce2dab53d2e2baa583f2243d6fc7d36dcc8
[3] https://github.com/noxxi/lwp-protocol-https/commit/1b924708663f457a4f7c25ed35d7dfb3bb5b334d
[4] https://github.com/noxxi/lwp-protocol-https/commit/6b5c876de80451ee54de5d853de37a62e26bf6fe
[5] https://github.com/libwww-perl/lwp-protocol-https/pull/14



Comment 1 Vincent Danen 2014-05-05 17:07:04 UTC
Created perl-libwww-perl tracking bugs for this issue:

Affects: fedora-all [bug 1094442]

Comment 3 Martin Prpič 2014-05-07 15:00:47 UTC
MITRE assigned CVE-2014-3230 to this issue:


^ also states that additional CVEs may be assigned later.

Comment 5 Petr Pisar 2014-05-08 15:16:43 UTC
Created attachment 893659 [details]
Test case

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.

Comment 6 Petr Pisar 2014-05-09 08:32:07 UTC
Created attachment 893881 [details]
Test case

Quoting colon in the network address fixed.

Comment 7 Petr Pisar 2014-05-12 12:27:48 UTC
Created attachment 894671 [details]
Proposed fix (part 1)

From <https://github.com/noxxi/lwp-protocol-https.git>.

Comment 8 Petr Pisar 2014-05-12 12:28:24 UTC
Created attachment 894672 [details]
Proposed fix (part 2)

From <https://github.com/noxxi/lwp-protocol-https.git>.

Comment 9 Petr Pisar 2014-05-12 14:46:20 UTC
Created attachment 894747 [details]
Part 1 ported to 6.04

Comment 10 Petr Pisar 2014-05-12 14:47:16 UTC
Created attachment 894748 [details]
Part 2 ported to 6.04

Comment 11 Petr Pisar 2014-05-13 12:50:05 UTC
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.

Comment 12 Fedora Update System 2014-05-21 23:22:55 UTC
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.

Comment 13 Fedora Update System 2014-05-23 18:55:40 UTC
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.

Comment 14 Tomas Hoger 2014-06-05 21:32:11 UTC
(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:


- 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.

Note You need to log in before you can comment on or make changes to this bug.