{"id":579,"date":"2023-10-09T12:58:51","date_gmt":"2023-10-09T10:58:51","guid":{"rendered":"https:\/\/ackeeblockchain.com\/blog\/?p=579"},"modified":"2024-07-04T13:29:11","modified_gmt":"2024-07-04T11:29:11","slug":"staying-safe-with-safe","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/staying-safe-with-safe\/","title":{"rendered":"Staying safe with Safe"},"content":{"rendered":"

Safe multi-sig wallet is one of the core items in the Ethereum ecosystem. It\u2019s been evolving and it\u2019s not what it was in 2017: <\/span>it develops<\/span><\/a> into a flexible and modular system from relatively simple signature verification.<\/span><\/p>\n

Since we audited Safe version 1.4.0, we realized the importance of Safe in the Ethereum ecosystem and decided to research it continuously. We collected several tips and potential risks for Safe users and developers building projects around it. Here is the result of our research with several valuable resources for those who decide to get deeper.<\/span><\/p>\n

Fallback Handler msg.sender<\/b><\/h3>\n

Using msg.sender<\/code> is very common in smart contracts. We use it for access control as a mappings key or encode it with other parameters to connect the data to the specific address. However, some design patterns may work in a less straightforward way. One of them is Safe’s <\/span>FallbackHandler<\/code><\/span> contract.<\/span><\/p>\n

To extend the functionality of the Safe, we have to deploy a new <\/span>separate<\/b> contract called Fallback Handler. Why? Because Safe is a battle-tested singletone contract, changing it may be not the best idea. Instead, we deploy our proxy pointing to the Safe contract and our handler, where we can extend the functionality of our Safe any way we want.<\/span><\/p>\n

How does it work? At first, we add the <\/span>FallbackHandler<\/code>
\n<\/span> contract address into the Safe. Then, we call the Safe address with the function from <\/span>FallbackHandler<\/code><\/span>. Because the function is not implemented inside the Safe contract, the call falls into <\/span>fallback<\/code>
\n<\/span>, where the call is forwarded to the <\/span>FallbackHandler<\/code>
\n<\/span>.<\/span><\/p>\n

During this call trace, <\/span>msg.sender<\/code>
\n<\/span> inside the <\/span>FallbackHandler<\/code>
\n<\/span> function will carry the address of Safe, not the original sender. It\u2019s important to keep it in mind because anyone can call <\/span>FallbackHandler<\/code>
\n<\/span> on behalf of Safe. For example, the simple access control condition that allows only Safe to call the contract will be useless. If we want to use the original sender’s address, we use the function <\/span>msg.sender()<\/code>
\n<\/span> instead, which is implemented inside the <\/span>contract HandlerContext<\/span><\/a>.<\/span><\/p>\n

function _msgSender() internal pure returns (address sender) {\n    assembly {\n        sender := shr(96, calldataload(sub(calldatasize(), 20)))\n    }\n}<\/code><\/pre>\n
As we can see, the function extracts a specific part of the call data, which carries the original sender’s address. The process of storing the address inside the call data can be seen in the logic of the fallback function inside the <\/span>contract<\/span><\/a> FallbackManager<\/code><\/span>.<\/span><\/p>\n
\/\/ The msg.sender address is shifted to the left by 12 bytes to remove the padding\n\/\/ Then the address without padding is stored right after the calldata\nlet senderPtr := allocate(20)\nmstore(senderPtr, shl(96, caller()))\n\/\/ Add 20 bytes for the address appended add the end\nlet success := call(gas(), handler, 0, calldataPtr, add(calldatasize(), 20), 0, 0)\n<\/code><\/pre>\n
Broken guard<\/b><\/h3>\n
Guard is a smart contract that implements specific data validation logic. It usually contains two main functions <\/span>(an upcoming Safe version may introduce\u00a0guard for module transaction<\/a>):<\/p>\n