CVE-2023-29526: Async and display macro allow displaying and interacting with any document in restricted mode

Steps to reproduce:

1. Enable comments for guests by giving guests comment rights

2. As a guest, create a comment with content

   {{async}}{{display reference="Menu.WebHome" /}}{{/async}}

   and another one with content

   {{async context="request.parameters"}}{{display reference="FlamingoThemes.WebHome" /}}{{/async}}

3. Open the comments viewer from the menu (appends ?viewer=comments to the URL)

4. Right-click and copy one of the URLs for "Use this theme", e.g., the URL of the “Cyborg” theme. It should look like http://localhost:8090/xwiki/bin/view/FlamingoThemes/?action=setTheme&theme=FlamingoThemes.Cyborg&form_token=bw2VMc2UsUhxQk6LS1yYoQ but with a different token.

5. Paste the copied URL after the current URL in the address bar and replace everything before the ? by & and open this new URL.

6. Reload the page.

Expected result:

The menu home page isn’t displayed as guests don’t have view rights on Menu.WebHome and the theme is unchanged.

Actual result:

The menu home page is displayed and the theme has been changed to the Cyborg theme.

This demonstrates that the display macro inside the async macro allows displaying arbitrary documents in the comments viewer as the context user is now superadmin and that those documents aren’t restricted in any way and we can interact with them via the request parameters and execute actions as superadmin when the documents contain such code as the theme selector. Already with the theme selector, we’ve also obtained the CSRF token of superadmin which is useful in case some document requires it. I’ve experienced errors (generally, null pointer exceptions) with some documents like CKEditor.HTMLConverter (which would be the key to universal RCE) so I’m not sure how universally this can be used to gain privileges, maybe also more context entries need to be preserved to prevent these errors.

I’ve reproduced this issue on 14.9 and on the most recent 14.10 snapshot but it seems likely that this issue can also be reproduced on older versions of XWiki.