[Qt-interest] Deployed win32 app with msvc runtime as private assembly fails to load psql plugin
Oliver.Knoll at comit.ch
Oliver.Knoll at comit.ch
Thu Jan 20 17:23:53 CET 2011
On 2011-01-20 Dmitry Dmitry Teslenko wrote:
>> ..
> I set directory explicitly:
>> QApplication::setLibraryPaths(QStringList(QString("./plugins")));
> Sorry, I had to mention that.
That is
a) very fragile (it depends on the "current directory"!) and
b) a high security risk!
As for a), at the point when you set ./plugins as the path the "current directory" could point to anywhere - you never know!
As for b), a malicious user could try to set the "current directory" to a bad place, such that you would end up loading bad Qt plugins which could do who-knows-what-harm!
This security risk is known since I don't know how many years (a multiple of 10, basically since the concept of "dynamically linking to code" exists ;) and has been discussed just a few months ago, when it was "discovered" that a lot of Windows applications suffer from this "DLL injection" possibility.
Also refer to:
- https://secure.wikimedia.org/wikipedia/en/wiki/DLL_injection
- http://news.cnet.com/8301-27080_3-20014625-245.html
The last link refers to a (one of many) article which describes this "discovered" security whole due to the "flaw in the way Windows handles DLL (dynamic-link library)".
Microsoft tried to reduce the risk of loading "malicious DLLs":
- http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
Note the distinction between SafeDllSearchMode enabled/disabled which basically controls when the "current directory" will be searched for DLLs! Since a lot of applications (apparently) dynamically loaded (via LoadLibrary()) plugins as in LoadLibrary("MyFooPlugin.dll") (or with any other relative path) they were prone to this attack.
But note that SafeDllSearchMode exists since I don't know when (much longer than this "flaw" was discovered), it does not entirely remove the risk and this is not only limited to Windows. On a Linux system calling dlopen("MyFooPlugin.so") is equally dangerous. That is the reason why most (if not all) Linux distros do NOT have the "current directory" (.) in the LD_LIBRARY_PATH. And if you are root I think the kernel does even ignore such a relative path.
Anyway, the bottom line (on any system) here is: NEVER LOAD DYNAMICALLY CODE FROM A RELATIVE PATH!
Alsways use ABSOLUTE PATHS, and these must be under control by the application, e.g. let the user explicitly set the "plugin directory", or look into a "well-known" plugin location which was created at install time etc. - off course if the user copies (unknowingly) malicious code into these places things will still blow up - but then you can at least blame the user ;)
So: use
http://doc.trolltech.com/4.7/qcoreapplication.html#applicationDirPath
to determine the absolute path to the application directory, then append ./plugins to that.
Cheers, Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22
More information about the Qt-interest-old
mailing list