7

Lets say I interact with an action from a smart contract, if I'm not careful and didn't read or couldn't understand the source code for the smart contract, is it not possible that the contract could purposefully fill a database entry with junk data and charge me the RAM for it?

If that happens, is there a mechanism to delete the table entry for the end-user? I don't think that that should be possible, so if this happened you would be at the mercy of the smart-contract owner, who may not delete the entry if they are being malicious.

Is this understanding correct?

Improve this question
11
  • 1
    no mechanism, you're right, take care don't buy too much ram in your account, however, malicious contract can not take your ram away
    – Jimmy Guo
    Commented Aug 10, 2018 at 9:00
  • 1
    Ok, so lets say I have created a multi-index table. You have to pay for RAM storage. You create an entry by doing an action from my contract. However, I have nothing in my contract to delete orders. Are you saying that the solution would be to create your own contract, set up an equivalent multi-index, and delete it from there? I thought that the database entries belonged to the account that created them (in this case the original contract).
    – Phillip Hamnett - EOS42
    Commented Aug 10, 2018 at 10:29
  • 1
    yeah, that's what i imagined. haven't tried to initialise a table with a different code, so i need to try that, but this may be doable at the very least with the right permissions, which can be a prerequisite to interact with the contract. i may give it a try this weekend
    – confused00
    Commented Aug 10, 2018 at 10:55
  • 1
    It wouldn't make sense to allow users to delete data from other smart contracts. This would break a huge amount of functionality and they'd be quite useless. Seems like a malicious contract can gobble your RAM if you aren't careful :-/
    – Alex
    Commented Aug 10, 2018 at 22:36
  • 1
    yeah Todd Fleming confirmed that OP is correct and there's no mechanism against this
    – confused00
    Commented Aug 17, 2018 at 1:09

2 Answers 2

Reset to default
6

Yes, I believe that your understanding is correct, as confirmed in a discussion on Telegram Developers Channel pasted below--Todd Fleming is a contributor to EOSIO codebase:

16th of August

User: is there any way for an user to remove RAM allocated that they own ? let’s say that I own a malicious contract that once an action hit, check ram of user, and fullfill it with [useless] data, and I dont provide a remove method

Todd Fleming: The contract is the only thing that can free the ram

User: and you cannot do anything if contract consume so much ram of user account ?

Todd Fleming: Right. Be careful what contracts you send actions to.

Update 27th August: This mechanism enables what is now considered an exploit.

A contract can intercept a transfer action when it's being sent tokens and use up the unused RAM of the sender. In other words, if you send tokens to an account that has a contract, it is possible that the account will use your unused RAM, if any. Details here, and a temporary solution where you use an intermediate to interact with other contracts has been proposed here. This is particularly dangerous for exchanges that manage withdrawals from an account with unused RAM.

Update 9th September: The exploit below has been fixed in EOSIO. See @PhillipHamnett-EOS42's answer.

Improve this answer
2
  • if someone can provide a better answer than an informal Telegram discussion please do share, but at the moment this question has gone unanswered for 10 days so maybe this is marginally better than nothing
    – confused00
    Commented Aug 19, 2018 at 22:13
  • 1
    Another potential solution is to check in the smart contract, whether the account you will transfer to has code or not. As you mentioned in another answer
    – Phillip Hamnett - EOS42
    Commented Aug 27, 2018 at 14:59
2

A stop-gap fix has been issued in v1.2.3 of EOS

Deprecation of the ability of a notified contract to bill RAM to authorizers of the original action EOSIO blockchains enable a useful feature which allows one contract executing an action to notify another contract of the action because it may pertain to it. EOSIO blockchains have up to now had an additional capability which allows the notified contract to bill any of the authorizers of the original action for the RAM costs of storing data in the blockchain state. This powerful, but ultimately undesirable, capability has allowed smart contracts to adopt a common pattern of executing sophisticated operations which consume RAM in response to receiving tokens from a transfer action; however, the capability has also been abused my malicious contracts to waste the available RAM of users.

For this reason, this additional capability of allowing a notified contract to bill additional RAM to the authorizers of the original action is now deprecated. Legitimate smart contracts that currently utilize this capability can upgrade to instead use more appropriate patterns (such as the one discussed in the description of #5451). This release introduces a mitigation (#5451) to subjectively restrict this capability if all active block producers of the blockchain deploy the mitigation. An objective solution will be introduced at a later date.

For more information about these changes, please see: https://medium.com/@bytemaster/preventing-unexpected-ram-consumption-8029a9342659

This means that you can no longer emplace into a table or push_back into a vector within a table through code accessed by a transfer action (or any other action that isn't unique to the contract), unless the smart contract itself pays for it.

The only way to make the user pay for RAM now, is to have the user submit first an action that is contract-specific, using cleos push action....

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.