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) On Thu, Jun 23, 2016 at 12:50 PM, Russ Loucks <rjl at mnmicro.net> wrote: > > 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 > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160624/932d79a6/attachment.html>
