|Summary:||CVE-2012-6093 qt: QSslSocket might report inappropriate errors when certificate verification fails|
|Product:||[Other] Security Response||Reporter:||Jan Lieskovsky <jlieskov>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Version:||unspecified||CC:||itamar, jreznik, kevin, ltinkl, rdieter, rnovacek, smparrish, than|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-01-16 10:55:40 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||891964|
Description Jan Lieskovsky 2013-01-04 16:06:20 UTC
A security flaw was found in the way QSslSocket implementation of the Qt, a software toolkit for applications development, performed certificate verification callbacks, when Qt libraries were used with different OpenSSL version than the one, they were compiled against. In such scenario, this would result in a connection error, but with the SSL error list to contain QSslError:NoError instead of proper reason of the error. This might result in a confusing error being presented to the end users, possibly encouraging them to ignore the SSL errors for the site the connection was initiated against. References:  http://lists.qt-project.org/pipermail/announce/2013-January/000020.html Relevant upstream patch:  https://codereview.qt-project.org/#change,42461
Comment 1 Jan Lieskovsky 2013-01-04 16:17:48 UTC
CVE Request:  http://www.openwall.com/lists/oss-security/2013/01/04/3
Comment 2 Rex Dieter 2013-01-04 16:20:08 UTC
Hi, thanks for opening this for tracking purposes. I'd just submitted fixed builds to bodhi a little earlier, https://admin.fedoraproject.org/updates/qt-4.8.4-4.fc18 https://admin.fedoraproject.org/updates/qt-4.8.4-4.fc17 https://admin.fedoraproject.org/updates/qt-4.8.4-4.fc16 should a mark those to block this bug?
Comment 3 Jan Lieskovsky 2013-01-04 16:38:44 UTC
Created qt tracking bugs for this issue Affects: fedora-all [bug 891964]
Comment 4 Jan Lieskovsky 2013-01-04 16:41:10 UTC
(In reply to comment #2) Hi Rex, noticed (to be honest my CVE request was based on seeing your builds). > Hi, thanks for opening this for tracking purposes. I'd just submitted fixed > builds to bodhi a little earlier, > https://admin.fedoraproject.org/updates/qt-4.8.4-4.fc18 > https://admin.fedoraproject.org/updates/qt-4.8.4-4.fc17 > https://admin.fedoraproject.org/updates/qt-4.8.4-4.fc16 > > should a mark those to block this bug? I have created fedora-all tracker too. So feel free to use either both (this and Fedora tracker ones, Bodhi should recognize and do the right thing) or use just this one and close the Fedora tracker as not needed (here again Bodhi should not include updates messages into this bug / IOW realize it's not a tracker). Will leave to up to you (which scenario serves you better). Thank you for dealing with those, Jan.
Comment 6 Tomas Hoger 2013-01-04 16:42:30 UTC
Does this actually affect Fedora? It seems the dynamic OpenSSL loading feature is optional and Fedora builds configure qt with -openssl-linked. Hence they should never end up loading different OpenSSL version. Additionally, the library search code seems to search lib directories, but not lib64, so unsure if that dynamic loading would actually work.
Comment 7 Rex Dieter 2013-01-04 16:45:18 UTC
Honestly, the risk to fedora is probably somewhere between very small to nil indeed.
Comment 8 Tomas Hoger 2013-01-04 17:46:22 UTC
To clarify my comment 6, libQtNetwork.so in Fedora and Red Hat Enterprise Linux qt packages links against specific (system) OpenSSL version. Incompatible OpenSSL versions get different soname (e.g. libssl.so.8 for 0.9.8 and libssl.so.10 for 1.0.0 packages in Fedora and RHEL), hence it can not get used accidentally. Therefore assuming dynamic loading as requirement for this to get exposed.
Comment 9 Kevin Kofler 2013-01-06 00:43:30 UTC
I agree with Tomas Hoger, I don't see how this issue can possibly affect Fedora.
Comment 10 Vincent Danen 2013-01-07 16:14:31 UTC
This was assigned CVE-2012-6093: http://www.openwall.com/lists/oss-security/2013/01/04/6
Comment 11 Fedora Update System 2013-01-12 15:08:42 UTC
qt-4.8.4-6.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Comment 12 Tomas Hoger 2013-01-16 10:55:40 UTC
QSslSocket is only available in qt (4.x) packages in Red Hat Enterprise Linux 6 and later (including current Fedora versions). It is not available in qt and qt4 packages in Red Hat Enterprise Linux 5, and qt3 packages in Red Hat Enterprise Linux 6. Qt packages in Red Hat Enterprise Linux and Fedora are not built with support for dynamic loading of OpenSSL library. They are linked against the version provided with the distribution. Therefore, they will only use OpenSSL version that is compatible with the one that was used during the build, avoiding this confusion caused by OpenSSL version incompatibilities. Statement: Not vulnerable. This issue did not affect the versions of Qt as shipped with Red Hat Enterprise Linux 5 and 6.