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: [1] http://lists.qt-project.org/pipermail/announce/2013-January/000020.html Relevant upstream patch: [2] https://codereview.qt-project.org/#change,42461
CVE Request: [3] http://www.openwall.com/lists/oss-security/2013/01/04/3
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?
Created qt tracking bugs for this issue Affects: fedora-all [bug 891964]
(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.
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.
Honestly, the risk to fedora is probably somewhere between very small to nil indeed.
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.
I agree with Tomas Hoger, I don't see how this issue can possibly affect Fedora.
This was assigned CVE-2012-6093: http://www.openwall.com/lists/oss-security/2013/01/04/6
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.
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.