<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 24, 2016, at 3:35 PM, Dan S <<a href="mailto:danchik@rebelbase.com">danchik@rebelbase.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>less headache static linking to SSLEAY32 and LIBEAY32 :), depending on how many windows versions you want to support, static linking to WS2_32 and CRYP32 may also be useful (though linking all 4 nearly tripled the binary for what we needed to have included), but don't have to worry about what version or SP is on the target machine and not bother with redistributables that may otherwise be needed on some installations... Also, lib dependencies in manifests may be treated differently between platforms and I am not sure if dependencies can be separated by the platform (for example 7 will accept abs paths, vista will expect paths to be relative to the location of the manifest file (embedded or near the .exe) and XP wants them relative to the exe (placing the dlls, the manifest and the exe in the same could avoid that, however lunching from different user accounts may again be a headache (ex. SUBSTed or hard linked paths on current user may differ from those of the run as user as in launching an app from SUBSTed (at login) path, for example, will fail to find the DLLs in current folder on vista and xp if you run as administrator that never had the startup script SUBST any drives)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 12:50 PM, Russ Loucks <span dir="ltr"><<a href="mailto:rjl@mnmicro.net" target="_blank">rjl@mnmicro.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="-ms-word-wrap: break-word;"><div><div class="h5"><br><div><div>On Jun 23, 2016, at 1:44 PM, Jakob Bohm <<a href="mailto:jb-openssl@wisemo.com" target="_blank">jb-openssl@wisemo.com</a>> wrote:</div><br><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 23/06/2016 18:25, Russ Loucks wrote:<br>
</div>
<blockquote type="cite">
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></div></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><span><br>
----Russ Loucks<div style="margin:0px"><font face="Helvetica">mailto: <a href="mailto:rjl@mnmicro.net" target="_blank">rjl@mnmicro.net</a></font></div>Winter is coming
<br></span></div><br>--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" target="_blank" rel="noreferrer">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br></blockquote></div><br></div>
-- <br>openssl-users mailing list<br>To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br></blockquote></div><div><br></div>Got this to work on the HP tablets by statically linking the OpenSSL libraries into our app. Interestingly I have a Toshiba Encore tablet running Windows 8.1 and applied all the upgrades and our app didn’t break like it did on the HP. Oh, well, I like the solution.<div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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;"><br></div><div style="orphans: 2; widows: 2; margin: 0px;"><div style="margin: 0px;"><font face="Helvetica">“Until you teach someone calculus, they can’t even walk finite distances. </font><span style="text-align: -webkit-auto;">But they can get reallllllly close.”</span></div><div style="margin: 0px;"> - Saturday Morning Breakfast Cereal</div><div><br></div></div></div><br class="Apple-interchange-newline">
</div>
<br></div></body></html>