Bug 164225 - LibreOffice is vulnerable to LPE if it's installed to a non-default location
Summary: LibreOffice is vulnerable to LPE if it's installed to a non-default location
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
24.8.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:25.8.0
Keywords: security
Depends on:
Blocks: Automatic-Updater
  Show dependency treegraph
 
Reported: 2024-12-06 22:30 UTC by wdormann@gmail.com
Modified: 2024-12-18 10:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Crassus results (922.20 KB, image/png)
2024-12-06 22:31 UTC, wdormann@gmail.com
Details
Example of calc.exe running with SYSTEM privileges (3.18 MB, image/png)
2024-12-06 22:31 UTC, wdormann@gmail.com
Details

Note You need to log in before you can comment on or make changes to this bug.
Description wdormann@gmail.com 2024-12-06 22:30:50 UTC
Description:
LibreOffice allows the installing admin to choose a custom installation directory, but the installer does not set the ACLs of the target to be secure. Because the installer creates a service that runs with LocalSystem privileges and can also be started by non-admin users, a non-admin user can simply replace update_service.exe and then start the LibreOffice Maintenance Service to have update_service.exe run with SYSTEM privileges.

Steps to Reproduce:
1.Install LibreOffice to C:\Programs\LibreOffice
2.As a non-admin user, replace C:\Programs\LibreOffice\program\update_service.exe with the EXE of your choice.
3.As a non-admin user, start LibreOffice Maintenance Service

Actual Results:
update_service.exe, which was replaced by a non-admin user, runs with SYSTEM privileges

Expected Results:
A non-admin user should not be able to replace update_service.exe or plant DLLs in that directory.


Reproducible: Always


User Profile Reset: No

Additional Info:
## Recommendations
* Do not allow the installation directory to be chosen at install time
* Manually set ACLs for the installation directory
* If the installing user manually chooses an installation directory, warn them that this may affect the security of the system that the Ivanti software is loaded onto.
Comment 1 wdormann@gmail.com 2024-12-06 22:31:16 UTC
Created attachment 197995 [details]
Crassus results
Comment 2 wdormann@gmail.com 2024-12-06 22:31:43 UTC
Created attachment 197996 [details]
Example of calc.exe running with SYSTEM privileges
Comment 3 Buovjaga 2024-12-16 13:27:17 UTC
Not an easy hack candidate, so removing needsDevEval keyword
Comment 4 Commit Notification 2024-12-18 08:46:31 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5b2674b278fd48700409079803fbaf7ea177be61

tdf#164225: Only install MAR update_service when it will be needed

It will be available in 25.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Stephan Bergmann 2024-12-18 10:18:33 UTC
(In reply to wdormann@gmail.com from comment #0)
> ## Recommendations
> * Do not allow the installation directory to be chosen at install time
> * Manually set ACLs for the installation directory
> * If the installing user manually chooses an installation directory, warn
> them that this may affect the security of the system that the Ivanti
> software is loaded onto.

When looking how best to address this issue, none of the above items looked particularly promising:
* People will likely still want to decide where to put installations (esp. if they have multiple ones).
* For a user doing an installation to a place other than `C:\Program Files`, where they have all the necessary privileges, it would look odd for the installation process to remove those privileges (esp. since, in that case, a MAR update would not need admin privileges via the update_service.exe in the first place).
* Even adding some warning to the manual msi installation tab page turned out to be a somewhat non-trivial option, as the content of that page has to be laid out to the pixel (in instsetoo_native/inc_openoffice/windows/msi_languages/Control.ulf), with no spare place for such a warning.

My next thought was to only install LO's update_service.exe as a Windows service (i.e., grant its execution admin privileges) when it will actually be needed during MAR updates (i.e., when modifying the files in the install location requires admin privileges).  My hope was that one could somehow use Windows' GetNamedSecurityInfo, GetExplicitEntriesFromAcl, et al to determine upfront during LO installation whether modifying the files in the install location will require admin privileges later during a MAR update.  But I failed that, so what I did, at least for now, in my actual commit (cf. comment 4) is to conservatively base that decision on whether the install location is underneath FOLDERID_ProgramFiles (i.e., `C:\Program Files`).  There, the service will be needed during MAR update (so it is installed), but the install directory will not be writable by plain users (so this issue should not be exploitable).  When installing to other places, the service would likely not be needed during MAR update (so it is not installed, and this issue should be moot in that case).  Conservatively, the worst that can happen is that a MAR update could need the service after all but it is not installed.  Better approaches welcome.

Updated the release notes at <https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/25.8&oldid=777267> "MAR service restrictions".
Comment 6 Mike Kaganski 2024-12-18 10:24:10 UTC
(In reply to Stephan Bergmann from comment #5)

Note that, in a hypothetical scenario when the user has modified either Program Files location system setting (very non-trivial, completely unsupported by MS AFAIK), or changed its (subdirectory) permissions to be writable by users - that would be an own security breach, which we shouldn't try to mitigate ourselves. A user has a right to use their shootgun.