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

[Russ Loucks]

On Jun 23, 2016, at 1:44 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> 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.

Thanks much for the info.  I’ll work on two options - statically linking the libs and, if that doesn’t work, augmenting our existing app manifest to bind the app to the  DLLs.

I’ll let you know what I find.

----
Russ Loucks
mailto: rjl at mnmicro.net
Winter is coming

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