<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 23, 2016, at 1:44 PM, Jakob Bohm <<a href="mailto:jb-openssl@wisemo.com">jb-openssl@wisemo.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/06/2016 18:25, Russ Loucks wrote:<br>
</div>
<blockquote class=" cite" id="mid_81046AB7_D60E_4F99_84FC_F58E1D537E40_mnmicro_net" cite="mid:81046AB7-D60E-4F99-84FC-F58E1D537E40@mnmicro.net" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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.<br>
<br>
We're using version 1.0.2 of the OpenSSL libraries.<br>
<br>
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.<br>
<br>
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).<br>
<br>
Works well.<br>
<br>
Until the user runs Windows updates....<br>
<br>
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'.<br>
<br>
I've tried the following - all to no avail:<br>
<ul>
<li>removing the HP and Intel OpenSSL libraries (but
safe-keeping them for later re-installation)</li>
<li>Re-installing our application and OpenSSL libraries<br>
</li>
</ul>
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....<br>
<br>
I'm stumped. Any clues?<br>
<br>
I'm guessing the best course of action is to statically link the
OpenSSL libs into our app. Is that a good plan?<br>
<br>
Thanks for the help.<br>
<br>
<br>
</blockquote>
<tt>Over the past few years, Microsoft has been phasing in a
security <br>
improvement (and it is an improvement) to protect against remote <br>
attackers dropping trojanized replacement DLLs in an unsecured <br>
(document) directory which they have reason to believe will be <br>
the current directory when the attacked program is loaded. <br>
This change consists of a change in the default search order <br>
for DLLs where no explicit directory is passed to LoadLibrary/<br>
LoadLibraryEx, and a very similar change to the search order for <br>
DLLs that are named (with no path obviously) in the import tables
<br>
in programs and other DLLs.</tt><tt><br>
<br>
The recommended best practice for DLLs loaded by linking to an <br>
import library (which contains the needed entries for the import <br>
table) is to leave OS owned standard DLLs in System32 (SysWoW64 <br>
for 32 bit programs on Win64), use explicit manifest version <br>
references in the calling EXE/DLLs linked in manifest (don't trust
<br>
the manifest generator in Visual Studio, it tends to get details <br>
wrong), and put application specific DLLs (including private <br>
copies of stuff such as SSLEAY32.DLL) in the same directory as the
<br>
referencing EXE/DLL file.<br>
<br>
Playing around with the PATH environment variable when installing
<br>
programs is generally considered worst practice due to the risk of
<br>
affecting other programs by inflicting your own DLLs etc. on them.<br>
<br>
As a side effect of all this, having a dedicated lib/dll subdir in
<br>
your install dir will generally not work unless you load all those
<br>
DLLs via your own calls to LoadLibrary/LoadLibraryEx with <br>
explicitly computed full pathnames, thus such a dir is now only <br>
good for plugins and other on-demand loaded components. With a <br>
little tweaking it could also be useful for OpenSSL engine plugin
<br>
DLLs.</tt></div></blockquote><br></div>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.<div><br></div><div>I’ll let you know what I find.</div><div><br><div apple-content-edited="true">
<div><div style="orphans: 2; widows: 2; margin: 0px;"><font face="Helvetica">----</font></div><div style="orphans: 2; widows: 2; margin: 0px;"><font face="Helvetica">Russ Loucks</font></div><div style="orphans: 2; widows: 2; margin: 0px;"><font face="Helvetica">mailto: <a href="mailto:rjl@mnmicro.net">rjl@mnmicro.net</a></font></div><div style="orphans: 2; widows: 2; margin: 0px;"><font face="Helvetica">Winter is coming</font></div></div>
</div>
<br></div></body></html>