Am 26.01.2014 um 20:46 schrieb Thiago Macieira <thiago.macie...@intel.com>:
> On sexta-feira, 24 de janeiro de 2014 18:47:33, Till Oliver Knoll wrote:
>> ... which on its turn - or whatever Qt component in the end - seems to
>> search for an OpenSSL.dll in the PATH (according to the OP the program
>> folders of "Tortoise" and "CMake" were scanned!). And PATH is clearly /not/
>> a standard "Qt Plugin Path".
>
> OpenSSL is not a Qt plugin.
That's what I said ;)
> It's being searched as it would have been searched
> if QtNetwork did directly link to it.
The search order of a "directly linked DLL" (altough I think that there are
some MSVS linker flags which would restrict that search path for "hardlinked"
DLLs even more, or with "side-by-side/private assemblies/manifests" or whatever
that was called to make sure your and *only* your DLLs would be used) and a DLL
opened via LoadLibrary and a *relative* path, as in LoadLibrary("Foo.dll"),
might be the same.
But there's still a subtle but important difference: the dependency might not
be obvious! So it might be very easily forgotten to ship an OpenSSL library +
dependencies (libeay.dll is apparently one of them), and that dependency is not
visible in Dependency Walker (unless off course one would "profile" the
application and trigger all possible actions which would lead to all possible
LoadLibrary calls in the application).
Now, I must admit that I am no OpenSSL expert, so I don't know whether that
"libeay32.dll" is merely a ("hard-linked") dependency of some other "OpenSSL"
library (ssleay32.dll maybe?) which on its turn is (safely with *absolute*
paths) linked with LoadLibrary from Qt itself - or whether it is really Qt that
does a very dangerous call like
// Is it present *somewhere* on the system?
LoadLibrary("libeay32.dll"); // BAD!
That would be an invitation for "binary planting".
May I refer to
http://www.binaryplanting.com/guidelinesDeveloper.htm
(Yes indeed, that "binary planting" aka "DLL hijacking" was such a huge
"discovery" amongst many developers, including MS Office engineers, back in
2010 that this problem has its own domain ;))
Unsurprisingly the number one "best practise" is:
"Use absolute paths to libraries when calling LoadLibrary*."
> Therefore, the behaviour is correct.
Should Qt really have LoadLibrary calls with *relative* paths, then I would say
that the behaviour is *expected* that a libeay32.dll is picked up at "random
places" such as "C:\Program Files\CMake\" (which the OP, being a developer,
must have explicitly added to the PATH, or the CMake installer did that), or
even worse, the "current working directory", but it would be "fatal", not
"correct".
I am not saying that this is the case though: maybe (probably? Let's emphasise
Hope here ;)) Qt does the Right Thing and restricts the search to the
"application directory" and e.g. "system libraries", and it tries to resolve
e.g.
LoadLibrary("/APP_DIR/ssleay32.dll");
Maybe *that* library was indeed shipped by the OP, but he forgot to ship the
"hard dependency" libeay32.dll, which then Windows tries to resolve with the
usual search path. Then there's nothing Qt could do about it.
If on the other hand there was indeed a
LoadLibrary("libeay32.dll")
somewhere in Qt's code, then we should stop discussing immediatelly in public
and move the discussion to whoever feels responsible for critical issues.
Actually, my point was more to bring up the topic "binary planting" as a
general point for developer who haven't heard about it yet (or have forgotten),
but I must admit that the statement "Therefore, the behaviour is correct"
(assuming off course that we really talk about a library which is loaded with
LoadLibrary) makes me a bit nervous ;)
Especially since a quick Google search with
"LoadLibrary(L"libeay32.dll")"
(including all quotes) also shows up results under the qt.gitorious.org domain!
:O
But talking about which, the commit message (from 3 years ago!) is very
interesting, as it covers /exactly/ the (possible) problem that I was talking
about:
https://qt.gitorious.org/qt/agateau-qt/commit/5738dcd705e7edde816940f9c0ab2c364c81ad20
“Ensure that we load system libraries from the correct location.
This was a security hole that has been there for a while, but the public
awareness have recently rised so the threat is more imminent now.
The solution is to fix all places where we dynamically load system libraries.
More specifically, we now load all system libraries with an absolute path that
points to a library in the system directory (usually c:\windows\system32).
We therefore introduce a small class named QSystemLibrary that only loads
libraries located in the system path. This shares some of the API with QLibrary
(in order to make the patch as small as possible).
We don't fix QLibrary due to risk of regressions. In addition, applications can
fix the code that calls QLibrary themselves.
The problem does not apply to Windows CE, since the search order is documented
as not searching in the current directory.
However, it touches some CE-specific code - therefore QSystemLibrary is
sometimes used on WinCE (however, it will just do a normal LoadLibrary() since
its safe anyway).
This change does not affect the testability plugin (it is not clearly
documented where that plugin is located, and the plugin should never be used in
production code anyway)
Loading OpenSSL libraries The ssl libraries are handled specially, and searched
in this order (we cannot expect them to always be in the system folder): 1.
Application path 2. System libraries path 3. Trying all paths inside the PATH
environment variable
Task-number: QT-3825 Reviewed-by: Thiago Macieira Reviewed-by: Peter Hartmann”
Reviewed by... Thiago ;)
However the question remains: how come an attempt was (again?) made in the
scenario given by the OP to pickup a library from somewhere in the PATH (my
assumption, because locations from c:\Program Files\WhateverApp were taken)?
Is PATH considered "safe"?
Cheers,
Oliver
Cheers,
Oliver_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
