Red Hat Bugzilla – Bug 881399
CVE-2012-6709 elinks/links: does not properly verify SSL certificates
Last modified: 2018-03-20 10:31:12 EDT
A Debian bug report [1] indicated that Links does not properly verify SSL certificates. If you visit a web site with an expired SSL certificate, Links will only display "SSL error" without any indication as to what the error was. This, in and of itself, is not a flaw however when testing, I found that when you go to a site with a valid SSL certificate, but for a different hostname (for example, if you go to https://alias.foo.com which might be a CNAME or a proxy for https://foo.com) Links will connect without any errors or warnings. Doing the same in a browser like Google Chrome, however, reports "You attempted to reach alias.foo.com, but instead you actually reached a server identifying itself as foo.com." and allows you to either proceed or not, before loading the site. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694658
Elinks suffers from the same thing, and I suspect they have similar code with regards to SSL handling as Elinks originated from Links.
Created elinks tracking bugs for this issue Affects: fedora-all [bug 881411]
Created links tracking bugs for this issue Affects: fedora-all [bug 881409] Affects: epel-6 [bug 881410]
elinks-0.12-0.36.pre6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
elinks-0.12-0.33.pre6.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
elinks-0.12-0.35.pre6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Debian report about elinks not checking the hostname matches the certificate's Common Name or subjectAltName: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740981 Seems to be fixed by the patch in bug 881411
Note that the patch used in Fedora seems to be broken, at least in Fedora 20 as per https://bugzilla.redhat.com/show_bug.cgi?id=881411#c22. Another bug #1099423 has more details there.
I have switched ELinks back to OpenSSL because nss_compat_ossl is no longer maintained. Here is the backported upstream patch I applied to fix this vulnerability: http://pkgs.fedoraproject.org/cgit/elinks.git/tree/elinks-0.12pre6-ssl-hostname.patch?id=6e8e7242 Red Hat Product Security, could you please review the patch?
Created attachment 1035386 [details] [PATCH] openssl: use the OpenSSL-provided host name check Hi Christian, thanks a lot for the suggestion! I have implemented it in the attached patch for ELinks. Would you be willing to do a review of the patch? It applies on the master branch of the upstream git repository: http://repo.or.cz/w/elinks.git
Hi Kamil, I think your patch has at least one resource leak. You have to call X509_VERIFY_PARAM_free(vpm). Christian
Created attachment 1037270 [details] [PATCH v2] openssl: use the OpenSSL-provided host name check (In reply to Christian Heimes from comment #23) > I think your patch has at least one resource leak. You have to call > X509_VERIFY_PARAM_free(vpm). Good catch! I mistakenly thought that SSL_set1_param() would take ownership of the allocated object. Could you please have a look at the improved version of that patch?
(In reply to Kamil Dudka from comment #24) > Created attachment 1037270 [details] > [PATCH v2] openssl: use the OpenSSL-provided host name check proposed upstream: http://lists.linuxfromscratch.org/pipermail/elinks-dev/2015-June/002099.html
(In reply to Kamil Dudka from comment #25) > (In reply to Kamil Dudka from comment #24) > > Created attachment 1037270 [details] > > [PATCH v2] openssl: use the OpenSSL-provided host name check > > proposed upstream: > > http://lists.linuxfromscratch.org/pipermail/elinks-dev/2015-June/002099.html Patch included in elinks-0.12-0.47.pre6.fc23: http://pkgs.fedoraproject.org/cgit/elinks.git/commit/?id=f94b7750
Statement: Red Hat Product Security has rated this issue as having Moderate 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/.