Privilege escalation (PR) from account through UIX and cleaned HTML macros

Steps to reproduce:

1. Log in as a user without script or programming rights.
2. Edit the user profile or any other editable document using the object editor (enable advanced mode before if necessary).
3. Add an object of type XWiki.UIExtensionClass
4. As content, set

   {{html wiki="true"}}~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~1~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}~{{/html}}
   
   {{html wiki="true"}}~<~!~-~-~ ~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~ ~i~d~=~"~h~t~m~l~s~e~c~u~r~i~t~y~"~ ~t~i~m~e~T~o~L~i~v~e~=~"~1~"~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~"~H~e~l~l~o~ ~f~r~o~m~ ~g~r~o~o~v~y~!~"~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}~ ~-~-~>{{/html}}
   

5. As "Extension Point ID", set org.xwiki.platform.html.head
6. As "Extension ID" set org.xwiki.myuser.test (just needs to be unique)
7. As "Extension Scope", select "Current User"
8. Click "Save & View"
9. Open <xwiki-server>/xwiki/bin/view/Main/?sheet=CKEditor.ContentSheet&xpage=plain where <xwiki-server> is the URL of your XWiki installation.
10. View the HTML source of this page.

Expected result:

The output includes

{{/html}} {{cache}}{{groovy}}println(1){{/groovy}}{{/cache}}

and

<!-- {{/html}} {{cache id="security" timeToLive="1"}}{{groovy}}println("Hello from groovy!"){{/groovy}}{{/cache}} -->

, possibly with some characters escaped.

Actual result:

The output includes

<p>&nbsp;1&#123;&#123;/html}}&lt;!<del>&nbsp;&#123;&#123;/html}} Hello from groovy!&nbsp;</del>

This shows that both Groovy macros have been executed and thus demonstrates a privilege escalation from account to programming rights.

An explanation how this exploit works:

1. We use wiki="true" on the HTML macro to be able to get a raw

   {{/html}}

   in the output by escaping everything with XWiki syntax escaping.

2. As the user doesn't have script rights, this output is filtered using restricted HTML cleaning. This cleaning apparently escapes { neither in plain text nor in HTML comments. In the first example, we needed to avoid " to not to trigger HTML escaping but in comments no escaping happens, you only need to pay attention to not to close the HTML comment.
3. The HTML macro returns its result as a raw block which is then printed by the XHTML renderer without any further escaping.
4. The result of the renderer is printed without any further escaping inside an HTML macro inside CKEditor.ContentSheet which simply displays all UIX of that type.

There are several places where this attack could have been prevented:

1. Restricted HTML cleaning could remove HTML comments as they tend to allow dangerous attacks, though this doesn't completely prevent this attack as the first snippet shows, it just makes it more difficult.
2. The HTML cleaner could in general escape { while serializing the DOM, though this may be difficult in HTML comments without duplicating the escaping that XWiki already uses when printing HTML comments (but if we also escape { in general in HTML comments, it might be feasible to just escape {{ as this wouldn't trigger if the escaping had already been applied).
3. The XHTML renderer could escape { in raw outputs. Again, the problem is how to escape comments as in this case it wouldn't even be possible to detect if we're in a comment. It could be a solution, however, to again, just escape {{ and just avoid that this sequence appears in HTML comments or any other code that is generated by XWiki. A real problem are also most likely script-tags where no escaping is needed and thus any escaping would probably hurt - and JavaScript or JSON use a lot of { - and we have no way to even detect where script tags are.
4. The CKEditor.ContentSheet could have tried escaping the output, though this is again difficult as it is not clear how to escape { in a raw HTML block. However, in this case a similar escaping actually already exists because of CKEDITOR-134 so in this particular case this would actually work. However, we have other places where such a nice workaround doesn't exist.
5. The displayed UIX could also have been limited to UIXs defined in documents authored by users with admin rights, limiting the attack to admins - I don't see any reason why in this particular case per-user UIX should be displayed. It is not unlikely that the same can be concluded for other UIXPs that are included in XWiki.

Note that the first two options are only relevant for users without script right as with script right, HTML cleaning can be disabled. We'll need a proper discussion on the forum to decide how to fix this.