Proposal has a security hole about eosio.contracts

[StarryJapanNight]

I don't fully understand your example, can you give a clearer explanation? The invalidate action can be called by C to invalidate any proposals that affect B.

[pengten]

Account A adds a proposal in order to update auth, then account A is offline traded to others and the public key is modified, and then proposal is executed causing the public key to be modified again. This will cause serious property damage to the buyer.
like this example
the proposal which named xxtest111111 change the owner key to "EOS7QsF9zA4Yq7ugtVrEFP4UEhBGGnTuhHwaknQJoxp4daih1gUnx"

[pengten]

I think all proposals should expire after ownership changes.

[StarryJapanNight]

How do we know when ownership changes? I still do not understand why in your example the invalidate action doesn't resolve the problem. The code was specifically modified to stop msig actions from restoring account permissions after an account has been sold. But it is the new owner/exchanges responsibility to call the invalidate action.

[pengten]

I understand what you mean, we will try to solve the problem in this way, thank you

[arhag]

As @StarryJapanNight mentioned, the new invalidate action was added (#59) to eosio.msig in v1.3.0 specifically to address this issue. But it is the responsibility of the parties doing the exchange to call that invalidate in the same transaction that transfers ownership.

Keep in mind there are other loopholes (using deferred transactions) that a malicious account seller can use to effectively do the same thing. Unfortunately, there is no clean solution to this other than using an escrow process. See the discussion here.