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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160623/5cc23921/attachment.html>
