Vai al contenuto
Financial Context Wiki

Rischio della firma Permit2

Permit2 separa le allowance riutilizzabili dai trasferimenti una tantum autorizzati tramite firma; firmare in sicurezza richiede di verificare deployment, dominio, spender, destinatario, importo, nonce, scadenza, witness e calldata di esecuzione.

Aggiornato

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

Risposta diretta

Permit2 riunisce due sistemi di autorizzazione distinti. AllowanceTransfer registra un’allowance riutilizzabile tra proprietario, token e spender, con importo, scadenza e nonce ordinato. SignatureTransfer consuma un massimale firmato una tantum mediante un nonce bitmap non ordinato e non crea alcuna allowance persistente a valle. Entrambi dipendono comunque dall’allowance ERC-20 concessa dal proprietario del token a Permit2.

Una firma senza gas a carico dell’utente può spostare asset quando uno spender o un relayer paga l’esecuzione. Occorre verificare esattamente chain, codice Permit2 distribuito, dominio EIP-712, modulo, token, spender, massimale firmato, calldata del destinatario, nonce e vincoli temporali. La legittimità del contratto Permit2 non rende sicuri uno spender, un destinatario, un router o un witness malevoli.

Rischio della firma Permit2
0 / 5
0 elementi recensiti; 5 elementi ancora irrisolti

Il completamento di questa revisione non dimostra che una risorsa, una transazione o un sistema siano sicuri.

Come funziona

  1. Fissare chainId, rete, verifyingContract di Permit2, codice runtime distribuito, indirizzo e decimali del token, tipo di wallet del proprietario e applicazione prevista. Usare un registro ufficiale dei deployment: un indirizzo o un’etichetta familiari non bastano.
  2. Leggere saldo e allowance ERC-20 a monte dal proprietario a Permit2. Distinguere un’approvazione finita da una illimitata e identificare il comportamento specifico del token nei trasferimenti; questo registro sopravvive alla scadenza di una firma Permit2 o di un’allowance a valle memorizzata.
  3. Identificare il percorso e il tipo primario firmato: PermitSingle o PermitBatch per AllowanceTransfer, oppure PermitTransferFrom o le varianti batch e witness per SignatureTransfer. Non confondere transferFrom con il tipo firmato.
  4. Decodificare il dominio EIP-712 e ogni voce del messaggio. Per AllowanceTransfer verificare token, uint160 amount, expiration, nonce ordinato, spender e sigDeadline. Per SignatureTransfer verificare token e importo consentiti, nonce non ordinato, scadenza e spender vincolato dal contesto del chiamante.
  5. Decodificare separatamente la calldata di esecuzione. Nel SignatureTransfer di base, SignatureTransferDetails.to e requestedAmount sono parametri di esecuzione, non campi del permesso firmato di base; l’importo richiesto deve soltanto restare entro il massimale firmato. Verificare ogni indice del batch e, se presente, l’hash del witness e la stringa di tipo esatti.
  6. Interrogare il nonce corrente dell’allowance ordinata oppure parola e bit della bitmap non ordinata, quindi simulare chiamante, calldata, chain e stato esatti. Riconciliare destinatario, azioni del router, peculiarità del token, saldo ed entrambi i registri delle allowance; la simulazione può divergere per stato, ordinamento o riorganizzazione.
  7. Ridurre al minimo importi e durate. In caso di sospetto, conservare i dati tipizzati e inviare, tramite un percorso fidato, la revoca corretta dell’approvazione a monte, dell’allowance a valle o l’invalidazione del nonce, trattandola come una corsa nel mempool; attendere la conferma e riconciliare trasferimenti, saldi, allowance e bit della bitmap.

Il sigDeadline di AllowanceTransfer limita il momento entro cui il permesso firmato può creare o aggiornare l’autorità memorizzata; expiration limita il periodo in cui tale autorità può essere spesa. La deadline di SignatureTransfer limita la sua esecuzione una tantum. EIP-712 fornisce hashing tipizzato e separazione del dominio, non protezione dal replay né sicurezza dell’intento: questi limiti dipendono dalle regole di nonce e scadenza di Permit2.

