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>
