#43114 [BC-Critical] attackers can cause total shutdown network by exploiting missing of blob size check in da lightnode

#43114 [BC-Critical] Attackers can cause total shutdown network by exploiting missing of blob size check in DA Lightnode

Submitted on Apr 2nd 2025 at 10:14:19 UTC by @perseverance for Attackathon | Movement Labs

• Report ID: #43114

• Report Type: Blockchain/DLT

• Report severity: Critical

• Target: https://github.com/immunefi-team/attackathon-movement/tree/main/protocol-units/da/movement/

• Impacts:

  • Network not being able to confirm new transactions (total network shutdown)

Description

Short summary

Attackers can cause total shutdown network by exploiting missing of blob size check in DA Lightnode. The Blob Size Limit of Celestia is having a hard cap of 2 Mb. If submit blob size is greater than 2 Mb, then blobs are rejected. DA Lightnode does not check the size of Blob when submit to Celestia RPC Client. So when the Blob is rejected, then all the transactions of users are not executed, just causing total network shutdown. Since the attacker's transactions are not executed as well, so there is no cost for the attackers. Just the small cost of sending the spam transactions, thus make the attack threat is really high.

Background Information

The transactions passed validation from the mempool ==> included in the mempool ==> submit (or batch_write) to DA Lightnode

Step 1: Transactions from users are sent to Sender of a Multi Producer Single Consumer Channel.

Step 2: Transactions are read from Receiver of a Multi Producer Single Consumer Channel. This is FIFO Channel. (Ref: https://doc.rust-lang.org/std/sync/mpsc/index.html)

Step 3: Transactions is pushed to transactions vector

Step 4: Call da_light_node_client.batch_write to batch_write the transactions to the DA Lightnode

So notice that when transactions are read from Receiver, it is removed from the FIFO Channel.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/networks/movement/movement-full-node/src/node/tasks/transaction_ingress.rs#L38-L129

/// Constructs a batch of transactions then spawns the write request to the DA in the background.
	async fn spawn_write_next_transaction_batch(
		&mut self,
	) -> Result<ControlFlow<(), ()>, anyhow::Error> {
		use ControlFlow::{Break, Continue};

		// limit the total time batching transactions
		let start = Instant::now();
		let (_, half_building_time) = self.da_light_node_config.block_building_parameters();

		let mut transactions = Vec::new();

		let batch_id = LOGGING_UID.fetch_add(1, std::sync::atomic::Ordering::SeqCst);
		loop {
			let remaining = match half_building_time.checked_sub(start.elapsed().as_millis() as u64)
			{
				Some(remaining) => remaining,
				None => {
					// we have exceeded the half building time
					break;
				}
			};

			match tokio::time::timeout(
				Duration::from_millis(remaining),
				self.transaction_receiver.recv(), // @audit <--- step 2: transactions are read from Receiver of a Multi Producer Single Consumer Channel. This is FIFO Channel. 
			)
			.await
			{
				Ok(transaction) => match transaction {
					Some((application_priority, transaction)) => {
						info!(
							target : "movement_timing",
							batch_id = %batch_id,
							tx_hash = %transaction.committed_hash(),
							sender = %transaction.sender(),
							sequence_number = transaction.sequence_number(),
							"received transaction",
						);
						let serialized_aptos_transaction = bcs::to_bytes(&transaction)?;
						let movement_transaction = movement_types::transaction::Transaction::new(
							serialized_aptos_transaction,
							application_priority,
							transaction.sequence_number(),
						);
						let serialized_transaction = serde_json::to_vec(&movement_transaction)?;
						transactions.push(BlobWrite { data: serialized_transaction }); // @audit  <--- Step 2: Transactions is pushed to transactions vector 
					}
					None => {
						// The transaction stream is closed, terminate the task.
						return Ok(Break(()));
					}
				},
				Err(_) => {
					break;
				}
			}
		}

		if transactions.len() > 0 {
			info!(
				target: "movement_timing",
				batch_id = %batch_id,
				transaction_count = transactions.len(),
				"built_batch_write"
			);
			let batch_write = BatchWriteRequest { blobs: transactions };
			let mut buf = Vec::new();
			batch_write.encode_raw(&mut buf);
			info!("batch_write size: {}", buf.len());
			// spawn the actual batch write request in the background
			let mut da_light_node_client = self.da_light_node_client.clone();
			tokio::spawn(async move {
				match da_light_node_client.batch_write(batch_write.clone()).await { // @audit <-- Step 4: Call da_light_node_client.batch_write to batch_write the transactions to the DA Lightnode 
					Ok(_) => {
						info!(
							target: "movement_timing",
							batch_id = %batch_id,
							"batch_write_success"
						);
						return;
					}
					Err(e) => {
						warn!("failed to write batch to DA: {:?} {:?}", e, batch_id);
					}
				}
			});
		}

		Ok(Continue(()))
	}
}

