Change Notice: Cross-space moves

[#1]

Hello Confluence Admins,

We want to explain changes to cross-space page moves that resulted from patching a recently discovered vulnerability. The changes desupport an estimated 10-15% of cross-space page moves.

What was the vulnerability?

Summary: Moving a subtree (page+child pages) across spaces could allow for a user to inappropriately access and modify previously restricted child pages. 

Given a user with the following permissions:

In the Source Space User is NOT a space admin User has delete page permission User has create page permission User has edit restrictions on the page

In the Target Space User is a space admin

the user can move a page and all child pages to a space where they are a space admin. In the Manage Pages>Restricted admin screen, the user can then access any previously restricted child pages.

How did we patch it?

Only space admins of the source space can move a page out of the space. This patches the vulnerability as the space admin of the source is already allowed to access those restricted pages via the Manage Pages>Restricted admin screen.

What other options were considered?

Disallow page moves if any child pages were restricted: This had the benefit of absolutely patching the vulnerability, but with significant UX and technical impact

• UX: When a page move fails due to a child page that the user cannot see due to restrictions, there is no self-remediated solution and requires a space admin to assist.

• Technical: This would result in desupporting more than 30% cross-space page moves and the user would require space admin intervention to troubleshoot/remediate. Additionally, to perform permission checks along the entire subtree when the user is attempting to move a page has significant scale and performance risks. 

Only move pages in the subtree that the user can access: Similarly, this patches the VULN but has UX and technical impact

• UX: More user research is required to understand proper handling of stranded pages and retaining the subtree structure. Stranded or structural placeholder pages could cause additional clutter or confusion without proper treatment.

• Technical: To perform permission checks along the entire subtree when the user is attempting to move a page has significant scale and performance risks. Additionally, the scope of these changes is large which leaves the vulnerability open for significantly longer and has higher risk of bugs.

Next Steps

With our commitment to security, we made a hard trade-off to close this serious security risk with expediency while limiting breaking existing flows. Any future iterations on improving the cross-move experience will be considered for future roadmapped based on impact. One possible future solution is linked below- please vote/comment/follow this feature request if applicable to your organization.

CONFCLOUD-6645 - Add "Move Page" permission 

[Steve Rhodes]

I appreciate the work that has gone into fixing this even though it means non-space admins being unable to move their page tree without help. This is an important fix, and thanks for also explaining the reasons and the other options.

[Tim Eddelbüttel]

What makes me curious here, is the fact that you consider this now after > 10 years a vulnerability and reopen the request on Cloud.

Would it not be consequent, if it's handled as a vulnerability, to also reopen the corresponding Confluence DC issue?

[dhur]

@Tim Eddelbüttel This is great feedback that I will pass along to my counterpart for Confluence DC. 

As to why now?

A variant of this VULN was surfaced for Confluence Cloud by an independent security researcher via our Bug/VULN Bounty program. We patched that one immediately, and inventoried/tested for other potential VULNs that were similar in nature. This cross-space page move VULN surfaced from that investigation. This is how this older defect was brought to our attention- many of us closest to the VULN have been with Confluence Cloud for just a few years.

Thanks @Tim Eddelbüttel !

[Christopher G Andrews]

You have created an administration and user nightmare.  If you create a page in the wrong space, you now have to ask for admin permission to move the draft.  We just migrated and we have a lot of pages to move around to reorganize, now we have to elevate users to admin level access to page a page they own and have delete permissions on?  Maybe also update your error messages that you show users when they try to move pages to point to this.

This move put data at risk, you are locking data in spaces that it should not be in.  You just moved the security issue to us the users when you have other technical solutions that would have not broken functionality for most people. 

[Giuseppe Ursino]

Thanks for sharing this information and fix the vulnerability, but I am not convinced that it is the correct solution because it shifts burdens and implicit responsibilities regarding the page contents onto the admins.

Please consider this case:
Admin A: space administrator
User B permissions: page creation, delete and restrictions.
User C permissions: page creation, delete

Page Tree:
P1 - no restrictions
P1 > P2 - P2 is child of P1 and is restricted only to User B

User C ask to Admin A to move the page P1 to another space where User C is admin.

Admin A do not immediately know that P1 has a child because P2 is accessible only to User B, so he move the page.

User C on destination space can see the content on P2.

The only correct solution is to have a separate permission, like describes on CONFCLOUD-6645.

Please revert the fix and schedule the issue CONFCLOUD-6645.