Rapporto di audit del contratto intelligente per 1 pollice

Sommario di gestione

1inch ha contattato Sayfer per eseguire un audit di sicurezza sul proprio contratto intelligente.

Questo rapporto documenta la ricerca condotta da Sayfer mirata alle risorse selezionate definite nell'ambito della ricerca. In particolare, questo rapporto mostra la revisione della posizione di sicurezza per il contratto intelligente di 1 pollice. Abbiamo applicato una combinazione di strumenti di ispezione manuale e di scansione automatizzata

Durante il periodo di ricerca di 15 giorni di audit, abbiamo scoperto 3 vulnerabilità e 1 nota informativa nel contratto sottoposto a audit.
Nessuno di questi risultati è considerato critico, il contratto può essere implementato così com'è. Tutti i risultati sono stati indirizzati e corretti dal team di 1inch.

Metodologia del rischio

Noi di Sayfer ci impegniamo a fornire ai nostri clienti audit di contratti intelligenti della massima qualità. Ecco perché abbiamo implementato un modello completo di valutazione del rischio per valutare la gravità dei nostri risultati e fornire ai nostri clienti le migliori raccomandazioni possibili per la mitigazione.

Il nostro modello di valutazione del rischio si basa su due fattori chiave: IMPATTO ed PROBABILITÀ. L'impatto si riferisce al danno potenziale che potrebbe derivare da un problema, come una perdita finanziaria, un danno alla reputazione o un sistema non operativo. La probabilità si riferisce alla probabilità che si verifichi un problema, tenendo conto di fattori quali la complessità del contratto e il numero di potenziali aggressori.

Combinando questi due fattori, possiamo creare una comprensione completa del rischio posto da un particolare problema e fornire ai nostri clienti una valutazione chiara e attuabile della gravità del problema. Questo approccio ci consente di dare priorità alle nostre raccomandazioni e garantire che i nostri clienti ricevano la migliore consulenza possibile su come proteggere i loro contratti intelligenti.

Il rischio è definito come segue:

Panoramica del protocollo

1 pollice che migliora l'efficienza delle operazioni all'interno dell'ambiente blockchain Layer 2. Dato che le operazioni con dati di chiamata più grandi tendono ad essere più costose nel Livello 2, l’obiettivo centrale è ridurre la dimensione dei dati di chiamata. Per raggiungere questo obiettivo, viene utilizzata una strategia di compressione dei dati di chiamata, questa strategia coinvolge principalmente operazioni fuori catena e utilizza un meccanismo denominato DecompressorExtension, che consente il recupero dei dati di chiamata compressi.

Per la compressione dei dati delle chiamate vengono utilizzate diverse tecniche chiave:

1. Compressione di byte zero consecutivi: questa tecnica riduce la dimensione complessiva dei dati di chiamata consolidando byte zero sequenziali in un formato più compatto.
2. Copia di byte consecutivi: in alcuni casi, la replica di byte sequenziali viene utilizzata come strategia di compressione dei dati.
3. Sostituzione basata su dizionario: vengono utilizzati due metodi distinti per sostituire un segmento dei dati di chiamata con un indice tratto da un dizionario predefinito, portando a una rappresentazione dei dati più efficiente.

Risultati dell'audit

Rischio di centralizzazione

Descrizione

Se l' _setData la funzione è esposta al proprietario del contratto, che sembra essere il modo previsto di utilizzare il contratto secondo il README, questo introduce un rischio di centralizzazione per ogni progetto che utilizza DecompressorExtension.

function _setData(uint256 offset, bytes32 data) internal
validDictAccess(offset) {
    unchecked {
        _dict[offset] = data;
    }
}

Un proprietario può eseguire front-run una chiamata da un utente e modificare il tasto dict corrispondente prima che la chiamata venga eseguita, il che gli consente di modificare arbitrariamente i dati della chiamata. Pertanto, diventa impossibile per un utente verificare i dati della chiamata (decompressi) prima di una chiamata.

La mutabilità delle voci dei dict significa anche che altri contratti intelligenti che chiamano decompress non possono memorizzare immutabili i dati di chiamata compressi, poiché la sua interpretazione potrebbe cambiare.

Mitigazione

Una soluzione a questo problema potrebbe essere quella di non consentire la modifica delle voci del dizionario esistenti, ma è necessaria una migliore comprensione delle esigenze e delle opzioni aziendali.

Nessuna implementazione di proprietà

Descrizione

Il README afferma più volte sull'implementazione Modulo possedibile OpenZeppelin. In realtà, il contratto non implementa né estende Owneable, il che potrebbe creare confusione e fuorviante per i proprietari del progetto.

Dal README:

This contract provides a `DecompressorExtension` abstract
contract that extends `Ownable` from the OpenZeppelin
library.

Ciò è pericoloso in quanto i proprietari del progetto potrebbero presumere che esista un meccanismo di controllo degli accessi, che non esiste.

Mitigazione

Implementa la funzionalità di proprietà ereditando da Ownable o aggiorna il file README per dichiarare che l'utente è colui che dovrebbe occuparsi del controllo degli accessi

Attacco DoS con gas

Descrizione

È molto semplice inviare input (brevi). decompress ciò si traduce in enormi dati di chiamata decompressi, cioè l'equivalente di a bomba zip.

Ad esempio, è possibile inviare molti 00111111 byte seguiti da altri dati utilizzando case 0, con conseguenti enormi costi di espansione della memoria:

case 0 {
    let size := add(byte(0, data), 1)
    calldatacopy(outptr, calldatasize(), size)
    inptr := add(inptr, 1)
    outptr := add(outptr, size)
    continue
}

Se l'utente effettua personalmente questa transazione, questo non è un problema, poiché spreca solo i propri fondi, da qui il basso rischio dato a questa scoperta.

Tuttavia, esistono alcuni scenari in cui ciò potrebbe consentire un attacco. Ad esempio, potremmo avere un contratto di relè che richiama un contratto intelligente in cui gli sviluppatori si prendono cura che l'utilizzo del gas di ogni funzione sia limitato. Se questo contratto intelligente ora inizia a utilizzare l'estensione, l'utilizzo del gas diventa illimitato, poiché il data la variabile è un input controllato dall'utente.

Mitigazione

Evitare questa vulnerabilità sarà difficile, è necessario comprendere meglio le esigenze aziendali.

Una soluzione è introdurre un limite di lunghezza opzionale per i dati delle chiamate decompressi, sebbene ciò potrebbe essere difficile/impossibile da impostare a seconda delle funzioni.
Oltre a questa soluzione tecnica, riteniamo che questa dovrebbe essere almeno documentata nel README o in un commento in linea.

Incompatibilità con transazioni ERC-2771/meta

Descrizione

L'estensione è incompatibile con lo standard ERC-2771 in cui il ripetitore aggiunge il mittente originale ai dati della chiamata (poiché ciò comporterebbe errori di compressione).

Questo non dovrebbe essere un grosso problema poiché i contratti supportano ancora le chiamate normali (non compresse), ma significa che la compressione non può essere utilizzata insieme alle meta transazioni.

La nostra ipotesi è che a un certo punto questo contratto diventerà un elemento fondamentale per altri protocolli, che questi protocolli potrebbero utilizzare ERC-2771, che quindi non funzionerebbe più quando si utilizzano dati di chiamata compressi.

Mitigazione

Se questo è rilevante, implementa ERC-2771