Delegatecall as catch all mechanism

Hey Guys,
I lately read the post about the reentrancy attack and that it can’t happen in Diem. I was wondering if there is any mechanism why an parity attack couldn’t take place or if it has been tested and for example the verifiers would not allow to kompile a module or something having such a vulnerability in the SC.
Does anyone of you know something about this?

In order to exploit a re-entrancy vulnerability in procedure P, the code of P must invoke a callee procedure P' that (directly or eventually) calls back into P.

Move does not have dynamic dispatch, so the developer of P always knows exactly what P' will be in advance. This makes it impossible for an attacker to surprise P's developer with an unexpected P'.

See this discussion as well:

Thanks for the quick answer.
I now understand the re-entrancy part.
Do you know something about the parity attack and if something similar could happen in Diem?

I think there are a few different Parity hacks, but I’m guessing the question refers to this one.

This attack also would not be possible in Move for similar reasons: the attack involves delegatecall, a dynamic dispatch primitive. Move does not have dynamic dispatch, so the only way to call a sensitive private function like initWallet is to do so directly from another procedure in the same module.

Oh sorry I forgot to attach the parity attack I was talking about. It is exactly the one you referred to.
That makes sense. Thanks.
So if I would theoretically write a module with a multisig wallet and tried to publish it, everything would work. But if I would try to execute a similar “transaction” as in the link you referred to, a validator would prevent the execution or would there be an other error?

I’m not sure I understand the question, but I think the answer is that (1) the module could not have used a fallback function in the first place because Move does not have fallback functions, and (2) initWallet would be private and thus code outside the module that attempts to call it will be rejected by the bytecode verifier.

This post on implementing a multisig module may also be helpful

Hey,
thanks for your answers.
So Diem uses multisig transactions and not multisig modules. Is that right?
Is there a completely programmed multisig module or just the code in the other post?

So Diem uses multisig transactions and not multisig modules. Is that right?

Correct

Is there a completely programmed multisig module or just the code in the other post?

There is no implementation of a multisig module in Diem, but there might be one in dfinance or starcoin.

Hey,
i got one question. would it be possible to call a public function of the module that "accidentally calls the initWallet function?

I am not sure I understand the question. But if it is: “if a custom module has a sensitive private function like initWallet, can it accidentally exposes a public function that (directly or transitively) calls initWallet?”, the answer to that question is yes. Ultimately, it’s up to the module programmer to decide which functions are sensitive and ensure they are not callable. The language has nice properties that make this easier (e.g., by precluding re-entrancy), but it cannot know what is sensitive on its own.