[Interest] libeay32.dll - The Ordinal 4369 could not be located

[Till Oliver Knoll]

Am 24.01.2014 um 13:20 schrieb Phil Hannent <phil at hannent.co.uk>:

> ...
> 
> 1, How is Qt 5.2.0 able to make SSL connections when the required
> DLL's are not shipped in the pre-compiled Qt downloads?

In one word: "plugins" - or more specifically: dlopen (Unix) respective LoadLibrary (Windows).

So even "Dependency Walker" might not show that dependency Qt most likely tries to resolve for any OpenSSL library it finds *at runtime*.

And that is also the dangerous part (-> "DLL Injection") when one does a library search with /relative/ paths, like

  handle = LoadLibrary("DoNotDoThis.dll")

because Windows will then start to search in its usual manner, which usually involves the "working directory"(or at least /did/ involve in the past, or unless some "search path" related options are set e.g. with LoadLibraryEx). And usually the user has write permission to the "current work directory" and can (be tricked into) put whatever malicious DLL he wishes which is then dynamically "injected".

To be fair, the same can happen on other platforms, too, to some extend. It's just that the way Windows does (did?) resolve DLLs made it particularly easy (e.g. OS X is particularly picky about which shared libs it accepts).

The problem is surprisingly easy to solve: "Don't search with relative paths - ever!"

* Only search for plugins within known locations (which are considered reasonably safe, since a non-admin user typically has no write access to those places)
* Restrict the search path otherwise with the corresponding settings of LoadLibraryEx (I'm almost sure there are some, like LOAD_LIBRARY_SEARCH_APPLICATION_DIR, which restricts the search to the, well, application directory only)

I know, the above is somewhat unrelated to the actual question (and Qt does it right - right? ;)), but I thought it is worth repeating then and when.


So to respond to the actual question: Qt is able to search for SSL functionality (which in turn will resolve it's dependencies) *at runtime*, and if it's there, it's there (and will be used by Qt/QWebkit).


> 2, How can I stop the error message when there is no DLLs for me to bundle?

First off, maybe it is possible (I think it is) to analyse a *running application* with Dependency Walker, then you should be able to detect plugin linkage like OpenSLL and see its dependencies and where they come from.


Apparently your application does use SSL by making https:// connections to Google services. Probably Google enforces https (even when connecting to http://whatever.google.com), once Google sees that your browser is SSL enabled, which seems to be the case on certain client machines.

And even if you don't connect to those services, QWebKit will still try to resolve that OpenSSL library - or is that a deferred initialisation until a https connection is attempted? Then you would be lucky, because that would mean you could try to supress those https connections. But I doubt that is the case (the deferred initialisation), because even before connection time QWebkit needs to know its capabilities and advertise them during handshake with the server (I assume). Which would mean you probably have to ship a working OpenSSL + dependencies library if you want to make sure that your QWebkit enabled Qt app runs everywhere (even with incompatible libraries installed e.g. in c:\Windows\System32 or wherever Qt searches for OpenSSL libraries)

Cheers,
  Oliver


> 
> Regards
> Phil
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest