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

[Till Oliver Knoll]

Am 26.01.2014 um 20:46 schrieb Thiago Macieira <thiago.macieira at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140127/9851e4ca/attachment.html>