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.
Created attachment 197995 [details] Crassus results
Created attachment 197996 [details] Example of calc.exe running with SYSTEM privileges
Not an easy hack candidate, so removing needsDevEval keyword
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.
(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".
(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.