Swift Pistachio Rabbit Vulnerability Global Voting Power Lookup Ignores KeyTag

Jul 22, 2025 by JurnalWarga.com 79 views

Swift Pistachio Rabbit Global Voting Power Lookup Vulnerability

Hey guys, let's dive into a critical security vulnerability known as "Swift Pistachio Rabbit" that affects global voting power lookups. This issue was discovered during the Sherlock-Audit for the 2025-06-symbiotic-relay-judging event. It's a medium-severity bug that can have significant implications for the integrity of signature verification. In this article, we're going to break down the vulnerability, explore its root cause, and understand how attackers can exploit it. So, buckle up, and let's get started!

Summary of the Vulnerability

The core issue lies within the SigVerifierBlsBn254Simple.verifyQuorumSig() function. This function is supposed to verify quorum signatures, but it has a flaw: it uses a global lookup for total voting power that doesn't consider the keyTag parameter. Meanwhile, other crucial validator data, such as the validator set hash and aggregated public key, are correctly scoped per keyTag. This inconsistency creates a loophole that malicious actors can exploit.

Think of it like this: imagine you have different voting groups, each identified by a keyTag. Each group has its own set of validators and a certain amount of voting power. The vulnerability allows an attacker to mix and match data from different groups, potentially bypassing the required quorum threshold. It's like using votes from one election to influence the outcome of another – not good!

Root Cause Analysis

To truly understand this vulnerability, we need to dig into the root cause. The problem boils down to inconsistent key generation during the signature verification process. Let's look at the code snippets to illustrate this.

The function uses two different ways to look up data:

For total voting power, it uses a 2-argument version of getKey:
```
uint256(
    ISettlement(settlement).getExtraDataAt(epoch, VERIFICATION_TYPE.getKey(TOTAL_VOTING_POWER_HASH))
) - nonSignersVotingPower
```
This method doesn't include the keyTag, meaning it fetches the global total voting power.

For other validator data, it correctly uses a 3-argument version that does include keyTag:

ISettlement(settlement).getExtraDataAt(
    epoch, VERIFICATION_TYPE.getKey(keyTag, VALIDATOR_SET_HASH_KECCAK256_HASH)
)

ISettlement(settlement).getExtraDataAt(
    epoch, VERIFICATION_TYPE.getKey(keyTag, AGGREGATED_PUBLIC_KEY_G1_HASH)
)

This means the validator set hash and aggregated public key are scoped correctly to the specific keyTag.

The ExtraDataStorageHelper library is the culprit here. It provides two key generation patterns: one global and one keyTag-scoped. The issue is that these patterns are being used inconsistently within the same verification function.

Understanding the Implications of Inconsistent Key Generation

The inconsistent key generation is the crux of the vulnerability. It's like having a security system where some doors require a specific keycard, while others can be opened with a master key that overrides the individual permissions. This creates a weakness that can be exploited.

When the total voting power lookup ignores the keyTag, it essentially uses a global value regardless of the specific validator set being verified. This can lead to a situation where a signature that shouldn't be valid is accepted because it meets a quorum threshold calculated using the wrong voting power.

Imagine a scenario with two keyTags: keyTagA representing a smaller group with lower voting power, and keyTagB representing a larger group with higher voting power. An attacker could construct a proof that appears valid because it uses the higher voting power from keyTagB while actually belonging to the keyTagA group, which requires fewer signatures to reach a quorum.

This inconsistency breaks the fundamental security principle that all validator data should be consistently scoped by key type. It's like having a database where some records are properly indexed, while others are scattered and can be accessed using incorrect criteria. This can lead to data corruption and unauthorized access.

Pre-Conditions for Exploitation

To successfully exploit this vulnerability, certain conditions need to be in place. Let's break these down into internal and external pre-conditions.

Internal Pre-conditions

There are no specific internal pre-conditions within the smart contract code itself. The vulnerability stems directly from the inconsistent key generation logic.

External Pre-conditions

Multi-keyTag Deployment: The system must be deployed with multiple keyTag types. This is crucial because the vulnerability relies on the existence of different voting power distributions across different key types.
Attacker Capability: The attacker needs the ability to construct validator set proofs with mixed keyTag data. This means they need to be able to manipulate the data used in the signature verification process.
Varying Voting Power: The different keyTag types must have varying total voting powers. This is the key to bypassing quorum checks. If all key types had the same voting power, the vulnerability would be less impactful.

These pre-conditions are like the ingredients in a recipe. Without them, the attack can't be cooked up. The multi-keyTag deployment provides the environment, the attacker's ability to construct proofs provides the tools, and the varying voting power provides the fuel for the attack.

Attack Path: How an Attacker Can Exploit the Vulnerability

Now, let's walk through how an attacker can actually exploit this vulnerability. This will help us understand the real-world implications of the issue.

