Gnosis Safe: a tx nuance

Today we'll continue our breakdown of vulnerabilities and nuances in integrations with other web3 protocols.

And let's talk about the problems you may run into with Gnosis safe!

Let's dive in!

Gnosis Safe is a smart contract multi-sig wallet running on Ethereum that requires a minimum number of people to approve a transaction before it can occur.

To submit a transaction with a Gnosis Safe, you would first need to create the transaction on the Ethereum network.

Then it must be signed by the required number of keys (users) associated with the safe. Once the transaction has been signed by the required number of keys, it can be submitted to the Ethereum network to be executed.

You can apply as many users to validate a tx as you want.

However, there is a nuance to think about when sending transactions to your Gnosis Safe. Take a look on the Gnosis SafeTx params on the screen.

As well as basic arguments such as to, data and value, it has some gas-related params: safeTxGas, baseGas, gasPrice, etc.

You should not ignore them when forming and validating a tx in your own protocol!

Here is an example of a vulnerability in the Brahma protocol.

As you can see in a contract code there was a tx validation that considered only 6 out of 12 params. So the SubAccount operator can steal funds from the SubAccount Gnosis Safe via the Gnosis Safe gas refund mechanism.

Another impact is when executing the transaction arbitrary amount of gas price and gas amount can be passed in for certain transaction. It may perform a low level call and pass the gas parameter around and if there are insufficient gas passed in the low level call silently revert.

I know it is too much to read, but it should be known when working with Gnosis Safe.

Read the full report here:

Link: https://code4rena.com/reports/2023-10-brahma#m-02-subaccount-operator-can-steal-funds-via-the-gas-refund-mechanism