Notice that the loop in spawn_write_next_transaction_batch is batching all transactions in time of block_building_parameters. This parameter is configurable and the default value is 1000 ms that is 1 second.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/sequencing/memseq/util/src/lib.rs#L22

/// The configuration for the MemSeq sequencer
#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, Eq)]
pub struct Config {
	/// The chain id of the sequencer
	#[serde(default = "Config::default_sequencer_chain_id")]
	pub sequencer_chain_id: Option<String>,

	/// The path to the sequencer database
	#[serde(default = "Config::default_sequencer_database_path")]
	pub sequencer_database_path: Option<String>,

	/// The memseq build time for the block
	#[serde(default = "default_memseq_build_time")]
	pub memseq_build_time: u64,

	/// The memseq max block size
	#[serde(default = "default_memseq_max_block_size")]
	pub memseq_max_block_size: u32,
}

env_default!(default_memseq_build_time, "MEMSEQ_BUILD_TIME", u64, 1000); // @audit default memseq build time  = 1000 ms = 1 second 

env_default!(default_memseq_max_block_size, "MEMSEQ_MAX_BLOCK_SIZE", u32, 2048); // @audit default max block size is 2048 

impl Default for Config {
	fn default() -> Self {
		Config {
			sequencer_chain_id: Config::default_sequencer_chain_id(),
			sequencer_database_path: Config::default_sequencer_database_path(),
			memseq_build_time: default_memseq_build_time(),
			memseq_max_block_size: default_memseq_max_block_size(),
		}
	}
}

So the DA Lightnode now can work in 2 modes: blocky or sequencer mode:

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/protocol/light-node/README.md#L1-L6

Blocky Mode of DA Lightnode

If the DA Lightnode works in Blocky mode, then block of transactions received from mempool are signed to create Blob data and send to Celestia.

The code to send the blob to Celestia is here:

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/protocol/light-node/src/passthrough.rs#L229-L248

/// Batch write blobs.
	async fn batch_write(
		&self,
		request: tonic::Request<BatchWriteRequest>,
	) -> std::result::Result<tonic::Response<BatchWriteResponse>, tonic::Status> {
		let blobs = request.into_inner().blobs;
		for data in blobs {
			let blob = InnerSignedBlobV1Data::now(data.data)
				.try_to_sign(&self.signer)
				.await
				.map_err(|e| tonic::Status::internal(format!("Failed to sign blob: {}", e)))?;
			self.da
				.submit_blob(blob.into()) // @audit call da.submit_blob to submit Blob to Celestia. 
				.await
				.map_err(|e| tonic::Status::internal(e.to_string()))?;
		}

		// * We are currently not returning any blobs in the response.
		Ok(tonic::Response::new(BatchWriteResponse { blobs: vec![] }))
	}

Since the DA Lightnode is sending to Celestia, it is using Celestia RPC Client

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/providers/celestia/src/da/mod.rs#L59-L80

fn submit_blob(
		&self,
		data: DaBlob<C>,
	) -> Pin<Box<dyn Future<Output = Result<(), DaError>> + Send + '_>> {
		Box::pin(async move {
			debug!("submitting blob to celestia {:?}", data);

			// create the blob
			let celestia_blob = self
				.create_new_celestia_blob(data)
				.map_err(|e| DaError::Internal(format!("failed to create celestia blob :{e}")))?;

			debug!("created celestia blob {:?}", celestia_blob);

			// submit the blob to the celestia node
			self.submit_celestia_blob(celestia_blob)  // @audit call submit_celestia_blob 
				.await
				.map_err(|e| DaError::Internal(format!("failed to submit celestia blob :{e}")))?;

			Ok(())
		})
	}

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/providers/celestia/src/da/mod.rs#L42-L52

/// Submits a CelestiaBlob to the Celestia node.
	pub async fn submit_celestia_blob(&self, blob: CelestiaBlob) -> Result<u64, anyhow::Error> {
		let config = TxConfig::default();
		// config.with_gas(2);
		let height = self.default_client.blob_submit(&[blob], config).await.map_err(|e| { // @audit call default_client.blob_submit to submit Blob 
			error!(error = %e, "failed to submit the blob");
			anyhow::anyhow!("Failed submitting the blob: {}", e)
		})?;

		Ok(height)
	}

