[Development] New Qt vulnerabilities

[Henry Skoglund]

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?