EOS RAM hijack and its mitigation.

On the 26th of August, Nathan James (a.k.a nsjames from Scatter) wrote;

A malicious user can install code on their account which will allow them to insert rows in the name of another account sending them tokens. This lets them lock up RAM by inserting large amounts of garbage into rows when dapps/users send them tokens.

Who does this attack affect?

It affects all accounts which call a contract action that notifies other parties about the action. Contract notifies 3rd party about the action by calling require_recipient function. In practice, this means that all token transfers which notify the recipient about the incoming payment are susceptible to this vulnerability.

Still, users (not contracts) have to consciously make a token transfer, so this vulnerability mainly affects all dapps that are sending any kind of automatic payouts and can be easily tricked into payment transfer to the malicious user.

What’s the typical end result?

The attacker burns all the RAM space of a dapp and consequently preventing it to use its own RAM, thus crippling the dapp. An example of this would be a dapp payout to the users who do not already have a reserved balance space of a token’s contract. In this scenario, the dapp won’t be able to make a token transfer because it ran out of RAM space.

The attack in the wild;

EOSbet dapp (the dapp with the most volume on Dapp Radar) was hit by an attack as a result of this vulnerability. After a short time of being offline the community of block-producers and developers prepared the mitigation;

A proxy contract.

A proxy contract handles a token transfer in the name of the token sender hence any attack is mitigated through the proxy, leaving the sender unaffected. Proxy also doesn’t hold any excess RAM thus it prevents any malicious user from being able to hijack RAM space.

The limitation;

The main limitation of the mentioned proxy contract is that it can not be used to send a token to an account that doesn’t hold a token balance. It can’t transfer new tokens to users that don’t hold any receiving token yet. That’s the limitation that many dapps can’t live with; they need to be able to provide transfers to fulfil its obligations. As far as we know; some dapps skipped the proxy and instead provide an outside oracle (server) that scans the EOS blockchain for smart contract accounts and actively blacklists them. This type of mitigation relies on the availability of the outside oracle- which could fail at any time, to allow a persistent attacker to take advantage of the dapp.

Iryo’s blockchain squad to the rescue.

The blockchain team at Iryo have managed to build a proxy contract that allows token transfers to the recipients that don’t hold any yet. In short, the proxy contract buys on the spot a sufficient amount of RAM space needed for the transfer and then transfers token. As a dapp developer, all you need to do is register your contract in EOS Transfer Proxy Dapp and hold sufficient EOS balance on the contract doing the transfers. In addition to that, the team simplified the interaction between dapp and proxy contract, so that dapp developers can keep their memo structure intact.

Link to the proxy repository.

Feel free to contact us for any support, or whitelisting to skip the fee.
Smart-contract is already deployed on the Mainnet and Tesnet.

In the future, Iryo hopes to keep delivering open source tools for EOS, enriching the dapp developers experience and further secure its ecosystem.