Problem with Directory OPUS's viewer and ReHIPS

[Stephen]

I now use Directory OPUS as my file manager. Among its features is a viewer that allows one to see the content of various documents (images, text, Office, PDF etc.).

I'm having a problem with Acrobat Reader DC which apparently is used by Directory OPUS for PDF file viewing. Firstly, Acrobat Reader shows the attached image on starting up the program.

Secondly, the Security settings of Acrobat Reader are shown as attached.

Thirdly, Acrobat Reader is set by ReHIPS to run in an Isolated Environment.

The problem described above also affects MS Office documents such as Word and Excel files, presumably for a similar reason. I'm highlighting Acrobar=t Reader here for the purpose of explaining what is going on.

If I disable ReHIPS then Directory OPUS's viewer works with no problem.

EDIT: I solved the pdf problem as follows. I downloaded SumatraPDF and installed it by enabling the option of a Windows PDF handler (if I remember correctly). Now pdf files are displayed in the Directory OPUS viewer.

I'll have to wait a while and test a bit more MS Office files and LibreOffice files.

EDIT 2: I can confirm that there is a problem with MS Office and LibreOffice files. They are not shown properly in Directory OPUS unless ReHIPS is disabled.

[fixer]

Thank you for your report, let's see.

Acrobat Reader is isolated in ReHIPS default rules as these rules were created when it didn't support AppContainer. If you use AppContainer, it can be allowed in ReHIPS. Some of you may say "hey, be consistent, in your blogpost https://forum.rehips.com/index.php?topic=9533 you recommended to isolate in ReHIPS for cases like this". You're right, but keep reading.

Why doesn't it work in ReHIPS? The problem is partly Windows and partly tight Acrobat sandbox restrictions. Windows in its msctf.dll has poor handling of some class freeing memory at first and then referencing its memory including handles causing invalid handle to be addressed (this will be covered in a separate blogpost). And sandbox doesn't allow it to address invalid handles causing it to crash immediately. Acrobat doesn't expect this crash and shows the window that something is incompatible.

[Stephen]

Thank you for the explanation although to be honest I didn't fully understand. Too technical for me!

There remains a problem with MS Office and LibreOffice files. Is there any possibility that a solution may be found for these? I don't see anything in the ReHIPS rules settings that could help me solve it. The Directory OPUS programs include a few executables that appear, judging by their name, to be connected to the viewer function, but they are not listed in the ReHIPS rules settings and I cannot add them anyway.

[fixer]

Could you please explain more about Office files? What exactly doesn't work? Any errors? Any screenshots.

[Stephen]

Directory OPUS is a file manager with a feature to preview in a separate pane files that are selected in the file listing pane. This includes images, pdf files, text files and Office files.

The problem with Office files is that they are not shown in the Preview pane if ReHIPS is in any mode other than disabled. As soon as I set ReHIPS to disabled, the Office files are immediately viewed in the preview pane. If I re-enable ReHIPS the problem appears to be gone, but it comes back if I log out and log in to Windows and repeat the exercise of viewing Office files in the preview pane.

What may be worth mentioning is that when I disable ReHIPS and try to preview a Word document (actually it is a LibreOffice document with an odt extension) a dialog comes up saying "Microsoft Word isn't your default program for viewing and editing documents. Do you want to select the file types that Word should open?".

If I respond with No, then the previews load properly. If I respond with Yes then I'm taken to Windows settings to define which program should open Word documents etc. Even if I make no changes in Windows settings, the previewer in Directory OPUS then works as I describe above. Strangely, this also fixes Excel document previews, but again it's a temporary thing. Moreover, no dialog ever comes up about Excel, but only about Word.

EDIT: This is an interesting thread: https://resource.dopus.com/t/activex-preview-office-web/5472/5
Please note that Windows File Explorer with preview enabled does not show previous of Office documents and in fact exhibits a similar behavior to what I had experienced. I don't know if this may help the ReHIPS developers discover what it is with ReHIPS that causes this problem.

[fixer]

And to make sure we're on the same page, what MS Office and Libre Office versions do you use?

[Stephen]

I use MS Office 2019 32 bit and LibreOffice v.6.3.2.2 64 bit.

[fixer]

Looks like they use OLE (Object Linking and Editing) for preview. This way a host process (DOPUS or explorer in this case) starts a child process to handle the file and give parsed preview to the host. They need to comminucate with each other which becomes impossible since one of them (child in our case) is isolated and the other one is not.

It's hard to solve this one in a good way. In terms of danger, preview is almost the same as standard file open. If it's some kind of exploit, opening or previewing it, will trigger the payload. And correct previewing requires communication with a non-isolated process. This basically means that some possibly dangerous process that should be isolated will have some access to the non-isolated process. Allowing it may not end well.

[Stephen]

Just academically speaking, would it work at all if I run DOPUS in an isolated environment? Would it place both the host and the child at an equal level?

[fixer]

I'm not sure about latest released version 2.4. Because building parent-child chain for an isolated process wasn't fully supported in ReHIPS 2.4. But in upcoming ReHIPS 2.5 having host and child in the same isolated environment solves the issue.

[Stephen]

Thank you. That's good to know.