5

Say I have a "master" contract that can create other "servant" contracts. The master contract routes users into different servant contracts and each servant contract should only be able to be accessed by one user (and as a result has a modifier that throws unless the msg.sender is the master contract).

My worry is that someone could create a servant contract that uses DELEGATECALL to call into a different servant contract than the one they are supposed to access.

So my question is two-fold - would DELEGATECALL allow this type of attack? And if so, is it possible to defend against this type of attack?

Thanks!

Improve this question
4
  • let me understand, you say "I have a "master" contract that can create other "servant" contracts." But the servant contracts can be anything, ie you create them with a call(data) where data is the new servant contract?
    – Roland Kofler
    Commented Jan 22, 2017 at 11:37
  • Yes - sorry for the lack of clarity. The servant contracts can be updated by the user who has control over them, so they can make the code anything they want - for example, they could include a call or delegatecall.
    – Nate Rush
    Commented Jan 22, 2017 at 16:25
  • Wouldn't a DELEGATECALL just pull code out of the contract, not its storage.
    – Xavier Leprêtre B9lab
    Commented Jan 22, 2017 at 16:50
  • Possible to contrive a little example for us to consider? I see lots of potential problems but I imagine you've coded your way around the obvious ones.
    – Rob Hitchens
    Commented Jan 22, 2017 at 17:09

1 Answer 1

Reset to default
1

DELEGATECALL can usually be a vulnerability to the "sending" contract, not the "receiving" contract. DELEGATECALL basically says that I'm a contract and I'm allowing you to do whatever you want to my storage: so it isn't really possible for me to use DELEGATECALL to change your storage.

When contract C does a DELEGATECALL to contract D, C is at the mercy of D. With DELEGATECALL, all of D's code manipulates the storage of C.

In hub-spoke contracts, a hub (master) performing a DELEGATECALL to spoke (servant) contracts is certainly vulnerable to spoke contracts manipulating the state of the hub. The attack surface could be large, and DELEGATECALL wasn't intended as a way to allow arbitrary untrusted code (spokes) to manipulate "shared" state (hub): it may help to explore this more with some specific examples. A contract or "library" usually only has a single, active contract it delegates to at a time.

A spoke contract S that uses DELEGATECALL to another spoke contract T, is at the mercy of T, rather than attacking T (just like the example with C and D).

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.