Bug 660847 - (CVE-2010-4334) CVE-2010-4334 perl-IO-Socket-SSL: ignores user request for peer verification
CVE-2010-4334 perl-IO-Socket-SSL: ignores user request for peer verification
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20101206,reported=2...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-07 13:08 EST by Vincent Danen
Modified: 2015-08-22 11:00 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-22 11:00:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
upstream 1.34->1.35 patch to fix the issue (2.41 KB, patch)
2010-12-07 14:40 EST, Vincent Danen
no flags Details | Diff
Test case (1003 bytes, text/plain)
2010-12-17 11:52 EST, Tomas Hoger
no flags Details

  None (edit)
Description Vincent Danen 2010-12-07 13:08:55 EST
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 
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606058

[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 14:40:01 EST
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 17:59:27 EST
This is CVE-2010-4334.

Another reference: http://secunia.com/advisories/42508/
Comment 3 Tomas Hoger 2010-12-17 11:47:05 EST
(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 11:52:51 EST
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 16:48:04 EST
Fedora 13, 14 and Rawhide all now have IO::Socket::SSL 1.37.
Comment 8 Tomas Hoger 2011-01-04 03:29:44 EST
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 08:09:49 EDT
I believe this one can be closed now.
Comment 10 Vincent Danen 2011-07-01 00:59:01 EDT
No, Red Hat Enterprise Linux 6 is still affected by this so it cannot be closed.
Comment 11 Vincent Danen 2015-08-22 11:00:47 EDT
Statement:

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

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