Bugzilla – Bug 933110
VUL-0: CVE-2015-3886: libinfinity: does not correctly check certificates for validity
Last modified: 2015-06-02 13:37:09 UTC
https://gobby.github.io/2015/05/14/libinfinity-0-6-6-released.html libinfinity 0.6.6 has been released. This is a bugfix release in the 0.6.x series. It fixes a problem where a server's certificate would silently be accepted even though it failed verification if no certificate pinning is performed, i.e. the hostname matches and its CA is trusted. A potential client-side crash is also fixed which occured when a server is shut down while still being connected. It is recommended that all users update to this new version of libinfinity. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3886 http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-3886.html Need backported fixes for... openSUSE:13.1 libinfinity 0.5.4 openSUSE:13.2 libinfinity 0.5.5 please.
bugbot adjusting priority
(In reply to Andreas Stieger from comment #0) > Need backported fixes for... > openSUSE:13.1 libinfinity 0.5.4 > openSUSE:13.2 libinfinity 0.5.5 > please. I'm wondering if 0.5.4 and 0.5.5 are actually affected by this bug. The code rather different here: > ret = gnutls_x509_crt_list_verify( > inf_certificate_chain_get_raw(chain), > inf_certificate_chain_get_n_certificates(chain), > (gnutls_x509_crt_t*)priv->ca_certs->pdata, > priv->ca_certs->len, > NULL, > 0, > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, > &verify > ); > > if(ret < 0) > { > g_warning(_("Could not verify certificate: %s"), gnutls_strerror(ret)); > inf_xmpp_connection_certificate_verify_cancel(connection); > } > else > { > if((verify & GNUTLS_CERT_INVALID) != 0) > flags |= INF_GTK_CERTIFICATE_DIALOG_CERT_INVALID; So, if gnutls_x509_crt_list_verify fails, it aborts - otherwise it checks for CERT_INVALID and adds this to the flags - which later on is used to give dialogs. The code in 0.6 looks rather different here. I'll see if I can setup a test case to validate if this is actually applicable or not
also take into account the oriinal report @ debian: >At the moment the certificate of gobby.debian.net is expired (reported >separately as Bug#783599) but Jessie's gobby happily establishes a full >connection to it without any warning. This is a regression since Wheezy, >since it's not the case in gobby-0.5 (version 0.4.94-5), which shows a >warning stating that the certificate has expired with the option to >accept it any way.
There was also an answer posted by upstream on my direct query: >No, this does not apply to 0.5.x. The code was indeed changed between 0.5 and >0.6, to make certificate pinning more SSH-like. For example, if a host has a >self-signed certificate, with 0.5.x you would be asked at every connection >attempt whether to actually connect, while with 0.6.x you are only asked the >first time as long as that host shows you the same certificate every time. So, I'd say nothing left to be done. Andreas: agreed?
(In reply to Dominique Leuenberger from comment #4) > There was also an answer posted by upstream on my direct query: > > >No, this does not apply to 0.5.x. The code was indeed changed between 0.5 and >0.6, to make certificate pinning more SSH-like. For example, if a host has a >self-signed certificate, with 0.5.x you would be asked at every connection >attempt whether to actually connect, while with 0.6.x you are only asked the >first time as long as that host shows you the same certificate every time. > > So, I'd say nothing left to be done. > > Andreas: agreed? Thanks for the verification with upstream. Agree, 13.1 and 13.2 not affected, and Tumbleweed already fixed with 0.6.6.