Replacing a dll (libeay32.dll) in my GnuWin32 bin directory (which is in the search path) I found out that it was in use by soffice.bin. LibreOffice comes with its own libeay32.dll in <Installdir>/program, but that is not used. My system is a german WinXP Pro SP3, but this should happen on almost all newer Windows versions beginning with XP SP2, because: On newer Windows Microsoft introduced the "safe DLL search mode" (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx), which is ON by default on everything newer than XP SP1, and this puts the local directory later in the search path to circumvent certain security concerns especially with web servers. For local programs to be able to load their own DLLs they have to issue a SetDllDirectory call (http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx) before loading the dynamic libraries. soffice.bin seems not to do so, however it should. There is a (severe?) security issue connected: when an attacker successfully places a rogue dll anywhere in the default dll search path (or adds the directory with his rogue dll to this path before soffice starts), soffice will happily load the attackers dll and not its own safe version.
Hi Tor: please have a look at the last paragraph of the description, I guess it will of interest for you. Best regards. JBF
If you let attackers place rogue DLLs in arbitrary places on your system, then indeed you have a security problem. That said, I *am* surprised by the claim that soffice.bin would pick up DLLs it needs from locations in PATH in preference to the one in the "program" subdirectory. That hardly can be the intention. Either something has broken this, or there is something special in the bug reporter's case that makes it happen.
If I read the web page you pointed to correctly, in all cases the directory from which soffice.bin is loaded is searched first, and that is where our libeay32.dll is located, isn't it? What am I missing?
(In reply to comment #3) > If I read the web page you pointed to correctly, in all cases the directory > from which soffice.bin is loaded is searched first, and that is where our > libeay32.dll is located, isn't it? What am I missing? Reread the page, and yes, you are right, and I was wrong thinking the cause was there. So I dug a little deeper and found: I see this happen with 2 DLLs, libeay32.dll and ssleay32.dll. They are not loaded from the start, but get loaded when the help browser gets called. With sysinternals' procmon I can see in which directories soffice.bin looks for them. They are: <installdir>\Basis\program\python-core-2.6.1\lib (1) %windir%\system32 (2) %windir%\system (3) %windir% (4) <installdir>\URE\bin (5) and then all PATH entries in order (6) This is exactly the order listed if SafeDllSearchMode is enabled, where we expect: (1) is the directory from which the application loaded (5) is the current directory but, looking at soffice.bin's environment through sysinternals' process explorer, I see still: the program's path is <installdir>\program\soffice.bin its current directory is <installdir>\program\ The help browser isn't started in its own process but as a thread of soffice.bin (using CreateThreadEx), so the kernel should honor soffice.bin's settings, but somehow it picks the python-core/lib directory as application load dir (because _ssl.pyd loads from there?) and URE\bin as current dir (?). It looks as if the kernel is not doing what it should according to MS' definitions, but somehow I feel the culprit might as well be with LibreOffice tricking some environment settings when loading the help browser?
facing this kind of problem 1) - old (incompatible) versions of libeay32.dll and ssleay32.dll are located in windows/system32 - correct dlls are in <libro>/program - using Libro python - import ssl fails on importing _ssl --> exploring with depends.exe, the 2 old dll are loaded from windows/system32 2) copying the 2 dlls located in <libro>/program to <libro>/program/python-core-3.3.3/lib where the file _ssl.pyd is located all is fine, the correct ddl are used (as they are in the same directory than there caller) 3) I tried to play with manifest files, with no success Not talking about security issue, this DLL hell may brake ssl support for python libreoffice binding (and other things ?) Any admissible suggestion to work on ? - manually duplicating the dll in <libro>/program/python-core-3.3.3/lib is an emergency hack but should not be used indefinitelly - manifest file (despite i did not success) could maybe solve the problem, but WinXP seems to have some restrictions (searches for manifest and files in the directory caller, the _ssl.pyd) --> back to step 2 - any building strategy on ssl support for python ? any strategy, hint, code pointers welcommed
So there are lots of related complexities here. (1) One of them is that our primary DLL's are in at least two folders - <installdir>\URE\bin <installdir>\program (2) Another is that python is calling the WINAPI method SetDllDirectory, which modifies the DLL search path. In theory, we could fix (1) simply by change the assignments to LIBO_URE_* for Windows in configure.ac. We already merge these folders on OSX. We can partially fix this problem by renaming our SSL DLL's so that we don't pick similarly named DLL's from other places. I suspect that we could fix it properly by doing two things (1) Combine URE\bin into \program (2) Use DLL redirection to enforce loading from our application folder first: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682600(v=vs.85).aspx
(In reply to Noel Grandin from comment #6) > (1) Combine URE\bin into \program I'll likely do that, for all remaining platforms, for LO 4.5.
i'll try to rename these 2 dll's
(In reply to Stephan Bergmann from comment #7) > (In reply to Noel Grandin from comment #6) > > (1) Combine URE\bin into \program > > I'll likely do that, for all remaining platforms, for LO 4.5. done a while ago
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Checked with Libreoffice 5.1.4.2 64bit on Windows 10 Pro and 4.4.7.2 on Windows XP Professional SP3 32bit: both loaded libeay32.dll and ssleay32.dll from <installdir>\program without searching other paths, not when starting the help browser, but when checking for updates. So I think this issue is solved.