Photon SOL - Entangle Labs

Transmitters and Executors are key Agents of the Entangle ecosystem.

Transmitters are a type of Agents responsible for compiling and aggregating data from various sources, including real-world data via APIs and blockchain data via RPCs.

On the other hand, Executors are a type of Agents responsible to execute operations in the Photon Endpoint Solana program.

For the Photon SOL program, both groups are set at initialization time i.e. when calling the initialize entry point with proper accounts.

Both transmitters and executors have a max number of members, being 20 on both cases as the snipper below shows:

lib.rs

    /// The maximum number of transmitters that can be registered in the system.
    /// Transmitters are critical for the dissemination and signing of cross-chain messages.
    pub const MAX_TRANSMITTERS: usize = 20;

    /// The maximum number of executors allowed within the system.
    /// Executors are responsible for carrying out operations and managing transaction state transitions.
    pub const MAX_EXECUTORS: usize = 20;

The current implementation of the initialize entry point is not validating that the provided arrays of transmitters and executors respects the boundaries previously mentioned, as shown in the snippet below:

lib.rs

    pub fn initialize(
        ctx: Context<Initialize>,
        eob_chain_id: u64,
        eob_master_smart_contract: Vec<u8>,
        consensus_target_rate: u64,
        gov_transmitters: Vec<EthAddress>,
        gov_executors: Vec<Pubkey>,
    ) -> Result<()> {
        ctx.accounts.config.admin = ctx.accounts.admin.key();
        ctx.accounts.config.eob_chain_id = eob_chain_id;
        require_eq!(eob_master_smart_contract.len(), 32);
        ctx.accounts.config.eob_master_smart_contract.copy_from_slice(&eob_master_smart_contract);
        ctx.accounts.protocol_info.is_init = true;
        ctx.accounts.protocol_info.protocol_address = photon::ID;
        ctx.accounts.protocol_info.consensus_target_rate = consensus_target_rate;
        ctx.accounts.protocol_info.transmitters = Default::default();
        for (i, k) in gov_transmitters.into_iter().enumerate() {
            ctx.accounts.protocol_info.transmitters[i] = k;
        }
        ctx.accounts.protocol_info.executors = Default::default();
        for (i, e) in gov_executors.into_iter().enumerate() {
            ctx.accounts.protocol_info.executors[i] = e;
        }
        Ok(())
    }

As of to now, there's no evidence that such lack of assertions generates any vulnerability.

The initialize function can only be called by a platform admin or by the DEPLOYER address, which transforms the function in a permissioned function.

If in any given case an admin incorrectly provides arrays with more members than expected, the receive_photon_msg permissioned entry point can be used to fix the mentioned problem.

Although there is no evidence that this implementation may introduce a vulnerability, it is considered best practice to adhere to the established code constraints, as unforeseen consequences may arise that are not immediately apparent.

Implement validations in the initialize entry point to check that both transmitters and executors arrays respects the boundaries of MAX_TRANSMITTER and MAX_EXECUTORS respectively.

ACKNOWLEDGED: The Entangle Labs team acknowledged this finding.

Events emission is considered a good practice to debug situations where it is necessary to check the parameters used to call an entry point.

Events can also be used to create a monitoring system to check the platform integrity in real time (or as real-time as possible).

The majority of platforms and protocols use use-case specific parameters and accounts for certain operations, so implementing events is a common practice.

In the case of CHEF, we identified at least 10 functions that changes the state without emitting an event:

• set_admin

• add_allowed_protocol_address

• remove_allowed_protocol_address

• add_allowed_proposer_address

• remove_allowed_proposer_address

• add_executor

• remove_executor

• add_transmitters_impl

• remove_transmitters_impl

• set_consensus_target_rate

As a consequence, critical changes can be executed in the platform without any way to monitor them.

For all of the mentioned functions, implement an event emission with proper information about old and new states.

ACKNOWLEDGED: The Entangle Labs team acknowledged this finding.