Vai al contenuto
Financial Context Wiki

Rischio dei moduli multifirma: quali autorizzazioni aggirano la soglia?

Un modulo abilitato può eseguire operazioni da un conto multifirma senza raccogliere la normale soglia dei proprietari. Scopri come verificare moduli, Guard, Fallback Handler, aggiornamenti e percorsi di recupero.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Un modulo abilitato è un percorso di autorizzazione separato. Nei conti intelligenti in stile Safe, un modulo approvato può chiamare execTransactionFromModule ed eseguire un CALL o DELEGATECALL senza raccogliere per quell’azione le normali firme M-su-N dei proprietari. La soglia visualizzata descrive quindi un solo percorso di esecuzione, non l’intero confine di sicurezza del conto.

I moduli permettono automazioni utili come limiti di spesa, pagamenti ricorrenti, recupero e operazioni di protocollo. La loro autorità può però essere ampia: il contratto Safe ufficiale descrive i moduli abilitati come capaci di eseguire transazioni arbitrarie e avverte che un modulo dannoso può prendere il controllo di un Safe. Verifica ogni modulo abilitato, non solo proprietari e soglia.

Come funziona

I proprietari autorizzano prima enableModule con una normale transazione Safe. Il conto registra il modulo tra quelli abilitati. In seguito, il modulo convalida autonomamente chiamante e regole, quindi chiama execTransactionFromModule; il conto verifica che il chiamante sia abilitato ed esegue l’operazione richiesta. La sicurezza dipende ora anche da codice, configurazione, amministratori, chiavi di aggiornamento e dipendenze esterne del modulo.

Un Guard di transazione e un Module Guard sono controlli distinti. Il primo verifica le normali chiamate execTransaction, il secondo quelle avviate dai moduli. Un Guard può rifiutare l’esecuzione, ma uno difettoso o troppo restrittivo può anche causare un’interruzione del servizio. Accerta quale tipo è installato, cosa controlla e come recuperarlo o rimuoverlo.

Un Fallback Handler è un altro punto di estensione. Quando calldata non corrisponde a una funzione principale del conto, questo inoltra la chiamata all’Handler configurato e aggiunge l’indirizzo del chiamante originale. Gli Handler possono aggiungere convalida delle firme e callback dei token, ma una logica o configurazione insicura crea un’ulteriore superficie di autorizzazione e interpretazione.

Esempio

Una tesoreria usa una soglia dei proprietari 3-of-5 e abilita un modulo di indennità per i pagamenti ordinari. Il modulo è aggiornabile e il suo amministratore di aggiornamento è un solo hot wallet. Se la chiave viene compromessa, un aggressore può aggiornare il modulo, usare il percorso di esecuzione modulare e trasferire attività senza ottenere 3 firme. La soglia 3-of-5 resta intatta, ma non governa questo percorso.

La verifica deve identificare indirizzo e implementazione verificata del modulo, proxy e amministratore, limiti di spesa, destinazioni e selettori consentiti, se DELEGATECALL è ammesso, il Module Guard installato, il Fallback Handler e la transazione esatta per disabilitare il modulo. Controlla questi valori nei contratti del conto e dei proxy su ogni catena, non solo nell’interfaccia del wallet.

Rischi

  • Rischio di autorità: Un modulo vulnerabile o dannoso può trasferire attività, approvare spenditori, cambiare lo stato tramite DELEGATECALL o invocare altri contratti privilegiati. Un’interfaccia limitata non dimostra un’autorità on-chain limitata.
  • Rischio di controllo e aggiornamento: Proxy, amministratore, oracolo, esecutore automatico o chiave di recupero possono ridurre una struttura apparente 3-of-5 a un insieme di controllo effettivo più piccolo. Segui ogni percorso di aggiornamento e configurazione fino ai firmatari finali e ai ritardi.
  • Rischio di disponibilità: Un Guard difettoso può bloccare transazioni valide, mentre un modulo compromesso può agire prima che i proprietari ne coordinino la rimozione. Prova disabilitazione e recupero, monitora modifiche a moduli, Guard e Handler e conserva un percorso di risposta indipendente dal componente da rimuovere.

Errori comuni

  • Errore 1: “Il conto è 3-of-5, quindi ogni trasferimento richiede 3 firme.” La soglia vale per il percorso normale autorizzato dai proprietari; i moduli abilitati possono avere una politica diversa.
  • Errore 2: “Un Guard protegge ogni percorso di esecuzione.” Guard di transazione e Module Guard coprono punti di ingresso diversi; la copertura dipende dal contratto installato e dalle sue regole.
  • Errore 3: “Rimuovere il modulo dall’interfaccia elimina il rischio.” Verifica su ogni catena il registro dei moduli abilitati, lo storage di Handler e Guard, l’implementazione del proxy e le transazioni di modifica eseguite.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...