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/
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.
This is CVE-2010-4334. Another reference: http://secunia.com/advisories/42508/
(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.
1.22 -> 1.23 and 1.34 -> 1.35 diffs for posterity: http://search.cpan.org/diff?from=IO-Socket-SSL-1.22&to=IO-Socket-SSL-1.23&w=1 http://search.cpan.org/diff?from=IO-Socket-SSL-1.34&to=IO-Socket-SSL-1.35&w=1
Created attachment 469413 [details] Test case Slightly modified example ssl_client.pl script that can be used to test.
Fedora 13, 14 and Rawhide all now have IO::Socket::SSL 1.37.
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.
I believe this one can be closed now.
No, Red Hat Enterprise Linux 6 is still affected by this so it cannot be closed.
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/.