LO and Defender Mitigations

[usable_sublevel]

Windows Defender has what’s called “Exploit protection settings”. In Powershell, these are called ProcessMitigation. There’s one ProcessMitigation that prevents LO from running. In the GUI this setting is called “Validate handle usage”. In Powershell this setting is called StrictHandle. We have it enabled by default, i.e. system-wide.

Documentation of this setting

With this mitigation enabled, LO cannot start, and produces the following error

LO does not have a problem with any other of the mitigation options we have enabled.

You can create exceptions in Defender though, and except a process from mitigations. Doesn’t help LO. I believe that this is due to LO running from soffice.bin. Defender can create rules and exceptions to .exe only. I have another program NoMachine that also runs from .bin files, and same issue. Cannot run with StrictHandle enabled, and cannot create exceptions for it.

System-wide changes to ProcessMitigation (or via the GUI) do not take effect until reboot. This means that to run LO, I need to remove the mitigation and reboot.

Has anyone figured out a way to work these two? I assume that .bin files run under some other system exe, which I can except. Process exceptions can be effected without rebooting (by killing and restarting the process)

Possible to take this into development consideration?

Was unable to find anything on the web related to this, or anything close.

[EarnestAl]

I see from your link that “This mitigation is automatically applied to Windows Store applications”. So does LibreOffice from Microsoft Store work?

[usable_sublevel]

Didn’t know LO was available in the Store. I’ll try that.

I expect that it’ll be the same. I expect that what the documentation says, applies to modern Apps only, not to Win32 apps, even from the Store. (This goes into the mess the Store has become). Anyway, I’ll try that later, and report. Good idea.

[usable_sublevel]

Welp, cannot test with Store version. Since it’s a purchase, which requires login. Don’t want to login. Price is small ($4.95) and not the issue. Login is.

Anyway, I’m quite confident that this would be the same with the Store version, as I explained above.

I went through my settings to see if other programs have problems with StrictHandle. Other than the aforementioned NoMachine, which also runs from .bin files, I only have one other program that doesn’t work with StrictHandle enabled. That one program does not run from .bin files, and excepting the exe solves the matter. All other programs (long list. the usuals, and many more) function properly with StrictHandle enabled.

Edit: adding context. This issue is not a new one. Have been unable to run LO on my machines for years. Only recently have I been able to narrow it identify the cause so clearly. Needing an exception, but cannot except .bin files.

If we’re talking about needing an exception, I ain’t no dev, but it seems that this situation of “referencing an invalid handle”, is essentially a bug. So a bug to fix.

[mikekaganski]

This powershell command (as admin)

Set-ProcessMitigation -Name soffice.bin -Enable StrictHandle

allows to repro. Have you filed the bug report yet? Please do and post the number here.

[mikekaganski]

OTOH: running "C:\Program Files\LibreOffice\program\soffice.exe from cmd.exe runs fine. Running soffice.exe from Windows Explorer fails the same way, but running soffice.com succeeds - and these two executables do the same thing preparing environment and calling soffice.bin the same way (the only difference is that one is GUI application, and the other is console subsystem).

It looks like it’s some bug in Windows shell, because it only fails when run from shell (explorer - be it directly, or through the shortcut).

Maybe still file the bug, but to MS?

[usable_sublevel]

Both your solutions work.
Didn’t think to try making the exception via PS. Didn’t think PS will allow non-exe exceptions. Windows is full of inconsistencies.

I prefer the second solution, running soffice.exe via CMD. Less defense disabling. Same is true for the other executables, sbase, scalc, sdraw, swriter. Runnin from Explorer all will fail, but works fine if run by command. Running soffice.com from Explorer keeps the console window open as long as LO is open.

And you’re right. All of this seems like Windows bugs.

Thanks!

[usable_sublevel]

Solutions summary:

Best solution: Change the name of the LO shortcut, like removing the version number, or simply copying it to a new shortcut. Change Target to C:\Windows\System32\cmd.exe /c start “” “C:\Program Files\LibreOffice\program\soffice.exe” (or C:\Windows\System32\cmd.exe /c start “” “C:\Program Files (x86)\LibreOffice\program\soffice.exe”). Optionally change icon to LO. Do not make these changes to the original shortcut without changing its name, because upon installation of a newer version, the modified shortcut, if left in its original name, will be overwritten by a new one.

Run soffice.exe from CMD

Create soffice.bin StrictHandle exception via Powershell