Bug 660847 (CVE-2010-4334)

Summary: CVE-2010-4334 perl-IO-Socket-SSL: ignores user request for peer verification
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: jose.p.oliveira.oss, paul, perl-devel, perl-maint-list, ppisar, psabata
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=low,public=20101206,reported=20101206,source=debian,cvss2=4/AV:N/AC:H/Au:N/C:P/I:P/A:N,fedora-all/perl-IO-Socket-SSL=affected,rhel-6/perl-IO-Socket-SSL=wontfix,rhel-5/perl-IO-Socket-SSL=notaffected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-22 15:00:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
upstream 1.34->1.35 patch to fix the issue
Test case none

Description Vincent Danen 2010-12-07 18:08:55 UTC
A Debian bug report [1] indicated that using the IO::Socket::SSL perl module, if the verify_mode were set to 0x03 (verify peer, fail verification if no peer certificate exists), that the requests were removed unless either the ca_file or ca_path were supplied.  This means that IO::Socket::SSL "fails open" if the user forgets to supply information about an acceptable set of trusted CAs, rather than "failing closed" (denying access by default, rather than allowing it).

Upstream has released IO::Socket::SSL version 1.35 [2] to correct this flaw with the following changelog entry:

v1.35 2010.12.06
- if verify_mode is not VERIFY_NONE and the ca_file/ca_path cannot be
  verified as valid it will no longer fall back to VERIFY_NONE but throw
  an error. Thanks to Salvatore Bonaccorso and Daniel Kahn Gillmor for
  pointing out the problem, see also 

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606058
[2] http://search.cpan.org/~sullr/IO-Socket-SSL-1.35/

Comment 1 Vincent Danen 2010-12-07 19:40:01 UTC
Created attachment 467284 [details]
upstream 1.34->1.35 patch to fix the issue

This is the diff of upstream versions 1.34 and 1.35.  The only change in 1.35 is this flaw.

Comment 2 Vincent Danen 2010-12-07 22:59:27 UTC
This is CVE-2010-4334.

Another reference: http://secunia.com/advisories/42508/

Comment 3 Tomas Hoger 2010-12-17 16:47:05 UTC
(In reply to comment #2)
> Another reference: http://secunia.com/advisories/42508/

Secunia advisory mentions:
  The security issue is caused due to IO::Socket::SSL silently falling back
  to the "VERIFY_NONE" verification mode if another verification mode is
  defined but no valid ca_file or ca_path is provided.

This is not entirely true, as IO::Socket::SSL carp()s in such case with error messages as:

  No certificate verification because neither SSL_ca_file nor SSL_ca_path
  known at /usr/share/perl5/IO/Socket/SSL.pm line 301

Looking that the upstream changelog, this problem was introduced as intended fallback behaviour in version 1.23:

  v1.23 2009.02.23
  - if neither SSL_ca_file nor SSL_ca_path are known (e.g not given and the
    default values have no existing file|path) disable checking of
    certificates, but carp about the problem

Affected versions are only in RHEL-6 and F-13/F-14.

Comment 5 Tomas Hoger 2010-12-17 16:52:51 UTC
Created attachment 469413 [details]
Test case

Slightly modified example ssl_client.pl script that can be used to test.

Comment 7 Paul Howarth 2010-12-26 21:48:04 UTC
Fedora 13, 14 and Rawhide all now have IO::Socket::SSL 1.37.

Comment 8 Tomas Hoger 2011-01-04 08:29:44 UTC
This issue has low security impact.  Fallback to VERIFY_NONE only happens in case of misconfiguration, i.e. when user requests certificate verification but fails to specify valid CA certificate store.  Warning message is printed in such case, making it easy to spot.

Comment 9 Paul Howarth 2011-06-29 12:09:49 UTC
I believe this one can be closed now.

Comment 10 Vincent Danen 2011-07-01 04:59:01 UTC
No, Red Hat Enterprise Linux 6 is still affected by this so it cannot be closed.

Comment 11 Vincent Danen 2015-08-22 15:00:47 UTC

This issue did not affect perl-IO-Socket-SSL version as shipped with Red Hat Enterprise Linux 5.  Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.