Lines of code
<https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/framework/plugin/repo/PluginRepoFactory.sol#L122&gt;

Vulnerability details

Impact

Detailed description of the impact of this finding.

Any developer can create their plugin repo and others can use them to download various plugins. The problem is that the plugin repo’s are upgradeable, and the owner access (and permissions to upgrade) are given to the creator of the plugin repo. This allows a malicious actor to change the plugin repo’s code, without changing the repo’s address. This can be devastating, as unsuspecting users, while installing a plugin from this repo could suffer from:

Incorrect version supplied <https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/framework/plugin/setup/PluginSetupProcessor.sol#L298-L300&gt;

Malicious plugin setup and prepared data <https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/framework/plugin/setup/PluginSetupProcessor.sol#L303-L306&gt;

And of course, the attacker can create a malicious plugin which can bypass protections because the dao owners gave it permissions. It could also perform reentrancy and lots of other attacks.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

1. The malicious user creates a plugin repo using this <https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/framework/plugin/repo/PluginRepoFactory.sol#L31-L36&gt; or this <https://github.com/code-423n4/2023-03-aragon/blob/4db573870aa4e1f40a3381cdd4ec006222e471fe/packages/contracts/src/framework/plugin/repo/PluginRepoFactory.sol#L45-L59&gt; function. This current plugin repo is non malicious, and any plugins are also non malicious, so unsuspecting users trust this repo.

2. The malicious user then upgrades the proxy (the repo) to a different implementation and changes the code, such as the plugin setup and the prepared data, versions.

3. The unsuspecting users, trusting the repo, decide to add a plugin “abc” to their dao. The first time the user has looked at the plugin, it looked safe. But now, the plugin “abc” is malicious, because owner changed the repo’s code and now it’s no longer the same plugin. So, they install a malicious plugin in their dao.

4. Now the attacker can perform reentrancy attacks, steal funds, interact with other plugins and possibly do more damage, all depends on the given permissions.

There could be an argument that the unsuspecting user can double check and see that the proxy’s implementation has changed. That’s true. Knowing that, the attacker could wait until the user submits the preparation for an install. Now, the malicious actor could frontrun the unsuspecting user, upgrade the proxy first, and the innocent user will still be damaged.

Tools Used

manual review

Recommended Mitigation Steps

I’d say the best way to fix this is to not give any access to the plugin repo’s proxy to the creator. Perform any upgrades and implementation changes or other such things through the PluginRepoFactory.sol contract or PluginRepoRegistry.sol contract.
If the creator of the repo wants to upgrade to a different implementation, force to do it through contracts listed above (or any other contracts).

---

The text was updated successfully, but these errors were encountered:

All reactions