xanoutas/solidity-security-findings huggingface dataset:
Upgraded Q -> 2 from #553 [1730390920681]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #553 as 2 risk. The relevant finding follows:

 ## [QA-04] Wrong address passed as `CreatedCrossChainTx.from` in `cross_chain_erc20_settlement`

**Issue Description:**

in `handler_erc20::cross_chain_erc20_settlement` when `CreatedCrossChainTx` is created, the code wrongly assign `get_contract_address` instead of `get_caller_address` as from address:

[handler_erc20.cairo](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L188)

```rust
let tx: CreatedCrossChainTx = CreatedCrossChainTx{
    tx_id: tx_id,
    from_chain: from_chain,
    to_chain: to_chain,
    from: get_contract_address(),//this one should be get_caller_address instead
    to: to,
    from_token: self.token_address.read(),
    to_token: to_token,
    amount: amount,
    tx_status: CrossChainTxStatus::PENDING
};
```

Although this struct to not be used in any important functions it will still show wrong data and can confuse users of Chakra.

**Recommendation:**

Replace `get_contract_address` with `get_caller_address` in `handler_erc20::cross_chain_erc20_settlement`:

```diff
fn cross_chain_erc20_settlement(ref self: ContractState, to_chain: felt252, to_handler: u256, to_token: u256, to: u256, amount: u256) -> felt252{
    assert(self.support_handler.read((to_chain, to_handler)), 'not support handler');
    let settlement = IChakraSettlementDispatcher {contract_address: self.settlement_address.read()};
    let from_chain = settlement.chain_name();
    let token = IERC20Dispatcher{contract_address: self.token_address.read()};
    let token_burnable = IERC20MintDispatcher{contract_address: self.token_address.read()};
    if self.mode.read() == SettlementMode::MintBurn{
        token.transfer_from(get_caller_address(), get_contract_address(), amount);
    }else if self.mode.read() == SettlementMode::LockMint{
        token.transfer_from(get_caller_address(), get_contract_address(), amount);
    }else if self.mode.read() == SettlementMode::BurnUnlock{
        token_burnable.burn_from(get_caller_address(), amount);
    }else if self.mode.read() == SettlementMode::LockUnlock{
        token.transfer_from(get_caller_address(), get_contract_address(), amount);
    }
    
    let tx_id = LegacyHash::hash(get_tx_info().unbox().transaction_hash, self.msg_count.read());
    let tx: CreatedCrossChainTx = CreatedCrossChainTx{
            tx_id: tx_id,
            from_chain: from_chain,
            to_chain: to_chain,
-           from: get_contract_address(),
+           from: get_caller_address(),
            to: to,
            from_token: self.token_address.read(),
            to_token: to_token,
            amount: amount,
            tx_status: CrossChainTxStatus::PENDING
        };
```
Upgraded Q -> 2 from #553 [1730390838001]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #553 as 2 risk. The relevant finding follows:

 ## [QA-01] `BaseSettlement` should update `required_validators` in `SettlementSignatureVerifier`

**Issue Description:**

BaseSettlement adds validators to `signature_verifier`(`SettlementSignatureVerifier`) through functions inside BaseSettlement. When a required_validators is updated inside BaseSettlement it must update the required_validators inside `signature_verifier`(`SettlementSignatureVerifier`) also since they are the used ones.

