Bug 1094440 (CVE-2014-3230)

Summary: CVE-2014-3230 perl-libwww-perl: incorrect handling of SSL certificate verification
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: carnil, jkurik, jrusnack, mmaslano, perl-devel, perl-maint-list, ppisar, psabata
Target Milestone: ---Keywords: Patch, Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: https://github.com/libwww-perl/lwp-protocol-https/pull/14
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-27 15:12:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1094442    
Bug Blocks: 1094441    
Attachments:
Description Flags
Test case
none
Test case
none
Proposed fix (part 1)
none
Proposed fix (part 2)
none
Part 1 ported to 6.04
none
Part 2 ported to 6.04
none
Part3 for 6.04 to restore behavior in F19 none

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


Statement:

(none)

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:

http://seclists.org/oss-sec/2014/q2/256

^ 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:
http://search.cpan.org/dist/libwww-perl/lib/LWP/UserAgent.pm#ATTRIBUTES

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.