The malicious observer/node can use the voting function to conduct a DoS attack on ZetaChain

[c4-bot-8]

Lines of code

https://github.com/code-423n4/2023-11-zetachain/blob/b237708ed5e86f12c4bddabddfd42f001e81941a/repos/node/x/crosschain/keeper/keeper_cross_chain_tx_vote_inbound_tx.go#L95

Vulnerability details

Impact

A malicious observer/node can perform a DoS attack on ZetaChain

Proof of Concept

When there is a new message to vote on (for example :VoteOnObservedInboundTx), FindBallot looks for the Ballot and creates a new Ballot if it does not exist.

Since the validity of the message cannot be verified, if the observer sends an invalid message, a Ballot is also created, but the Ballot fails to pass the vote, and CCTX is not created.

Malicious observers can add a large number of invalid ballots to the blockchain network by sending a large number of invalid messages, consuming the server's storage resources.

The VoteOnObservedInboundTx process is as follows:
The same problem exists in other places where voting is required

func (k msgServer) VoteOnObservedInboundTx(....) {
    ....
    ballot, isNew, err := k.zetaObserverKeeper.FindBallot(ctx, index, observationChain, observationType)
	....
	ballot, err = k.zetaObserverKeeper.AddVoteToBallot(ctx, ballot, msg.Creator, observerTypes.VoteType_SuccessObservation)
	....
}

func (k Keeper) FindBallot(....) {
    isNew = false
	ballot, found := k.GetBallot(ctx, index)
	if !found {
		....
		ballot = types.Ballot{
            ....
		}
		isNew = true
@>	    k.AddBallotToList(ctx, ballot)
	}
	return
}

func (k Keeper) AddBallotToList(ctx sdk.Context, ballot types.Ballot) {
	list, found := k.GetBallotList(ctx, ballot.BallotCreationHeight)
	if !found {
		list = types.BallotListForHeight{Height: ballot.BallotCreationHeight, BallotsIndexList: []string{}}
	}
@>	list.BallotsIndexList = append(list.BallotsIndexList, ballot.BallotIdentifier)
	k.SetBallotList(ctx, &list)
}


func (k Keeper) AddVoteToBallot(ctx sdk.Context, ballot types.Ballot, address string, observationType types.VoteType) (types.Ballot, error) {
	ballot, err := ballot.AddVote(address, observationType)
	if err != nil {
		return ballot, err
	}
	ctx.Logger().Info(fmt.Sprintf("Vote Added | Voter :%s, ballot idetifier %s", address, ballot.BallotIdentifier))
	k.SetBallot(ctx, &ballot)
	return ballot, err
}

Tools Used

vscode manual

Recommended Mitigation Steps

Limit the number of votes a observer/node can create.

Assessed type

DoS

[c4-pre-sort]

DadeKuma marked the issue as primary issue

[c4-pre-sort]

DadeKuma marked the issue as insufficient quality report

[0xean]

@DadeKuma - I assume there is some mechanism (slashing perhaps) to prevent this, but am having trouble finding it in the docs, can you refer me?

[0xean]

sorry, nevermind, found it. closing

[c4-judge]

0xean marked the issue as unsatisfactory:
Insufficient quality

[ciphermarco]

Hi, @0xean. I'm not sure what this issue defines as "invalid message", but, since my issue #536 is considered duplicate with this, I'm commenting here. And, I also don't know if the documented slashing mechanism was used to invalidate the issue, but, in my issue, I show how the slashing mechanism cannot punish this misbehaviour.

The problem I present in #536 is that a malicious or faulty observer can freely create useless ballots and not be slashed by this action. As detailed in my submission, the issue is created by the limited voting options for the ballot type that only allows observers to vote for a successful observation. Thus, the malicious chain of events expected is:

1. A faulty or malicious Observer creates a ballot with a false observation.
2. Other Observers cannot vote against this observation due to limited voting options.
3. The ballot remains with the status BallotStatus_BallotInProgress.
4. As shown in my issue, the slashing mechanism does not account for ballots with the status BallotStatus_BallotInProgress, thus never punishing the spam ballot creator.

I also see no evidence as to why this would be pre-sorted as QA (same for my other issue with a similar impact, but with different root cause #539). This is critical node software and any resource exhaustion vectors are equally critical and expected to be attacked. Though, in the C4 context and rules, I think the Medium severity may be adequate.

Thank you for your consideration and time spent with this.

[c4-judge]

0xean marked the issue as satisfactory

[c4-judge]

0xean marked the issue as duplicate of #536

[c4-judge]

0xean marked the issue as partial-25