Notice that there is no check or ways to control the size of blob before calling blob_submit. If the function blob_submit return error, then the error is returned back, but there is no mechanism to retry or rebuild the block.

Celestia Hard Cap Block Size to 2 MB

https://docs.celestia.org/how-to-guides/mainnet#transaction-size-limit

As specified in CIP-28, there is a 2 MiB (2,097,152 bytes) limit on individual transaction size. This limit was implemented to maintain network stability and provide clear expectations for users and developers, even as block sizes may be larger.

So if the Blob Data exceed the limit, the transaction will be rejected.

This is done in the code of Celestia

https://github.com/celestiaorg/celestia-node/blob/e9026800ed67859deb0a4f31e832a4586bee1d45/blob/blob.go#L93-L95

func NewBlob(shareVersion uint8, namespace share.Namespace, data []byte) (*Blob, error) {
	if len(data) == 0 || len(data) > appconsts.DefaultMaxBytes {
		return nil, fmt.Errorf("blob data must be > 0 && <= %d, but it was %d bytes", appconsts.DefaultMaxBytes, len(data))
	}

The current default RPC that Movement using is Lumina RPC

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/Cargo.toml#L231

celestia-rpc = { git = "https://github.com/eigerco/lumina", rev = "c6e5b7f5e3a3040bce4262fe5fba5c21a2637b5" }   #{ version = "0.7.0" }

I checked the code and found that there is one test case also confirm this. So if the blob size is bigger than size limit, the function default_client.blob_submit will return error.

https://github.com/eigerco/lumina/blob/main/rpc/tests/blob.rs#L162-L170

#[tokio::test]
async fn blob_submit_too_large() {
    let client = new_test_client(AuthLevel::Write).await.unwrap();
    let namespace = random_ns();
    let data = random_bytes(5 * 1024 * 1024);
    let blob = Blob::new(namespace, data, AppVersion::V2).unwrap();

    blob_submit(&client, &[blob]).await.unwrap_err();
}

Sequencer Mode of DA Lightnode

If the DA Lightnode works in "Sequencer" mode, then it is more complicated, but the same issue that blob size is not controlled.

Blob Data is received from Mempool and then write to RockDB Mempool.

Then the transactions are pop from RockDB Mempool to build block. This is happening during the tick.

In the Sequencer, the transactions in a block are limited to block_size that can be configured. The default value is default max block size is 2048 as noticed above.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/sequencing/memseq/sequencer/src/lib.rs#L101-L131

/// Waits for the next block to be built, either when the block size is reached or the building time expires.
	async fn wait_for_next_block(&self) -> Result<Option<Block>, anyhow::Error> {
		let mut transactions = Vec::with_capacity(self.block_size as usize);

		let now = Instant::now();

		loop {
			let current_block_size = transactions.len() as u32;
			if current_block_size >= self.block_size {
				break;
			}

			let remaining = self.block_size - current_block_size;
			let mut transactions_to_add = self.mempool.pop_transactions(remaining as usize).await?; // @audit pop_transactions remove transactions from RockDB mempool 
			transactions.append(&mut transactions_to_add);

			// sleep to yield to other tasks and wait for more transactions
			tokio::task::yield_now().await;

			if now.elapsed().as_millis() as u64 > self.building_time_ms {
				break;
			}
		}

		if transactions.is_empty() {
			Ok(None)
		} else {
			let new_block =
				self.build_next_block(block::BlockMetadata::default(), transactions).await?;
			Ok(Some(new_block))
		}
	}

Then the block is sent to "Sender" of Multi Producer Single Receiver Channel.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/protocol/light-node/src/sequencer.rs#L142-L162

async fn tick_build_blocks(&self, sender: Sender<Block>) -> Result<(), anyhow::Error> {
		let memseq = self.memseq.clone();

		// this has an internal timeout based on its building time
		// so in the worst case scenario we will roughly double the internal timeout
		let uid = LOGGING_UID.fetch_add(1, std::sync::atomic::Ordering::SeqCst);
		debug!(target: "movement_timing", uid = %uid, "waiting_for_next_block",);
		let block = memseq.wait_for_next_block().await?;
		match block {
			Some(block) => {
				info!(target: "movement_timing", block_id = %block.id(), uid = %uid, transaction_count = block.transactions().len(), "received_block");
				sender.send(block).await?; // @audit send Block built to Sender 
				Ok(())
			}
			None => {
				// no transactions to include
				debug!(target: "movement_timing", uid = %uid, "no_transactions_to_include");
				Ok(())
			}
		}
	}

Then the block will be sent to Celestia through the same code as Passthrough.rs that I analyzed above.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/protocol/light-node/src/sequencer.rs#L219-L241

/// Ticks the block proposer to build blocks and submit them
	async fn tick_publish_blobs(
		&self,
		receiver: &mut Receiver<Block>,
	) -> Result<(), anyhow::Error> {
		// get some blocks in a batch
		let blocks = self.read_blocks(receiver).await?; // @audit Read from Receiver MPSC channel 
		if blocks.is_empty() {
			return Ok(());
		}

		// submit the blobs, resizing as needed
		let ids = blocks.iter().map(|b| b.id()).collect::<Vec<_>>();
		for block_id in &ids {
			info!(target: "movement_timing", %block_id, "submitting_block_batch");
		}
		self.submit_blocks(blocks).await?; // @audit call submit_blocks 
		for block_id in &ids {
			info!(target: "movement_timing", %block_id, "submitted_block_batch");
		}

		Ok(())
	}

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/protocol/light-node/src/sequencer.rs#L164-L173

/// Submits blocks to the pass through.
	async fn submit_blocks(&self, blocks: Vec<Block>) -> Result<(), anyhow::Error> {
		for block in blocks {
			let data: InnerSignedBlobV1Data<C> = block.try_into()?;
			let blob = data.try_to_sign(&self.pass_through.signer).await?;
			self.pass_through.da.submit_blob(blob.into()).await?;
		}

		Ok(())
	}

To summarize, the users transactions are batched into a blob during block_building_parameters in Blocky mode of DA Lightnode. In Sequencer mode of DA Lightnode, the transactions in a block are also limited to block_size that can be configured. The building time of block is also limited to block_building_parameters. The default value is default max block size is 2048 as noticed above.

The bug is there is no mechanism to control the size of a blob. So if the blob size exceeds the size limit of Celestia Transaction size, then all user transactions in block are lost, not executed.

Attack Scenario

The transaction size limit of Movement now is 64 Kb per transactions. This is hard coded in the code as below.

https://github.com/immunefi-team/attackathon-movement-aptos-core/blob/627b4f9e0b63c33746fa5dae6cd672cbee3d8631/aptos-move/aptos-gas-schedule/src/gas_schedule/transaction.rs#L69-L73

  [
            max_transaction_size_in_bytes: NumBytes,
            "max_transaction_size_in_bytes",
            64 * 1024
        ],

So an attacker can create 1000 valid transactions with the maximum size possible.

For example, an attacker can create 1000 accounts. Each account submit a transaction to deploy a big smart contract. Each transaction is 63 Kbytes.

So the total size of all transactions would be: 63 * 1024 * 1000 = 64_512_000

Notice that now the movement allow one user to create maximum 32 transactions (= Sequence tolerance), so it would be easier for the attacker. He just need to create 32 accounts. But this is optional as this is not needed for this attack.

To bypass rate limit, the attacker can submit the transactions from different machines, IPs, ...

Since this is valid transactions, the movement node should accept these transactions.

All 1000 transactions in 1 seconds will be batched into the mempool and into a single blob.

The blob compress before sending and compress ratio

Actually before sending to Celestia, the blob data is compressed using zstd library.

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/protocol-units/da/movement/providers/celestia/src/blob/ir.rs#L26-L49

/// Tries to form a CelestiaBlob from a CelestiaDaBlob
impl<C> TryFrom<CelestiaDaBlob<C>> for CelestiaBlob
where
	C: Curve + Serialize,
{
	type Error = anyhow::Error;

	fn try_from(da_blob: CelestiaDaBlob<C>) -> Result<Self, Self::Error> {
		// Extract the inner blob and namespace
		let CelestiaDaBlob(da_blob, namespace) = da_blob;

		// Serialize the inner blob with bcs
		let serialized_blob = bcs::to_bytes(&da_blob).context("failed to serialize blob")?;

		// Compress the serialized data with zstd
		let compressed_blob =
			zstd::encode_all(serialized_blob.as_slice(), 0).context("failed to compress blob")?; // @audit using encode_all to compress the data with level 0 

		// Construct the final CelestiaBlob by assigning the compressed data
		// and associating it with the provided namespace
		Ok(CelestiaBlob::new(namespace, compressed_blob, AppVersion::V2)
			.map_err(|e| anyhow::anyhow!(e))?)
	}
}

The Library is zstd, in this case is: https://github.com/gyscos/zstd-rs

https://github.com/immunefi-team/attackathon-movement/blob/a2790c6ac17b7cf02a69aea172c2b38d2be8ce00/Cargo.toml#L345

zstd = "0.13"

The compress level is 0 that is default level of 3.

https://github.com/gyscos/zstd-rs/blob/229054099aa73f7e861762f687d7e07cac1d9b3b/src/stream/functions.rs#L27-L36

/// Compress all data from the given source as if using an `Encoder`.
///
/// Result will be in the zstd frame format.
///
/// A level of `0` uses zstd's default (currently `3`). // @audit level 0 means default level of 3 
pub fn encode_all<R: io::Read>(source: R, level: i32) -> io::Result<Vec<u8>> {
   
}

I researched about the compress level and found that with level 3 the output size is 2.5 to 3.5 smaller than input size.

For example: https://github.com/klauspost/compress/blob/master/zstd/README.md

Or I run the benchmark.rs (https://github.com/gyscos/zstd-rs/blob/main/examples/benchmark.rs) and give me result the compress ratio is that the output size about 3 times smaller than input

Compression level       Input size      Output size     Compression ratio       

3       				211.94 MB       66.48 MB        3.188   				

So with the compress ratio of about 3 times. The actual compress ratio depends on the data. Let's assume the compress ratio is 4 times

With the size of above input 64_512_000 would result in more than 16_128_000 that is still much bigger than 2 MB cap.

So if the attacker send this transactions for every block, then all valid user transactions are not executed and dropped. Since the attackers' transactions are dropped also, so no cost for him to execute the attack. There is only a small cost to send the requests and some money to prepare all 1000 accounts for the attack.

The capital needed: 1000 * 1 MOVE = 1000 * 0.4 = 400 USD (Price: https://coinmarketcap.com/currencies/movement/)

1 MOVE is more than enough to pay gas for a big smart contract deployment. The actual cost probably is lower.

Severity Assessment

Bug Severity: Critical

Impact:

Network not being able to confirm new transactions (total network shutdown)

Likelihood:

• High as No special privileges required

• Can be executed by any attacker with very cheap cost of attack.

• The cost of an attack is 0

• The capital is < 400 USD

Recommendation

Implement mechanism to control blob size that after compress should have size less then Celestia Blob Size limit of 2 MB.

Proof of Concept

Proof of concept

The following attack scenario demonstrate the bug.

Preparation: An attacker can create 1000 accounts. Each account has 1 MOVE.

Step 1: So an attacker can create 1000 valid transactions with the maximum size possible and send in every seconds.

Each account submit a transaction to deploy a big smart contract. Each transaction is 63 Kbytes.

So the total size of all transactions would be: 63 * 1024 * 1000 = 64_512_000

To bypass rate limit, the attacker can submit the transactions from different machines, IPs, ...

Since this is valid transactions, the movement node should accept these transactions.

All 1000 transactions in 1 seconds will be batched into the mempool and into a single blob.

Expected output: All user transactions including attacker transactions are dropped.

The attached image or sequence diagram below illustrates the attack

sequenceDiagram
    participant Attacker
    participant Movement Node
    participant Mempool
    participant DA Lightnode
    participant Celestia RPC
    participant Celestia Network

    Note over Attacker,Celestia Network: Preparation: Create 1000 accounts<br/>Each account has 1 MOVE (~0.4 USD)

    loop Every Second
        Note over Attacker: Create 1000 valid transactions<br/>Each transaction: 63KB<br/>Total: 64.5MB
        
        Attacker->>Movement Node: Send 1000 transactions
        Movement Node->>Mempool: Add to mempool
        Note over Mempool: Batch transactions within 1s
        
        Mempool->>DA Lightnode: Send transaction batch
        Note over DA Lightnode: Compress data with zstd (level 0)<br/>Compression ratio ~1:3
        
        DA Lightnode->>Celestia RPC: Send compressed blob (~21.5MB)
        Celestia RPC->>Celestia Network: Submit blob
        
        Note over Celestia Network: Check blob size<br/>Limit: 2MB
        Celestia Network-->>Celestia RPC: Error: Blob too large
        Celestia RPC-->>DA Lightnode: Submit error
        DA Lightnode-->>Mempool: Batch processing error
        Note over Mempool: Drop all transactions<br/>in the batch
        
        Note over Movement Node: All valid user transactions<br/>are dropped
    end