On 2020-01-30 18:09, Olivier Goffart wrote:
On 30/01/20 17:12, Thiago Macieira wrote:
On Thursday, 30 January 2020 03:05:50 PST Olivier Goffart wrote:
$PWD is not the same as the binary dir
(QCoreApplication::applicationDirPath) The later is still searched
while
looking for plugin. (so that covers the case where plugin is in the
folder
next to the binary)
But I am also not sure why Windows is not affected.
Because LoadLibrary() works differently from dlopen().
The Qt plugin loader code will open the DLL relative to $PWD and
inspect its
plugin metadata, in order to decide whether to load or not. Then it
tells
LoadLibrary to load a plain filename with no path components and
LoadLibrary()
goes and searches the system paths (which include the .exe's) first.
So it
loads a different file.
This is similar to a TOCTOU attack, but I couldn't come up with a
reasonable
attack scenario. If the interposing DLL has metadata saying not to load,
QLibrary will find the actual plugin later and will load that. The
worst that
could happen is that the interposing DLL has valid but incorrect
metadata
causing another DLL to be loaded that shouldn't be. This other DLL
isn't under
the control of the attacker, though and neither is the name of the DLL.
I think a reasonable attack scenario remains if the plugin does not
exist in the system.
Hi, since Qt's plugin loader does not care what the filename is, as long
as it ends with .dll (i.e. if you rename qwindows.dll to grapefruit.dll
it will still be loaded), isn't an attack always possible?
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
