light client may be attack by 1/3+ validators

[BananaLF]

Summary of Bug

I research the code of ibc 02-client. When ibc run ‘MsgUpdateClient’ to update client，the CheckHeaderAndUpdateState of 07-tendermint will call light client verify which only verify sign validators is more than 1/3+ trustvalidators( code)

So I think if Chain B validatorset has been change with the number of 1/3+ validators remove or offline, then the 1/3+ validators send counterfeit client of Chain B to Chain A, thus the Chain A will be cheated。

It also like this comment cosmos/ibc#421 (comment)

Expected Behaviour

This problem is light client problem.

As far as I am concerned, the light client of Chain B will slashing when discovery thus attack。And I think the attack only be discovery by the node of Chain A , but if the attack is happened in Chain B ,it will not be slashing attacker or i'm not search the way of slashing attacker.

Could you pelease help me to solve my question:

1. the 1/3+ validators whether or not attack to update client？
2. could ibc have punitive measures to provent this attack？
3. if ibc have punitive measures ，how can i to use it？

Version

Steps to Reproduce

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

Thanks for asking these questions, @BananaLF. And great to read that you've been diving into the ibc-go code!

If 1/3 or more of the voting power belongs to faulty or malicious validators, then at a given height validators could decide on different blocks. If that happens a relayer can submit a message with both conflicting headers (what we call a proof of misbehaviour) and the light client would in that case freeze and not accept new headers any more.

If the chain is taken over by enough voting power of malicious validators that they generate only malicious headers, then the light client will be cheated and accept the malicious headers, but if this happens, then the fact that the chain has become completely malicious is a bigger problem that the light client being cheated.

I hope this helps and if you feel your questions are answered, please feel free to close the issue. We also encourage people to ask general IBC questions on Discord instead of opening an issue in the repo. That's our preferred way to answer questions; I hope that's ok with you!

[AdityaSripal]

Hello @BananaLF , this is indeed correct. IBC tendermint client by default runs on the BFT assumption that >1/3 of validator power is honest.

However, this is parameterized. You can choose to adopt a more stringent security model by changing the TrustLevel parameter.

This would require more frequent updates to the client in order to keep it live. Thus there exists a tradeoff between liveness and security when choosing a value for this parameter.

@crodriguezvega is correct. Please direct any followups to the Discord! Thanks!

[BananaLF]

@AdityaSripal @crodriguezvega Thanks for your reply. I will answer questions on Discord new-devs-support

[BananaLF]

If Chain B validatorset has been change with the number of 1/3+ validators remove or offline, then Chain B consensus will be work fine. But 1/3+ validator which is removed or offline will send counterfeit client of Chain B to Chain A. In this case, ibc recv msg is wrong msg, Chain B consensus is well, so ibc need send slashing msg to Chain A when recv wrong for punish the perpetrator instead of only submit MsgSubmitMisbehaviour.

As chain developer, when we support ibc,we need do something:

1. Make app for check this case for each header and submit MsgSubmitMisbehaviour ,send slashing msg to dst chain
2. Choose carefully 'TrustLevel' 'TrustingPeriod'

Can someone help me with reference values for the above parameters？