<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body 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.<br>
</tt><br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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 </pre>
</body>
</html>