## Summary The fraud detection function `is_kickoff_malicious()` in `core/src/verifier.rs` automatically classifies any database retrieval error as malicious behavior, creating an economic attack vector where attackers can trigger database overload to cause false fraud alerts and impose transaction costs and operational burdens on legitimate operators. ## Finding Description The `is_kickoff_malicious()` function at `core/src/verifier.rs:1544-1605` validates operator kickoffs by querying database payout information. However, the implementation contains a critical business logic flaw where operational database failures are interpreted as evidence of malicious behavior: ```rust // core/src/verifier.rs:1555-1565 let payout_info = self .db .get_payout_info_from_move_txid(dbtx, move_txid) .await; if let Err(e) = &payout_info { tracing::warn!( "Couldn't retrieve payout info from db {}, assuming malicious", e ); return Ok(true); // ← Any database error = malicious classification } ``` The function queries the database to retrieve payout information for validation: ```rust // core/src/database/verifier.rs:252-265 pub async fn get_payout_info_from_move_txid( &self, tx: Option>, move_to_vault_txid: Txid, ) -> Result, BlockHash, Txid, i32)>, BridgeError> { let query = sqlx::query_as::<_, (Option, BlockHashDB, TxidDB, i32)>( "SELECT w.payout_payer_operator_xonly_pk, w.payout_tx_blockhash, w.payout_txid, w.idx FROM withdrawals w WHERE w.move_to_vault_txid = $1", ) .bind(TxidDB(move_to_vault_txid)); let result: Option<(Option, BlockHashDB, TxidDB, i32)> = execute_query_with_tx!(self.connection, tx, query, fetch_optional)?; // ← Database connection errors, timeouts, or query failures propagate as BridgeError ``` **Required Imports and Error Types:** ```rust // Key imports enabling this vulnerability pattern - core/src/verifier.rs & core/src/database/mod.rs use crate::errors::{BridgeError, TxError}; // Error types for database failures - core/src/verifier.rs:30 use crate::database::{Database, DatabaseTransaction}; // Database types - core/src/verifier.rs:28 use bitcoin::{Address, Amount, ScriptBuf, Witness, XOnlyPublicKey}; // Bitcoin primitive types - core/src/verifier.rs:59 use sqlx::{Pool, Postgres}; // Database connection pool (vulnerable to exhaustion) - core/src/database/mod.rs:17 // BridgeError::DatabaseError propagation pattern #[error("Failed to call database: {0}")] DatabaseError(#[from] sqlx::Error), // core/src/errors.rs:157 - Any sqlx::Error becomes BridgeError ``` **Additional False Positive Triggers:** The function contains multiple automatic malicious classifications for missing data: ```rust // core/src/verifier.rs:1567-1570 let Some((operator_xonly_pk_opt, payout_blockhash, _, _)) = payout_info else { tracing::warn!("No payout info found in db, assuming malicious"); return Ok(true); // ← Missing data = malicious }; // core/src/verifier.rs:1572-1575 let Some(operator_xonly_pk) = operator_xonly_pk_opt else { tracing::warn!("No operator xonly pk found in payout tx OP_RETURN, assuming malicious"); return Ok(true); // ← Missing operator key = malicious }; ``` ## Impact Explanation **Economic Attack Vector Through False Positive Fraud Detection:** The vulnerability creates a critical business logic flaw where legitimate operational issues are classified as fraudulent behavior, enabling economic attacks against honest operators. **Economic Consequence Chain - Code Evidence:** **Step 1: False Positive Detection** (`core/src/verifier.rs:1564`): ```rust // Database error automatically classified as malicious if let Err(e) = &payout_info { tracing::warn!("Couldn't retrieve payout info from db {}, assuming malicious", e); return Ok(true); // ← False positive: DB error = malicious behavior } ``` **Step 2: Economic Penalty Processing** (`core/src/verifier.rs:1617-1628`): ```rust // handle_kickoff processes malicious classification let is_malicious = self .is_kickoff_malicious(kickoff_witness, &mut deposit_data, kickoff_data, Some(dbtx)) .await?; if !is_malicious { return Ok(false); // Early exit for legitimate operators } tracing::warn!("Malicious kickoff {:?} for deposit {:?}", kickoff_data, deposit_data); // Continues to create challenge transactions for "malicious" (actually database error) operators ``` **Step 3: Challenge Transaction Creation** (`core/src/verifier.rs:1637-1645`): ```rust // Economic penalty transactions created for false positives let signed_txs = create_and_sign_txs( self.db.clone(), &self.signer, self.config.clone(), context, None, Some(dbtx), ) .await?; // ← Creates challenge transactions with associated Bitcoin fees ``` **Step 4: Transaction Fee Application** (`core/src/verifier.rs:1666-1682`): ```rust // Challenge transactions queued for broadcast TransactionType::Challenge | TransactionType::AssertTimeout(_) | TransactionType::KickoffNotFinalized | TransactionType::LatestBlockhashTimeout | TransactionType::OperatorChallengeNack(_) => { #[cfg(feature = "automation")] self.tx_sender .add_tx_to_queue( dbtx, *tx_type, // ← Challenge transaction type signed_tx, // ← Actual transaction with Bitcoin network fees &signed_txs, tx_metadata, &self.config, None, ) .await?; } // Result: Innocent operator pays Bitcoin transaction fees for database operational issues ``` **Attack Scenarios - Code Evidence:** **1. Database DoS Attack** (`core/src/database/verifier.rs:264-265`): ```rust // Database connection pool vulnerable to exhaustion let result: Option<(Option, BlockHashDB, TxidDB, i32)> = execute_query_with_tx!(self.connection, tx, query, fetch_optional)?; // ^^^^^^^^^^^^^ ← Shared connection pool // Attack: Flood connections → pool exhausted → legitimate queries fail with BridgeError // Result: execute_query_with_tx! returns Err(BridgeError::DatabaseError(sqlx::Error)) // → propagates to is_kickoff_malicious() → "assuming malicious" → false positive ``` **2. Resource Exhaustion Attack** (`core/src/verifier.rs:1557-1558`): ```rust // Database query vulnerable to resource saturation let payout_info = self .db .get_payout_info_from_move_txid(dbtx, move_txid) // ← Query execution point .await; // Attack scenarios that trigger BridgeError: // - High query load → sqlx::Error → BridgeError::DatabaseError // - Memory exhaustion → sqlx::Error → BridgeError::DatabaseError // - Lock contention → sqlx::Error → BridgeError::DatabaseError // - Disk I/O saturation → sqlx::Error → BridgeError::DatabaseError // All lead to same false positive path: Err(e) → "assuming malicious" ``` **3. Network Interference Attack** (`core/src/database/verifier.rs:257-262`): ```rust // Network connection vulnerable to interference let query = sqlx::query_as::<_, (...)>( "SELECT w.payout_payer_operator_xonly_pk, w.payout_tx_blockhash, w.payout_txid, w.idx FROM withdrawals w WHERE w.move_to_vault_txid = $1", // ← Network database call ) .bind(TxidDB(move_to_vault_txid)); // Attack: Network disruption → Connection drops → BridgeError::DatabaseError(sqlx::Error) // MITM attacks, DNS poisoning, packet loss → same vulnerability path // Result: Network failure treated as malicious behavior by is_kickoff_malicious() ``` **Common Vulnerability Path for All Attacks:** ```rust // core/src/verifier.rs:1559-1565 // Any BridgeError from database layer triggers false positive if let Err(e) = &payout_info { // ← e can be any of: // DoS Attack: BridgeError::DatabaseError(sqlx::Error::ConnectionTimeout) // Resource Attack: BridgeError::DatabaseError(sqlx::Error::QueryTimeout) // Network Attack: BridgeError::DatabaseError(sqlx::Error::NetworkError) tracing::warn!("Couldn't retrieve payout info from db {}, assuming malicious", e); return Ok(true); // ← All attack scenarios lead to same false positive } ``` **Missing Resilience Mechanisms - Code Evidence:** **No Retry Logic** (`core/src/verifier.rs:1559-1565`): ```rust // Single database failure immediately triggers false positive if let Err(e) = &payout_info { // No retry attempts, no backoff, no circuit breaker tracing::warn!("Couldn't retrieve payout info from db {}, assuming malicious", e); return Ok(true); // ← Immediate malicious classification } // Missing: retry_with_backoff(), circuit_breaker_check(), error_classification() ``` **No Error Differentiation** (`core/src/verifier.rs:1559-1565`): ```rust // All BridgeError types treated identically as malicious behavior if let Err(e) = &payout_info { // ← e could be: // - BridgeError::DatabaseError(sqlx::Error::ConnectionTimeout) // - BridgeError::DatabaseError(sqlx::Error::NetworkError) // - BridgeError::DatabaseError(sqlx::Error::ConnectionPoolExhausted) // - BridgeError::DatabaseError(sqlx::Error::QueryTimeout) // - BridgeError::DatabaseError(sqlx::Error::TransactionRollback) // All classified as "malicious" - no error type checking return Ok(true); } ``` **No Graceful Degradation** (`core/src/verifier.rs:1544-1605`): ```rust // Function signature only returns Result // No Option to represent "uncertain/unknown" state // No mechanism to defer decisions during database unavailability // Binary choice: malicious (true) or not malicious (false) // Missing: Ok(None) for "database unavailable, cannot determine" ``` ## Likelihood Explanation **High Likelihood - Database Dependencies Create Attack Surface:** The vulnerability manifests through predictable database operational issues that can be externally triggered or naturally occurring. **Attack Vector Analysis:** 1. **Database Overload Trigger** (`core/src/verifier.rs:1555-1558`): ```rust // Critical single point of failure - database query execution let payout_info = self .db .get_payout_info_from_move_txid(dbtx, move_txid) // ← Line 1557: Vulnerability trigger .await; ``` - Function depends on successful database query execution - Any connection timeout, query failure, or resource exhaustion triggers false positive - No retry mechanism or error classification exists 2. **Common Database Error Scenarios**: ``` Database Connection Timeout → BridgeError → Malicious Classification Query Resource Exhaustion → BridgeError → Malicious Classification Network Connectivity Issues → BridgeError → Malicious Classification Database Maintenance → BridgeError → Malicious Classification Connection Pool Saturation → BridgeError → Malicious Classification ``` 3. **Economic Attack Execution** (`core/src/verifier.rs:1564`): - `return Ok(true)` triggers fraud detection for innocent operators - Challenge transactions automatically created with associated fees - No mechanism to distinguish legitimate database errors from actual fraud **Code-Based Likelihood Analysis:** The implementation architecture creates high vulnerability probability through multiple single points of failure: **Database Dependency Architecture** (`core/src/verifier.rs:1555-1558`): ```rust // Critical single point of failure - no alternative validation path let payout_info = self .db .get_payout_info_from_move_txid(dbtx, move_txid) // ← Single database dependency .await; // No fallback mechanism, cached data, or alternative validation method // Function cannot determine legitimacy without successful database connection ``` **Zero Resilience Implementation** (`core/src/verifier.rs:1559-1565`): ```rust // No error handling sophistication - immediate false positive trigger if let Err(e) = &payout_info { // Missing resilience patterns: // - No retry_with_backoff() // - No circuit_breaker_check() // - No error_type_classification() // - No temporary_failure_handling() tracing::warn!("Couldn't retrieve payout info from db {}, assuming malicious", e); return Ok(true); // ← Immediate false positive on any database issue } ``` **Shared Resource Vulnerability** (`core/src/database/verifier.rs:264-265`): ```rust // Database connection shared across all fraud detection calls let result: Option<(Option, BlockHashDB, TxidDB, i32)> = execute_query_with_tx!(self.connection, tx, query, fetch_optional)?; // ^^^^^^^^^^^^^ ← Shared connection pool // Multiple concurrent fraud checks compete for same database resources // Resource contention increases failure probability during high load ``` **Binary Decision Architecture** (`core/src/verifier.rs:1544-1550`): ```rust // Function signature forces binary malicious/non-malicious decision async fn is_kickoff_malicious( &self, kickoff_witness: Witness, deposit_data: &mut DepositData, kickoff_data: KickoffData, dbtx: Option>, ) -> Result { // ← No Option for "uncertain" state // Architecture prevents graceful degradation during database issues // Must return true (malicious) or false (legitimate) - no "unknown" option } ``` **Attack Surface Analysis - Code Evidence:** - **Single Failure Point**: One database error triggers economic consequences - **Shared Resources**: Connection pool contention amplifies failure probability - **No Error Recovery**: Zero retry or fallback mechanisms implemented - **Binary Logic**: Cannot defer decisions during operational issues - **High Economic Impact**: Challenge transactions impose immediate costs on false positives ## Proof of Concept **Vulnerability Execution Path:** **Phase 1: Database DoS Attack Setup** ```rust // core/src/database/mod.rs:38 - Shared connection pool architecture pub struct Database { connection: Pool, // ← Single shared connection pool } // core/src/database/mod.rs:78-92 - Pool configuration and limits let opts = sqlx::postgres::PgPoolOptions::new().acquire_slow_level(log::LevelFilter::Debug); #[cfg(test)] let opts = if config.test_params.timeout_params.any_timeout() { // increase timeout for pool connections beyond any other to avoid flakiness opts.acquire_timeout(Duration::from_secs(10000)) .acquire_slow_threshold(Duration::from_secs(10000)) } else { opts }; let connection = opts .connect_with(opt) .await .map_err(BridgeError::DatabaseError)?; // Attack: Flood database with connections → exhaust Pool → legitimate queries fail // Target: Single shared connection pool serves all fraud detection calls // Result: Legitimate fraud detection queries return BridgeError::DatabaseError(sqlx::Error) ``` **Phase 2: Legitimate Kickoff Processing** ```rust // core/src/verifier.rs:1544-1554 async fn is_kickoff_malicious( &self, kickoff_witness: Witness, deposit_data: &mut DepositData, kickoff_data: KickoffData, dbtx: Option>, ) -> Result { let move_txid = create_move_to_vault_txhandler(deposit_data, self.config.protocol_paramset())? .get_cached_tx() .compute_txid(); // Legitimate operator initiates valid withdrawal ``` **Phase 3: Database Query Failure Due to Attack** ```rust // core/src/verifier.rs:1555-1558 let payout_info = self .db .get_payout_info_from_move_txid(dbtx, move_txid) // ← Query fails due to DoS .await; // Database returns: Err(BridgeError::DatabaseError(sqlx::Error)) ``` **Phase 4: False Malicious Classification** ```rust // core/src/verifier.rs:1559-1565 if let Err(e) = &payout_info { // ← Database error caught here tracing::warn!( "Couldn't retrieve payout info from db {}, assuming malicious", e // ← Logs "DatabaseError(sqlx::Error)" but assumes fraud ); return Ok(true); // ← Innocent operator classified as malicious } ``` **Phase 5: Economic Penalty Execution** ```rust // Fraud detection returns true → triggers challenge transaction creation // Innocent operator faces: // 1. Challenge transaction fees // 2. Transaction costs and operational burden // 3. Reputation damage // 4. Potential exclusion from future operations ``` ## Recommendation Consider evaluating database resilience patterns to mitigate false positive fraud detection during operational database issues. **Core Issue:** The current implementation at `core/src/verifier.rs:1559-1565` treats any database error as evidence of malicious behavior, creating a potential economic attack vector. **Areas for Consideration:** 1. **Error Classification**: Evaluate distinguishing between transient database issues and actual fraud indicators 2. **Graceful Degradation**: Consider deferring fraud detection decisions during database unavailability rather than assuming malicious behavior 3. **Retry Mechanisms**: Assess implementing basic retry logic for transient database failures **Potential Approaches:** - **Conservative Policy**: During database uncertainty, consider avoiding challenge transactions against potentially innocent operators - **Operational Resilience**: Evaluate retry mechanisms for common transient database failures (connection timeouts, pool exhaustion) - **Observability**: Consider adding monitoring for deferred fraud detection decisions - **Configuration Flexibility**: Assess making retry parameters and fallback behavior configurable **Alternative Mitigation Strategies:** - **Cached Validation**: Evaluate caching recent payout validations to reduce database dependency - **Deferred Processing**: Consider queueing uncertain cases for later validation when database connectivity is restored - **Circuit Breaker Pattern**: Assess temporarily deferring strict fraud detection during widespread database issues **Current Implementation Pattern:** The existing error handling immediately classifies any database error as malicious: ```rust // core/src/verifier.rs:1559-1565 - Current implementation if let Err(e) = &payout_info { tracing::warn!( "Couldn't retrieve payout info from db {}, assuming malicious", e ); return Ok(true); // ← Any database error = malicious } ``` **Potential Error Handling Considerations:** The current pattern could be enhanced to differentiate error types: ```rust // Potential approach for error classification match payout_info { Ok(data) => { // Continue with existing fraud detection logic }, Err(BridgeError::DatabaseError(_)) => { // Consider: Could this be a transient database issue? // Option: Log as "database unavailable" instead of "malicious" // Option: Return a different result indicating uncertainty tracing::warn!("Database unavailable for fraud detection, deferring decision"); // Consider: return Ok(false) or implement uncertainty handling }, Err(other) => { // Handle other error types as appropriate } } ``` **Additional Pattern Considerations:** Similar patterns exist for missing data that might benefit from review: ```rust // core/src/verifier.rs:1567-1570 - Current pattern let Some((operator_xonly_pk_opt, payout_blockhash, _, _)) = payout_info else { tracing::warn!("No payout info found in db, assuming malicious"); return Ok(true); // ← Missing data = malicious }; ``` **Consideration**: Evaluate whether missing data should always indicate malicious behavior, or if there are legitimate scenarios where data might not be available (e.g., during database synchronization, new deposits, etc.).

Competition	Date	Submissions	Payout
Citrea	Aug 11, 2025	1	$0
Kuru Labs	Aug 18, 2025	1	$0
Ammalgam	Jul 9, 2025	1	$115
Genius Foundation	Jul 2, 2025	1	$31

ATrnd

Public reviews