Security advisory: QLockFile, QAuthenticator, Windows platform plugin

Recently, the Qt Project's security team was made aware of an issue regarding Qt's usage of LoadLibrary in a few locations and determined it to be a security issue on Windows only.

Specifically, the problem is connected to when LoadLibrary is used to load a system library, such as opengl.dll as these are expected to be located inside the system Windows directory. However, LoadLibrary will search in the current working directory first to see if a dll with the same name is available there first and as a result it can end up trying to load that one instead of the correct one. This can mean that it can invoke the Preload routine of the dll before trying to load the symbols needed by the caller.

This can be worked around in any application, by calling:

SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT);

before creating the Q[Core|Gui]Application object and then any calls to LoadLibrary will only check in the current working directory after it has searched the other paths which should suffice to prevent the problem.

Patches are available for the currently supported versions of Qt can be found here:

dev: https://codereview.qt-project.org/c/qt/qtbase/+/396440
Qt 6.2: https://codereview.qt-project.org/c/qt/qtbase/+/396689 or https://download.qt.io/official_releases/qt/6.2/CVE-2022-25643-6.2.diff
Qt 5.15: https://codereview.qt-project.org/c/qt/tqtc-qtbase/+/396690 or https://download.qt.io/official_releases/qt/5.15/CVE-2022-25643-5.15.diff

The official CVE report for this can be found here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25634

Update: It has been reported that the workaround is not always working, so it is recommended to see: https://support.microsoft.com/en-us/topic/secure-loading-of-libraries-to-prevent-dll-preloading-attacks-d41303ec-0748-9211-f317-2edc819682e1 for further options in that respect.

 


Blog Topics:

Comments

Commenting for this post has ended.

Richard Thompson
0 points
38 months ago

The Qt 5.15 links are both dead, regardless of whether I'm logged in as commercial or not.

The dev and Qt 6.2 links only appear to refer to loading opengl32.dll or opengl32sw.dll, while this advisory mentions QLockFile and QAuthenticator and "LoadLibrary in a few locations" and gives opengl32.dll as an example.

Is there something missing from this blog post? The CVE is extremely vague (presumably intentionally)

Finally, "opengl32sw.dll" is not part of a normal Windows 7/8/10/11 installation. I believe this means this fix does not in fact correct the problem - a miscreant able to insert an evil dll into the application directory can also set the "force software rendering" environment or qt.conf, and thus require the use of their evil opengl32sw.dll.

A
Andy Shaw
0 points
38 months ago

Both links for Qt 5.15 are working fine for me at least, if you are still having problems then please contact us via the Support Center in Qt Account so we can just provide you the patches directly.

Qt 5.15 has a problem in QLockFile and QAuthenticator at least as well as in the windows plugin, but in Qt 6 it is only in one place where it is a problem. But since the cause is the same then it was covered as one inclusive post and CVE.

When Qt is deployed, then typically it will be deployed with opengl32sw.dll because the automatic loading of software rendering might trigger and as a result the application directory should be protected against this usage. Forcing software rendering can only be done via specific ways and those can be overridden by the application itself if that level of protection is needed here.

What I would recommend is discussing this with the support team if you need further clarification so they can go into further detail if needed.