[openssl-users] Unable to run application after Windows updates

[Jakob Bohm]

On 23/06/2016 18:25, Russ Loucks wrote:
> We have an application running on Windows 8.1 (HP) tablets that is 
> mostly statically linked except for a few libraries, including the 
> SSLEAY32 and LIBEAY32 libraries.
>
> We're using version 1.0.2 of the OpenSSL libraries.
>
> We ship our executable and these two libraries and then set a PATH 
> entry in the registry that points to our 'lib' directory so the 
> system/library loader can find the libraries at load/run time.
>
> There are two other packages on these tablets we ship that include 
> older versions of the OpenSSL libraries - Intel TXE Components/TCS 
> (OpenSSL version 1.0.0g) and HP Registration service (1.0.0d).
>
> Works well.
>
> Until the user runs Windows updates....
>
> Then, when our application starts we get a 'The ordinal 3905 could not 
> be located in the dynamic link library 'C:\program Files\<our 
> installdir>\lib\SSALEAY32.dll'.
>
> I've tried the following - all to no avail:
>
>   * removing the HP and Intel OpenSSL libraries (but safe-keeping them
>     for later re-installation)
>   * Re-installing our application and OpenSSL libraries
>
> Interestingly, the OpenSSL libraries in the HP and Intel installations 
> do not change after the Windows update - they're the same versions as 
> before the update....
>
> I'm stumped.  Any clues?
>
> I'm guessing the best course of action is to statically link the 
> OpenSSL libs into our app.  Is that a good plan?
>
> Thanks for the help.
>
>
Over the past few years, Microsoft has been phasing in a security
improvement (and it is an improvement) to protect against remote
attackers dropping trojanized replacement DLLs in an unsecured
(document) directory which they have reason to believe will be
the current directory when the attacked program is loaded.
This change consists of a change in the default search order
for DLLs where no explicit directory is passed to LoadLibrary/
LoadLibraryEx, and a very similar change to the search order for
DLLs that are named (with no path obviously) in the import tables
in programs and other DLLs.

The recommended best practice for DLLs loaded by linking to an
import library (which contains the needed entries for the import
table) is to leave OS owned standard DLLs in System32 (SysWoW64
for 32 bit programs on Win64), use explicit manifest version
references in the calling EXE/DLLs linked in manifest (don't trust
the manifest generator in Visual Studio, it tends to get details
wrong), and put application specific DLLs (including private
copies of stuff such as SSLEAY32.DLL) in the same directory as the
referencing EXE/DLL file.

Playing around with the PATH environment variable when installing
programs is generally considered worst practice due to the risk of
affecting other programs by inflicting your own DLLs etc. on them.

As a side effect of all this, having a dedicated lib/dll subdir in
your install dir will generally not work unless you load all those
DLLs via your own calls to LoadLibrary/LoadLibraryEx with
explicitly computed full pathnames, thus such a dir is now only
good for plugins and other on-demand loaded components.  With a
little tweaking it could also be useful for OpenSSL engine plugin
DLLs.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160623/5cc23921/attachment.html>