Cube3 security record

The cube3Protected modifier is used to protect integration functions already enabled for protection. The status of each function's protection mechanism is tracked inside the state variable _functionToProtectionEnabled. This variable contains a mapping between the function selectors and a boolean value identifying whether the protection is enabled or not.When an integration function is disabled for protection, the check on line 55 will still allow the function to execute without any issues, bypassing all the logic to forward the cube3SecurePayload to the respective security module. This is intended.On the other hand, when an integration function's protection is enabled, the router will forward the cube3SecurePayload to the respective module, and only allow the execution of the function's logic if the module returns a valid result. This is also intended.Although both previous scenarios work as expected, it is possible for a malicious user to create a smart contract that will stand between the user's EOA and the integration contract. This contract (e.g MockMaliciousContract) simply implements a maliciousFunction() that performs a delegatecall() to the integration contract. Since a delegatecall() is being made, the storage context passed on to the integration contract is that of the malicious contract, and not of the integration contract's. This effectively means that the state variable _functionToProtectionEnabled will be searched for in the storage slots of the malicious contract where all protections are disabled (`placeholder2`).It should be noted however, that mostly integration functions that make external calls are vulnerable, due precisely to the fact that storage context on the integration contract is not modified. Integration functions that modify the integration's storage are generally safe.

The function _transferSecurityAdministration() attempts to implement the logic for transferring the role of _securityAdmin to another address. This role manages the protection status of the integration contract's functions and is set to the deployer of the contract by default.The transfer of this role does not follow a 2-step process. Being a critical and dangerous process, it should be ensured that no potential errors are made during the transfer. The change to an incorrect address on a single step would render the system useless forever.

The functions setClientSigningAuthority() and batchSetSigningAuthority() are used to set the signing authorities specified by the KMS for the specific integration contracts. These functions maintain a counting variable _signingAuthorityCount and increase it every time a new signing authority is set into the variable integrationToSigningAuthoritySet.Whether it is an update or a new insert of signing authority, the variable _signingAuthorityCount is always updated and can lead to the incorrect management of currently active signing authorities.

Floating pragmas is a feature of Solidity that allows developers to specify a range of compiler versions that can be used to compile the smart contract code. For security purposes specifically, the usage of floating pragmas is discouraged and not recommended. Contracts should be compiled and deployed with a strict pragma, the one which was thoroughly tested the most by developers. Locking the pragma helps ensure that contracts do not accidentally get deployed using too old or too recent compiler versions that might introduce security issues that impact the contract negatively.It should be noted however that, pragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package.The smart contracts of Cube3's core protocol make use of floating pragmas. These are not intended for use as libraries for other developers and, as such, should be locked of their pragma.

The functions transferIntegrationAdmin(), acceptIntegrationAdmin(), updateFunctionProtectionStatus(), and initiateIntegrationRegistration() are capable of modifying the storage of the Router smart contract, yet they do not validate whether the protocol is paused via the function getIsProtocolPaused().

The ProtocolManagement contract defines an installModule() function that saves new module's address into the storage. It was observed that it performs a zero-address check that is then followed by ERC165's supportsInterface() verification. Because the ERC165 standard is used, the zero-address check is redundant as the supportsInterface() function will fail if called on the zero-address. Effectively, the zero-address check is performed twice which incurs a higher gas costs.

The function installModule() does not validate if the module to be installed identified by the input parameter moduleAddress is in fact a Cube3Module. As per the implementation of this function, the module is only required to implement the functions moduleVersion() and moduleId(). This effectively means that when installing a new module via installModule() it is not necessary for the module to inherit from the contract Cube3Module, therefore, it doesn't need to implement the function deprecate(). A vulnerable module that was previously installed on the router will never be able to be deprecated by the Cube3 administrator.

According to the documentation and code commenting, the minimum valid length for a module version is 9 bytes. However, the check on the constructor of the Cube3Module contract only allows modules to be deployed with a version of 10 bytes or more.Additionally, no validation is being made on the module version in regards to the specification of its format.

The function _transferSecurityAdministration() does not validate against the Zero Address, allowing for a potential transfer of administration to an inexistent user, therefore removing all possibilities of regaining administration of the contract.

Inside the function validateSignature(), the first input validation is made between the variables integrationMsgSender and tx.origin, requiring both variables to be the same address. The integrationMsgSender variable is set all the way back in the Cube3Protected contract as the caller of the integration contract. The tx.origin variable always contains the address of the transaction's initiator EOA account.As per the implemented logic, a contract can never call a protected function in the integration contract since the address of the caller contract will never be an EOA address. This hinders many legitimate use cases and affects blockchain and smart contract interoperability.