Per un wallet contrattuale, la validità ERC-1271 dipende dalla politica isValidSignature corrente, dai moduli, dalle soglie e dal codice del wallet. Etichette del wallet, schermate abbreviate di un hardware wallet e simulazioni riuscite sono elementi informativi, non garanzie. Disconnettere un frontend non revoca alcuna approvazione o firma.

Esempio

  • Due registri di allowance. L’allowance finita del token verso Permit2 parte da 1,000 USDC; un PermitSingle registra 600 USDC per lo spender S. Dopo il trasferimento di 225 USDC da parte di S, l’importo memorizzato è 600 - 225 = 375 USDC, mentre una normale allowance finita a monte diventa 1,000 - 225 = 775 USDC. La scadenza o revoca di 375 non azzera automaticamente 775; token non standard possono comportarsi diversamente.
  • Destinatario e importo una tantum. Un SignatureTransfer firma un massimale di 250 USDC; la calldata richiede 180 USDC a favore di un esercente. Se saldo e allowance a monte sono sufficienti, l’esecuzione può trasferire 180. Il nonce viene consumato, quindi i 70 USDC inutilizzati non sono riutilizzabili. Se la calldata indica come destinatario un attaccante, il permesso di base da solo non impedisce allo spender vincolato di reindirizzare il trasferimento.
  • Bitmap dei nonce non ordinati. Per il nonce 513, wordPos = 513 >> 8 = 2, bitPos = 513 & 255 = 1 e mask = 1 << 1 = 2. L’esecuzione imposta il bit 1 della parola 2; il replay di 513 fallisce, mentre il nonce 512, associato al bit 0, resta indipendente.
  • Corsa alla revoca. Un’allowance memorizzata è pari a 400 USDC. Il proprietario trasmette una revoca a zero, ma prima viene eseguito un trasferimento di 300 USDC, che lascia 100 USDC; la revoca successiva porta il residuo a 0. Un saldo finale dell’allowance pari a zero non annulla la perdita realizzata di 300 USDC: occorre riconciliare ordinamento delle transazioni e saldi.

Rischi

  • Chain ID, deployment o codice runtime errati
  • Contratto di verifica contraffatto o inatteso
  • Confusione tra AllowanceTransfer e SignatureTransfer
  • Spender o chiamante malevolo oppure indicato per errore
  • Destinatario scelto tramite la calldata di esecuzione
  • Importo richiesto prossimo al massimale firmato
  • Indirizzo, simbolo, decimali o unità raw del token errati
  • Approvazione ERC-20 a monte persistente o illimitata
  • Importo o scadenza a valle eccessivi
  • Confusione tra deadline, signature deadline ed expiration
  • Nonce ordinato obsoleto o oggetto di una corsa
  • Bit della bitmap riutilizzato o maschera di invalidazione troppo ampia
  • Hash del witness o stringa di tipo esatta non corrispondenti
  • Voce batch nascosta, duplicata o con indice errato
  • Differenza tra quanto mostra il frontend, la calldata e l’intento
  • Revoca battuta in una corsa nel mempool o da MEV
  • Modifica di modulo, firmatario, soglia o upgrade ERC-1271
  • Token con commissione sul trasferimento, rebasing, pausa, blocco o callback
  • Deriva dello stato simulato, errore di simulazione o riorganizzazione
  • Conferma su hardware wallet o disconnessione scambiate per sicurezza

Idee sbagliate comuni

  • Una firma senza richiesta di gas non può spostare token. Un’altra parte può pagare il gas dell’esecuzione.
  • L’indirizzo Permit2 ufficiale dimostra che spender e destinatario sono sicuri. Permit2 può eseguire fedelmente un’autorità malevola.
  • SignatureTransfer e AllowanceTransfer creano la stessa autorizzazione persistente. Il primo è monouso; il secondo memorizza un’allowance riutilizzabile.
  • Disconnettersi o revocare un livello annulla ogni percorso e firma in sospeso. Stato a monte, stato a valle e nonce sono separati e le corse restano possibili.
  • EIP-712, un hardware wallet o una simulazione riuscita dimostrano intento e finalità. Migliorano visibilità o test, ma non sostituiscono la verifica di campi, calldata e stato confermato.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...