New IO::Socket::SSL version 1.26 was released fixing a bug in a hostname verification code. v1.26 2009.07.03 - SECURITY BUGFIX! fix Bug in verify_hostname_of_cert where it matched only the prefix for the hostname when no wildcard was given, e.g. www.example.org matched against a certificate with name www.exam in it An attacker could use this flaw to spoof identity of the SSL protected site, if he could obtain a valid certificate from the CA trusted by client with the CN being a prefix of the hostname client tried to connect to (e.g. domain.co if client tries to connect to domain.com). Upstream fix (diff between 1.25 and 1.26): http://search.cpan.org/diff?from=IO-Socket-SSL-1.25&to=IO-Socket-SSL-1.26&w=1
Updates are pending for F-9, F-10, and F-11, Rawhide is already updated to 1.26. EL-5 has IO::Socket::SSL version 1.01; EPEL-4 also has that version. I don't want to bump the version in EPEL-4 past the one in EL-5 so I'm waiting to see what happens for EL-5 before doing anything for EPEL-4.
Yup, I've seen and updated Fedora update requests. As for 1.01 in EL5 and EPEL4, the situation there is bit more difficult, as that version does not seem to any support for hostname verification. According to the changelog, it was only added in 1.14: http://cpansearch.perl.org/src/SULLR/IO-Socket-SSL-1.14/Changes v1.14 - added support for verification of hostname from certificate including subjectAltNames, support for IDN etc based on patch and input from christopher[AT]odenbachs[DOT]de and achim[AT]grolmsnet[DOT]de.
perl-IO-Socket-SSL-1.26-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
perl-IO-Socket-SSL-1.26-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
For RHEL5, do we want to add hostname verification to the older version? There are two schools of thought here, which is why it needs to be brought up (so we can decide what to do with it). If someone is relying on the *lack* of hostname verification, any app using this perl module could possibly break in a customer environment. That would be a bad thing for an update to do. Conversely, having hostname support increases security. Do we increase the security at the risk of breaking something in a customer's environment? A lot of people play fast-and-loose with internal networks and SSL just for cost savings, so if we make this change there is a very real chance this could break something. Personally, I think that because RHEL5 and earlier didn't have support for it, *this* issue isn't a security issue to affect them. Do we typically backport/provide security enhancements? From what I can see we don't, so I think if this is fixed in rawhide so RHEL6 gets it, then I think we've done what we should.
Secunia has an advisory for this issue, still no CVE name: http://secunia.com/advisories/35703/
(In reply to comment #6) > For RHEL5, do we want to add hostname verification to the older version? I think if that is requested by the users, it can be done, but I don't think this should be done under / because of this bug. > If someone is relying on the *lack* of hostname verification, any app using > this perl module could possibly break in a customer environment. That would > be a bad thing for an update to do. Conversely, having hostname support > increases security. As far as I can see, risks should be rather low. As name verification only happens when it's requested explicitly by the application using the module (either via verify_hostname method or SSL_verifycn_* options to new()). Old code should work with new module versions without regressions related to this, but just a module version update will not automagically add hostname verification to apps that don't do it today. > Personally, I think that because RHEL5 and earlier didn't have support for it, > *this* issue isn't a security issue to affect them. Agree. If someone needs a hostname verification support in RHEL5 packages, it should be requested via RFE bug. Additionally, I had a look at applications using IO::Socket::SSL in RHEL5. There are only 2 components in the distribution: - spamassassin - Used for optional SSL encryption for spamd <-> spamc communication. Only used on server side (spamd), as client (spamc) is written in C and is using OpenSSL directly. Hence this feature is irrelevant to spamassassin. - perl-LDAP - This module does not have support for hostname verification, not even in the latest git version to date. Hence without further modifications of perl-LDAP itself, it won't benefit from hostname verification support in IO::Socket::SSL.
As noted above, version of perl-IO-Socket-SSL does not implement name verification feature. If the backport of the feature is needed, separate RFE bug should be filed. Closing this one, as it was addressed on all affected versions.