[BaseSettlement.sol](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/settlement/contracts/BaseSettlement.sol#L121-L128)

```solidity
BaseSettlement.sol

function set_required_validators_num(
    uint256 _required_validators
) external onlyRole(MANAGER_ROLE) {
    uint256 old = required_validators;
    required_validators = _required_validators;
    emit RequiredValidatorsChanged(msg.sender, old, required_validators);
}

```

**Recommendation:**

```diff
function set_required_validators_num(
    uint256 _required_validators
) external onlyRole(MANAGER_ROLE) {
    uint256 old = required_validators;
    required_validators = _required_validators;
+   signature_verifier.set_required_validators_num(_required_validators);
    emit RequiredValidatorsChanged(msg.sender, old, required_validators);
}

```
Upgraded Q -> 2 from #555 [1730390255170]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #555 as 2 risk. The relevant finding follows:

 ## [L-10] incorrect value used in `CreatedCrossChainTx`
FILE:
https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/handler_erc20.cairo#L188

According to `CreatedCrossChainTx`'s defination, [from](https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/handler_erc20.cairo#L98) shoulde be the tx caller, which is `get_caller_address` instead of `get_contract_address`
Upgraded Q -> 2 from #556 [1730390113224]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #556 as 2 risk. The relevant finding follows:

 10. The Cairo version lacks crucial input validation. It should verify that the amount is greater than zero, and that the recipient address, handler address, and token address are all valid (non-zero). These checks are essential for preventing invalid transactions and potential security vulnerabilities.
https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/cairo/handler/src/handler_erc20.cairo#L167-L169
Upgraded Q -> 2 from #556 [1730390082225]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #556 as 2 risk. The relevant finding follows:

 3. The ReceivedCrossChainTx struct is incorrectly updating the to_handler field with address(this) instead of the actual to_handler parameter.https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/settlement/contracts/ChakraSettlement.sol#L211
Upgraded Q -> 2 from #556 [1730390050282]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #556 as 2 risk. The relevant finding follows:

 2. Inconsistent Validator Management: The `add_validator` and `remove_validator` functions in BaseSettlement interact with the signature_verifier, but `set_required_validators_num` does not update the verifier, creating an inconsistency in how validator-related state is managed across contracts and potentially causing partial updates to config.
https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/settlement/contracts/BaseSettlement.sol#L88-L126
Upgraded Q -> 2 from #572 [1730388628234]
Audit: 2024-08-chakra-findings
Severity: MEDIUM

Judge has assessed an item in Issue #572 as 2 risk. The relevant finding follows:

 ## Title (2/6)
Missed checks in Cairo functions that exists on Solidity functions with the same logic.

## Description
The next functions in cairo files miss the existing checks in same logic from Solidity files:

1. Missed checks for zero values in Cairo.
File:cairo/handler/src/handler_erc20.cairo
[![GitHub code snippet](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L167C1-L181C14)](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L167C1-L181C14)
```rust
fn cross_chain_erc20_settlement( ... ) -> felt252{
    // ...
};
```

File:solidity/handler/contracts/ChakraSettlementHandler.sol
[![GitHub code snippet](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L111C1-L121C60)](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L111C1-L121C60)
```solidity
function cross_chain_erc20_settlement( ... ) external {
    require(amount > 0, "Amount must be greater than 0");
    require(to != 0, "Invalid to address");
    require(to_handler != 0, "Invalid to handler address");
    require(to_token != 0, "Invalid to token address");
```

2. Missed checks for status in Cairo receive callback.
File:cairo/handler/src/settlement.cairo
[![GitHub code snippet](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/settlement.cairo#L393C9-L442C10)](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/settlement.cairo#L393C9-L442C10)
```rust
fn receive_cross_chain_callback( ... ) -> bool{
    // ...
}
```

File:solidity/settlement/contracts/ChakraSettlement.sol
[![GitHub code snippet](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/settlement/contracts/ChakraSettlement.sol#L312C1-L315C11)](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/settlement/contracts/ChakraSettlement.sol#L312C1-L315C11)
```solidity
function processCrossChainCallback( ... ) internal {
    // ...
    require(
        create_cross_txs[txid].status == CrossChainTxStatus.Pending,
        "Invalid transaction status"
    );
    // ...
}
```

3. Missed checks for status in Cairo receive msg.
File:cairo/handler/src/handler_erc20.cairo
[![GitHub code snippet](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L108C9-L136C10)](https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L108C9-L136C10)
```rust
fn receive_cross_chain_msg( ... ) -> bool {
    // ...
}
```

File:solidity/settlement/contracts/ChakraSettlement.sol
[![GitHub code snippet](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/settlement/contracts/ChakraSettlement.sol#L199C1-L202C15)](https://github.com/code-423n4/2024-08-chakra/blob/
send_cross_chain_msg() misses msg.sender parameter on Starknet 
Audit: 2024-08-chakra-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L216


# Vulnerability details

## Impact

The main task of the settlement handler is to construct a message and then transfer it to the settlement contract for emitting an event for Chakra network to call `receive_cross_chain_msg()` on the destination chain. The problem is that the current version of `send_cross_chain_msg()` in the settlement misses `msg.sender` parameter when it's called from the handler and this can lead to some serious issues. 

## Proof of Concept

The current implementation of `send_cross_chain_msg()` call:

https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/handler_erc20.cairo#L216
```
 settlement.send_cross_chain_msg(to_chain, to_handler, PayloadType::ERC20, encode_message(message));
```

In the settlement contract `from_address` is used in the event emission:

https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/settlement.cairo#L303
```
 from_address: get_tx_info().unbox().account_contract_address,
```

So it's set as the address that initiated the tx (tx.origin). The problem is that the caller was a smart contract, it'd incorrectly reflect this `from_address`. Take a look at the Solidity implementation:

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L203-209
```
 settlement.send_cross_chain_msg(
                to_chain,
                msg.sender,
                to_handler,
                PayloadType.ERC20,
                cross_chain_msg_bytes
            );
```

So it uses `msg.sender` parameter as `from_address`. As the receive function on the destination chain is called by the Chakra network validators, they would use the info from the event emitted. And, as this address is incorrect, `from_address` would be also incorrect on the destination chain (for example, on Ethereum):

https://github.com/code-423n4/2024-08-chakra/blob/main/cairo/handler/src/settlement.cairo#L299-311
```
 self
                .emit(
                    CrossChainMsg {
                        cross_chain_settlement_id: cross_chain_settlement_id,
                        from_address: get_tx_info().unbox().account_contract_address,
                        from_chain: from_chain,
                        to_chain: to_chain,
                        from_handler: from_handler,
                        to_handler: to_handler,
                        payload_type: payload_type,
                        payload: payload
                    }
                );
```

## Tools Used

Manual review.

## Recommended Mitigation Steps

Add additional parameter to the `send_cross_chain_msg()` and use this parameter when emitting `CrossChainMsg` event.


## Assessed type

Other
Wrong data filled in a lot of fields
Audit: 2024-08-chakra-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L160
https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L218


# Vulnerability details

## Vulnerability explanation
The `create_cross_txs` stores the information for each of the messages initiated in the specific handler. The data that it stores is the following:
```
struct CreatedCrossChainTx {
    uint256 txid;
    string from_chain;
    string to_chain;
    address from;
    uint256 to;
    address from_token;
    uint256 to_token;
    uint256 amount;
    CrossChainTxStatus status;
}
```
The implementation to fill each of these fields looks like this:
```
    function cross_chain_erc20_settlement(
        string memory to_chain,
        uint256 to_handler,
        uint256 to_token,
        uint256 to,
        uint256 amount
    ) external {
        ...

        // Create a new cross chain tx
        uint256 txid = uint256(
            keccak256(
                abi.encodePacked(
                    chain,
                    to_chain,
                    msg.sender, // from address for settlement to calculate txid
                    address(this), //  from handler for settlement to calculate txid
                    to_handler,
                    nonce_manager[msg.sender]
                )
            )
        );

        {
            // Save the cross chain tx
            create_cross_txs[txid] = CreatedCrossChainTx(
                txid,
                chain,
                to_chain,
                msg.sender,
                to,
                address(this),
                to_token,
                amount,
                CrossChainTxStatus.Pending
            );
        }

        ...
    }
```
Here we can see that all fields are set properly except from one, the `from_token`. This field is filled with `address(this)` which is wrong because the handler address is not the address of the token being bridged. It should be passed the address of the token from the handler storage. We can find this storage variable in the [BaseSettlementHandler](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/BaseSettlementHandler.sol#L70).

There is an other case where this issue happens and it is in the final event emitted by the handler. It is not as severe as storing wrong data onchain but is still an issue. The issue instance can be seen [here](https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L218).

In the EVM implementation there is also an other wrong data in the settlement contract, in this case is in a field of the `receive_cross_txs` instances where it is supposed to save the address of the `to_handler` but it save the address of the settlement contract instead.
```
    function receive_cross_ch
Cross-chain messages can be initiated to destination handlers not whitelisted on the Source Chain
Audit: 2024-08-chakra-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L120


# Vulnerability details

## Impact
One of the protocol's critical invariants, as highlighted in the contest README, is:
> - In Settlement Handler Contract
>   - The handler receiving a cross-chain message must be on the whitelist for the source chain.

This requirement is essential to prevent users from sending cross-chain messages to unwhitelisted destination handlers, which would result in users' tokens being permanently locked on the source chain. We can see that the invarient is correctly enforced in Cairo contract:
```rs
fn cross_chain_erc20_settlement(ref self: ContractState, to_chain: felt252, to_handler: u256, to_token: u256, to: u256, amount: u256) -> felt252{
    assert(self.support_handler.read((to_chain, to_handler)), 'not support handler');
    // --SNIP
}
```
However, the current implementation of `ChakraSettlementHandler::cross_chain_erc20_settlement` in solidity contract, which initiates ERC20 cross-chain messages, does not adequately enforce this invariant:
```solidity
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {
    require(amount > 0, "Amount must be greater than 0");
    require(to != 0, "Invalid to address");
>>>    require(to_handler != 0, "Invalid to handler address");
    require(to_token != 0, "Invalid to token address");

    // --SNIP
}
```
As illustrated above, the only check on `to_handler` is that it must be non-zero, which is insufficient to enforce the whitelisting requirement. Consequently, cross-chain messages can be initiated to unwhitelisted destination handlers, leading to users' tokens being permanently locked in the source `ChakraSettlementHandler` since the message settlement will fail in the `receive_cross_chain_callback`:
```solidity
function receive_cross_chain_callback(
    uint256 txid,
    string memory from_chain,
    uint256 from_handler,
    CrossChainMsgStatus status,
    uint8 /* sign_type */, // validators signature type /  multisig or bls sr25519
    bytes calldata /* signatures */
) external onlySettlement returns (bool) {
    //  from_handler need in whitelist
    if (is_valid_handler(from_chain, from_handler) == false) {
        return false;
    }
    // --SNIP
}
```

## Tools Used
Manual Review

## Recommended Mitigation Steps
Consider verifying in the `cross_chain_erc20_settlement` function that the `to_handler` is whitelisted:
```diff
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {
    require(amount > 0, "Amount must be greater than 0");
    require(to != 0, "Invalid to address");
-   require(to_handler != 0, "Invalid to handler address");
+   require(is_valid_handler(to_chain, to_handler));
Early burn in `BurnUnlock` mode can lead to permanent loss of users' assets if cross-chain messages fail
Audit: 2024-08-chakra-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L130


# Vulnerability details

## Impact
The protocol supports two bridging modes that require burning assets on the source chain: `MintBurn` and `BurnUnlock`. In the `MintBurn` mode, assets being bridged to the destination chain are first **locked** on the source chain and then [burned only after the successful settlement](https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L384-L386) of the cross-chain message in the `receive_cross_chain_callback`:
##### Locking the assets on the source chain when initiating cross-chain message
```solidity
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {

    if (mode == SettlementMode.MintBurn) {
>>>        _erc20_lock(msg.sender, address(this), amount);
    }
    // --SNIP
}
```
##### Burning the bridged assets on the source chain ONLY after the successful settlement 
```solidity
function receive_cross_chain_callback(
    uint256 txid,
    string memory from_chain,
    uint256 from_handler,
    CrossChainMsgStatus status,
    uint8 /* sign_type */, // validators signature type /  multisig or bls sr25519
    bytes calldata /* signatures */
) external onlySettlement returns (bool) {
    // --SNIP
    if (status == CrossChainMsgStatus.Success) {
        if (mode == SettlementMode.MintBurn) {
>>>            _erc20_burn(address(this), create_cross_txs[txid].amount);
        }

        create_cross_txs[txid].status = CrossChainTxStatus.Settled;
    }
    // --SNIP
}
```
However, this safe approach is not applied to the `BurnUnlock` mode, where assets are **immediately** burned on the source chain during the initialization of the cross-chain message:
```solidity
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {

    if (mode == SettlementMode.MintBurn) {
        _erc20_lock(msg.sender, address(this), amount);
    } else if (mode == SettlementMode.LockUnlock) {
        _erc20_lock(msg.sender, address(this), amount);
    } else if (mode == SettlementMode.LockMint) {
        _erc20_lock(msg.sender, address(this), amount);
    } else if (mode == SettlementMode.BurnUnlock) {
>>>        _erc20_burn(msg.sender, amount);
    }
    // --SNIP
}
```
This is problematic as cross-chain messages can fail on the destination chain (e.g., if the source handler is removed from the whitelist). In such cases, the assets fail to be bridged to the destination chain but are still burned on the source chain, leading to a permanent loss of users' assets.

<details>
<summary>The same issue exists on Starknet handlers</summary>

```rs
fn cross_chain_erc20_settlement(ref
Tokens Locked Due to Invalid `to_chain` and `to_handler` Inputs in ChakraSettlementHandler
Audit: 2024-08-chakra-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L112-L113


# Vulnerability details

## Impact

The `ChakraSettlementHandler::cross_chain_erc20_settlement()` function locks or burns users' tokens and sends a cross-chain message. However, if the user provides incorrect `to_chain` or `to_handler` inputs, the validators are unlikely to sign the message. The settlement contract on the target chain never receives the cross chain message, resulting in permanent loss of the user's tokens.

## Proof of Concept

The only validation in `cross_chain_erc20_settlement()` for user-provided `to_chain` and `to_handler` is `to_handler != 0`:

```solidity
File: ChakraSettlementHandler.sol
111:     function cross_chain_erc20_settlement(
112:>>       string memory to_chain,
113:>>       uint256 to_handler,
114:         uint256 to_token,
115:         uint256 to,
116:         uint256 amount
117:     ) external {
118:         require(amount > 0, "Amount must be greater than 0");
119:         require(to != 0, "Invalid to address");
120:>>       require(to_handler != 0, "Invalid to handler address");
121:         require(to_token != 0, "Invalid to token address");
```

## Tools Used
vscode

## Recommended Mitigation Steps

Ensure the `to_chain` and `to_handler` are whitelisted in the `ChakraSettlementHandler::cross_chain_erc20_settlement()` function.





## Assessed type

Invalid Validation