Bug Hunting Session
Bug 67313 - Libreoffice 4.1 tries to load URE's store.dll from Windows directory
Summary: Libreoffice 4.1 tries to load URE's store.dll from Windows directory
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: BSA target:4.2.0 target:4.1.2
Keywords: regression
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-07-25 16:40 UTC by real name
Modified: 2013-08-30 06:31 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description real name 2013-07-25 16:40:33 UTC
Problem description: 

Steps to reproduce:
1. have an old windowsxp installation with who-knows-what kind of misc. odd DLLs installed

this will be hard to repro, but I immediately found two previously unproblematic windowsxp professional 32bit machines, that ran many of the recent years worth of libreoffice just fine. today came the upgrade to libreoffice 4.1 via the official signed installer packages (.msi), and the 4.1 would not start up, as a popup would complain that soffice.bin was reporting that c:\windows\system\STORE.DLL was not a valid application or file or something.

that store.dll file existed on both of those machines, and uploading it to a virus checker (virustotal) showed that it was previously unknown to the online database there.

filedate of store.dll dates back to 1993! although there are plenty of rather old files in windows\system\ (not NOT system32) on windowsxp machines, for compatibility reasons and other things, this store.dll file was almost the oldest in there, the file properties say that its supposedly by microsoft mail store layers from the year 1993 

sha256 of store.dll file is:
757019059f3ca83aeb182385403a461342005423605b6502231ac6fcdf130598

analysis report can be found:
<https://www.virustotal.com/en/file/757019059f3ca83aeb182385403a461342005423605b6502231ac6fcdf130598/analysis/>

after renaming this file to something else, soffice.bin and the whole app starts up normally.

Expected Behavior:
Libreoffice code should make sure its not loading arbitrary DLLs accidentally or on purpose but only its own or well known legit DLLs and libraries and components.

When searching google for libreoffice and store.dll there is actually some source code or source code filenames and paths coming up that are named storedllapi.h or similar stuff, I wonder if thats maybe got to do something with this bug

<https://www.archlinux.org/packages/extra/x86_64/libreoffice-sdk/files/>
....
usr/include/libreoffice/store/
usr/include/libreoffice/store/store.h
usr/include/libreoffice/store/store.hxx
usr/include/libreoffice/store/storedllapi.h
usr/include/libreoffice/store/types.h
....

Operating System: Windows XP
Version: 4.1.0.4 release
Last worked in: 4.0.4.2 release
Comment 1 Urmas 2013-07-25 18:32:37 UTC
Confirming.
Comment 2 Stephan Bergmann 2013-07-26 09:10:05 UTC
This is a regression caused by <http://cgit.freedesktop.org/libreoffice/core/commit/?id=c9c963d3e6991d0dd73a95fc9734e38683d5be9c> "autoinstall ure private libraries" changing the name of the URE library from store3.dll to store.dll on Windows.  That DLLs from LO's URE\bin directory can be shadowed by ones with identical names from various Windows system directories when running LO is a known gotcha.

The easiest workaround might be to use the same "...lo.dll" naming scheme for those private URE DLLs that is already used for most of LO's non-URE DLLs.
Comment 3 Commit Notification 2013-08-27 12:15:35 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=644c33a857c46d540202189228f519946dc33833

fdo#67313: Use "lo" suffix for private URE libs



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 4 Stephan Bergmann 2013-08-28 15:09:25 UTC
requested backport to libreoffice-4-1 towards LO 4.1.2 with <https://gerrit.libreoffice.org/#/c/5667/>
Comment 5 Commit Notification 2013-08-30 06:31:28 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c4caf52724629d15a1d73c51c4f66e4f6011f7a&h=libreoffice-4-1

fdo#67313: Use "lo" suffix for private URE libs


It will be available in LibreOffice 4.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.