Description

Collabora Online delegates document operations to the engine (LibreOfficeKit) running in a per-document kit process. When a session is marked read-only (e.g. a viewer-role WOPI user), the engine is expected to refuse operations that mutate the document. Several code paths did not check the read-only state, allowing a user in a read-only session to send crafted WebSocket messages that execute document-mutating UNO commands.

Details

In RO-mode the UI presented is typically one that only offers RO operations, but that is not part of the security apparatus and can be toggled to RW-mode by an adept user. It is the server-side that is intended to enforce the RO rules, but for some commands and dialog operations those were not enforced when the client attempted to perform edit operations.

Impact

A read-only user cannot save the document. Changes made by exploiting this issue exist only in the live kit process instance and are discarded when the session ends. The practical risk is limited to two scenarios:

• Misleading co-viewers - other users viewing the document in the same session would see the modifications
• Piggybacking on an editing session - If the user with editing permission was joined by a user with view-only permission the view-only user could make some modifications which the editor could save without realizing changes had been introduced.

This is a server-side authorization failure: the server trusts client-supplied or client-influenced permission data rather than enforcing access control independently.

Fixes

1. General ReadOnly guards were added to dialog interactions.
2. Various UNO commands were reclassified as unavailable server-side for RO views.

Credits

Thanks to Gopal Singh Raigoni for discovering and reporting this vulnerability.