Restoring account backup packages from unknown, or untrusted, sources

[cPanelKenneth]

We’ve been getting some interesting and valuable feedback from the cPanel Community recently concerning the security model used by the transfer and backup restore system. We’d like to address these concerns here and provide the Community with some clarity on this topic, directly from cPanel.

First, we want to highlight again, the risk of restoring account backup packages from untrusted or unknown sources. We need to ensure that everyone has the opportunity to be conscious of the security concerns associated with this process.

The account backup package system (pkgacct) is designed to transfer an account between machines inside your ecosystem. This system's primary goal is to prefer replication integrity in order to simplify the process of migrating your accounts between your servers.

• In order to achieve this goal it must copy the entire account, along with its configuration, privileges, customizations, files, and permissions that the account has been granted.
  
• The system is not designed to handle untrusted data. There are a myriad of ways a malicious user can alter an account backup package to escalate privileges, or add additional privileges to an account backup package.
  
• We strongly recommend that you do not restore data from untrusted sources. It is for this reason that the restore system has always been limited to the root user.

It has recently been brought to our attention that the restoration of account backup packages from an untrusted or unknown source may be a more common practice then we envisioned. In addition, our warnings against doing so have been inadequate to discourage the restoration of untrusted account backup packages.

We understand the value that this workflow offers, and we want to offer a way to accomplish restoring account backup packages from untrusted sources in a more secure manner. The security and integrity of your system is very important to us.

Your feedback, along with the consideration of the desired workflow, has prompted us to reevaluate our current system and develop a new goal of delivering a more robust solution.

1. We will soon release an update that adds the warnings present in the CLI restorepkg script to the WHM UI. The warnings will be expanded to explain why account backup packages from untrusted sources should not be restored using the current system.
   
2. We have launched a high priority project to develop an alternate system for handling the restoration of untrusted account backup packages. This new system will restore a limited, safer subset of the data. The primary goal of the new restore tool will be to prefer the security of the restore over replication integrity. We will endeavor to provide as much of the current restore functionality with the new untrusted account backup package restore tool as possible. During the new transfer and restore process, you will be able to clearly select which system you want to use (trusted or untrusted) to restore an account backup package.
   
3. The CLI restorepkg tool will be renamed to restore_trusted_pkg. Once development of the untrusted account backup package restore system is complete, a restore_untrusted_pkg CLI tool will be added.

For the avoidance of doubt, untrusted sources means anyone you would not already trust with root access to the server.

Update 2-14-01-08

The team continues to make progress on this feature. They are currently focused on performing inspections, and warnings, during account transfer.

 

[cenourinha]

Thank you very much for the clarification. Hope you can find a way to allow us to restore accounts from other servers and provided by users in a secure way.

 

[cPanelNick]

The team working on this has started to produce new UIs (note these are mockups and have not reviewed by our docs team, the final implementation will be more refined) in addition to the backend changes needed to make this work. We will provide additional updates in a few days as the project progresses.

 

[Serra]

The team working on this has started to produce new UIs (note these are mockups and have not reviewed by our docs team, the final implementation will be more refined) in addition to the backend changes needed to make this work. We will provide additional updates in a few days as the project progresses.

Wow, I've never really thought about this before. This is a good idea.

 

[ChadM.]

Progress on this project has continued, and we are nearing a point at which we would like to throw some real-world issues at the restricted restoration system to ensure that it works as intended.

If anybody has an example of a potentially exploited backup that we could use as part of our internal testing efforts, please PM me and we can arrange a transfer of the tarball.

 

[popeye]

Hi i never knew all this how can i check a backup as not given full access ?

 

[ThinIce]

Hi i never knew all this how can i check a backup as not given full access ?

I'm unsure whether it would be considered polite to link to the Rack911 disclosure of an example of this issue, but they suggest running the following to check a backup archive for symlinks before restoring it

tar -ztvf archive.tar.gz | grep ‘ -> ‘ |grep -v public_html

I'd also take note of what Kenneth has said above, there may well be other vectors.

The system is not designed to handle untrusted data. There are a myriad of ways a malicious user can alter an account backup package to escalate privileges, or add additional privileges to an account backup package.

Until the new system has been released it might be best to just manually transfer content from unverified / untrusted sources as an unprivelaged user so you can manually verify it...