Identify a Target: The attacker starts by identifying a multi-keyTag deployment where different key types have different total voting powers. This is their hunting ground.
Craft a Malicious Proof: The attacker then constructs a malicious proof using a clever mix of data:
- Validator Set Hash from keyTagA: They use the validator set hash from a keyTag with lower voting power requirements (let's call it keyTagA).
- Global Total Voting Power: Here's the trick – they use the global total voting power, which might be from keyTagB with a higher total power.
- Aggregated Public Key from keyTagA: They keep the aggregated public key consistent with keyTagA.
Verification Bypass: The verification function, due to the vulnerability, incorrectly validates this mixed proof. Here's why:
- The validator set and public key are validated against keyTagA's data, which is correct.
- However, the quorum threshold check uses the global voting power (potentially from keyTagB), which is higher than keyTagA's actual power.
Insufficient Signatures Accepted: As a result, signatures that wouldn't meet keyTagA's actual quorum requirements are accepted as valid. The attacker has successfully bypassed the security check.

Think of this attack path as a carefully planned heist. The attacker identifies a weakness in the security system (the inconsistent key generation), gathers the necessary tools (the ability to construct proofs), and executes the plan by mixing data from different sources to bypass the security checks.

Impact: The Potential Damage

This vulnerability has serious implications for the security and integrity of the system. By exploiting the global voting power lookup, attackers can:

Bypass Quorum Threshold Checks: This is the most direct impact. Attackers can submit signatures with insufficient voting power, effectively undermining the consensus mechanism.
Compromise Signature Verification: The entire signature verification system becomes unreliable. If signatures can be forged or manipulated, the system's trust model is broken.
Unauthorized Validator Set Commits: Attackers might be able to commit unauthorized validator set headers with inadequate consensus. This could lead to malicious actors gaining control of the system.

These impacts are like dominoes falling. The initial vulnerability can trigger a cascade of problems, ultimately compromising the entire system's security. It's crucial to address this issue to prevent potentially catastrophic consequences.

Code Snippets: Pinpointing the Vulnerable Code

To understand the vulnerability in detail, let's look at the specific code snippets that are affected. The critical section is in the SigVerifierBlsBn254Simple.sol contract, specifically lines 106-108:

https://github.com/sherlock-audit/2025-06-symbiotic-relay/blob/main/middleware-sdk/src/contracts/modules/settlement/sig-verifiers/SigVerifierBlsBn254Simple.sol#L106-L108

These lines are where the global voting power lookup occurs, ignoring the keyTag parameter. This is the heart of the vulnerability.

By understanding the specific code affected, developers can focus their efforts on patching this critical area and preventing potential exploits.

How to Fix the Global Voting Power Lookup Vulnerability

To fix this issue, we need to ensure that the total voting power lookup is also scoped by keyTag, just like other validator data. Here's a step-by-step approach to address the vulnerability effectively:

Modify getExtraDataAt() Usage:
- Update the call to ISettlement(settlement).getExtraDataAt() that retrieves the total voting power to include the keyTag parameter. This ensures that the voting power is fetched for the correct key type.
- The corrected code should look something like this:
```
uint256(
    ISettlement(settlement).getExtraDataAt(
        epoch,
        VERIFICATION_TYPE.getKey(keyTag, TOTAL_VOTING_POWER_HASH)
    )
) - nonSignersVotingPower
```
Consistent Key Generation:
- Ensure that all key lookups within the verifyQuorumSig() function use the 3-argument getKey overload, which includes the keyTag.
- This will prevent any future inconsistencies and maintain the integrity of the signature verification process.
Thorough Testing:
- After implementing the fix, conduct thorough testing to verify that the vulnerability is resolved.
- Write unit tests that specifically target the vulnerable code path and simulate the attack scenario.
- Consider using fuzzing and formal verification techniques to identify any potential edge cases or regressions.
Auditing and Review:
- Engage a professional security auditor to review the fix and the surrounding code.
- An independent audit can provide an extra layer of assurance and catch any subtle issues that might have been missed.

By following these steps, you can effectively mitigate the "Swift Pistachio Rabbit" vulnerability and strengthen the security of your system.

Conclusion

The "Swift Pistachio Rabbit" vulnerability highlights the importance of consistent key management in smart contract development. By allowing a global lookup for total voting power while scoping other validator data by keyTag, the SigVerifierBlsBn254Simple.verifyQuorumSig() function created a potential bypass for quorum threshold checks.

This vulnerability could have significant consequences, including the acceptance of signatures with insufficient voting power and the compromise of the signature verification system's integrity. By understanding the root cause, the attack path, and the impact, developers can take the necessary steps to fix the issue and prevent future vulnerabilities.

Remember, security is an ongoing process. Regular audits, thorough testing, and a deep understanding of potential vulnerabilities are essential for building secure and reliable systems. Stay vigilant, and keep your code secure!