This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 891955 - (CVE-2012-6093) CVE-2012-6093 qt: QSslSocket might report inappropriate errors when certificate verification fails
CVE-2012-6093 qt: QSslSocket might report inappropriate errors when certifica...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130102,reported=2...
: Security
Depends On: 891964
Blocks: 891966
  Show dependency treegraph
 
Reported: 2013-01-04 11:06 EST by Jan Lieskovsky
Modified: 2015-07-31 02:56 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-16 05:55:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2013-01-04 11:06:20 EST
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
Comment 1 Jan Lieskovsky 2013-01-04 11:17:48 EST
CVE Request:
[3] http://www.openwall.com/lists/oss-security/2013/01/04/3
Comment 2 Rex Dieter 2013-01-04 11:20:08 EST
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 11:38:44 EST
Created qt tracking bugs for this issue

Affects: fedora-all [bug 891964]
Comment 4 Jan Lieskovsky 2013-01-04 11:41:10 EST
(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 11:42:30 EST
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 11:45:18 EST
Honestly, the risk to fedora is probably somewhere between very small to nil indeed.
Comment 8 Tomas Hoger 2013-01-04 12:46:22 EST
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-05 19:43:30 EST
I agree with Tomas Hoger, I don't see how this issue can possibly affect Fedora.
Comment 10 Vincent Danen 2013-01-07 11:14:31 EST
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 10:08:42 EST
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 05:55:40 EST
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.

Note You need to log in before you can comment on or make changes to this bug.