Noble Dollar v2 - IBC Support Update - Noble Assets

The module uses a vulnerable dependency:

• pkg:golang/golang.org/x/net@v0.34.0

• pkg:golang/golang.org/x/crypto@v0.32.0

• pkg:golang/github.com/ethereum/go-ethereum@1.14.13

Flagged by the nancy tool:

• CVE-2025-22870: Misinterpretation of Input

• CVE-2025-22869: Allocation of resources without limits or throttling.

• CVE-2023-42319: Geth (aka go-ethereum) through 1.13.4, when --http --graphql is used, allows remote attackers to cause a denial of service (memory consumption and daemon hang) via a crafted GraphQL query.

Using vulnerable dependencies can compromise the security and stability of the protocol, exposing it to potential attacks, performance degradation, and operational disruptions.

It is recommended to keep dependencies patched in order to reduce the risk of the system being attacked using known vulnerabilities. Run the security tools regularly and fix the warning.

SOLVED: The Noble team fixed this issue by updating the mentioned dependencies.

In the Stats query handler of the queryServerV2 struct, there is an issue where errors from the math.NewIntFromString function are silently ignored. This function returns two values: the converted Int and a boolean indicating success or failure of the conversion. However, the current implementation discards the success indicator with the blank identifier (_).

func (k queryServerV2) Stats(ctx context.Context, req *v2.QueryStats) (*v2.QueryStatsResponse, error) {
    // ... other code omitted ...
    
    totalExternalYield := make(map[string]v2.QueryStatsResponse_ExternalYield)
    for key, rawAmount := range stats.TotalExternalYield {
        provider, identifier := v2.ParseYieldRecipientKey(key)

        chainId := "UNKNOWN"
        switch provider {
        case v2.Provider_IBC:
            chainId = GetIBCChainId(ctx, k.channel, identifier)
        }

        amount, _ := math.NewIntFromString(rawAmount)  // Error indicator is ignored

        totalExternalYield[key] = v2.QueryStatsResponse_ExternalYield{
            ChainId: chainId,
            Amount:  amount,
        }
    }
    
    // ... return response ...
}

When math.NewIntFromString fails to parse a string (for example, if it contains non-numeric characters or represents a value outside the supported range), it returns a zero value (Int{0}) and false for the second return value. By ignoring this second value with the blank identifier _, the code silently accepts invalid inputs.

This also applies to IncrementTotalExternalYield function in state.go.

func (k *Keeper) IncrementTotalExternalYield(ctx context.Context, provider v2.Provider, identifier string, amount math.Int) error {
	stats, err := k.Stats.Get(ctx)
	if err != nil {
		return err
	}
	if stats.TotalExternalYield == nil {
		stats.TotalExternalYield = make(map[string]string)
	}

	key := fmt.Sprintf("%s/%s", provider, identifier)

	totalExternalYield := math.ZeroInt()
	rawTotalExternalYield, exists := stats.TotalExternalYield[key]
	if exists {
		totalExternalYield, _ = math.NewIntFromString(rawTotalExternalYield)
	}

// ...

Always check the boolean return value from math.NewIntFromString and handle error cases appropriately.

amount, ok := math.NewIntFromString(rawAmount)
if !ok {
    // Log the error but continue with zero amount
    k.logger.Error("failed to parse amount in Stats query", 
                   "key", key, 
                   "raw_amount", rawAmount)
    return err
}

ACKNOWLEDGED: The Noble team acknowledged this recommendation.

The ICS4Wrapper.SendPacket function in the Noble Dollar module contains two informational issues related to packet validation that could potentially lead to unexpected behavior:

1. Insufficient Error Handling during Unmarshaling: The function attempts to unmarshal the incoming packet data into a FungibleTokenPacketData structure. However, if unmarshaling fails, instead of returning an error, it silently forwards the packet to the underlying ICS4Wrapper without additional validation:

   
   

func (w ICS4Wrapper) SendPacket(ctx sdk.Context, chanCap *capabilitytypes.Capability, sourcePort string, sourceChannel string, timeoutHeight clienttypes.Height, timeoutTimestamp uint64, data []byte) (sequence uint64, err error) {
    var packetData transfertypes.FungibleTokenPacketData
    if err := transfertypes.ModuleCdc.UnmarshalJSON(data, &packetData); err != nil {
        return w.ics4Wrapper.SendPacket(ctx, chanCap, sourcePort, sourceChannel, timeoutHeight, timeoutTimestamp, data)
    }

    denom := w.dollarKeeper.GetDenom()
    if packetData.Denom == denom {
        enabled := w.dollarKeeper.HasYieldRecipient(ctx, v2.Provider_IBC, sourceChannel)
        if !enabled {
            return 0, fmt.Errorf("ibc transfers of %s are currently disabled on %s", denom, sourceChannel)
        }
    }

    return w.ics4Wrapper.SendPacket(ctx, chanCap, sourcePort, sourceChannel, timeoutHeight, timeoutTimestamp, data)
}

This behavior means that non-ICS20 packets or malformed packets will automatically pass through without proper inspection. While this may be intentional for supporting other packet types, it bypasses any custom validation logic defined in this wrapper.

2. No Validation for IBC-Traced Denominations: The current implementation only checks if packetData.Denom exactly matches the local native token denom. However, this doesn't account for IBC-traced denominations that follow the ICS-20 specification pattern (i.e., denominations in the format hash(port/channel)/denom).

For example, if the native denom is usdn, the function would validate transfers of usdn but would not validate transfers of IBC-traced forms like transfer/channel-1/usdn, which could still represent the same underlying asset returning through a different channel.

In the ICS-20 specification, a proper validation should consider the entire denomination trace to determine the original denomination and ensure all rules are properly enforced regardless of whether the token has traveled through other IBC channels.

It is recommended the following:

1. Improve Error Handling for Unmarshaling:

   • Consider logging unmarshaling errors to aid in debugging

   • Determine if non-ICS20 packets should be allowed, and if not, explicitly return errors for unsupported packet types.

2. Add Support for IBC-Traced Denominations:

   • Implement proper parsing of IBC denomination traces to validate transfers of the native token that might have been routed through other chains.

These improvements would ensure that the module properly handles all packet types and enforces transfer restrictions correctly for all representations of the native token, whether in its original form or as an IBC-traced denomination.

ACKNOWLEDGED: The Noble team acknowledged this recommendation.