Bentornati al Vulnerability Spotlight di Sherlock, dove mettiamo in evidenza una vulnerabilità significativa scoperta durante un audit di Sherlock. Questa settimana, esaminiamo un attacco di negazione del servizio trovato nel contest di @GMX_IO da @0xdeadbeef____ e @IllIllI000. Crediti a @int0x1catedCode per l'analisi.

Riepilogo della vulnerabilità: La vulnerabilità consente a un attaccante di manipolare il flusso di esecuzione degli ordini fornendo lunghezze di motivazione di annullamento false che non corrispondono ai dati reali. Ciò provoca che la gestione degli errori del protocollo legga regioni di memoria errate, potenzialmente interrompendo il processo di esecuzione o causando comportamenti imprevisti durante l'elaborazione degli ordini falliti.

Passaggi dell'attacco: 1. Fase di configurazione Distribuire un contratto malevolo che implementa un comportamento di revert personalizzato. Il contratto malevolo dovrebbe essere invocabile dal protocollo target (ad esempio, come gestore di callback). 2. Creare dati di revert malevoli Strutturare i dati di revert con un parametro di lunghezza falsificato. 3. Eseguire l'ordine tramite il protocollo Creare un ordine che attiverà l'interazione con il contratto malevolo. Quando il protocollo elabora l'ordine e chiama il contratto malevolo, esso effettua un revert con i dati creati. La gestione degli errori del protocollo tenta di decodificare il motivo del revert utilizzando la lunghezza falsa. 4. Attivare un overflow di lettura della memoria Il protocollo legge la memoria in base al parametro di lunghezza falsa. Questo causa la lettura oltre i confini reali dei dati di revert.

Qual è l'impatto? Negazione del servizio: Gli ordini possono non essere eseguiti correttamente, bloccando operazioni legittime del protocollo come la liquidazione di posizioni sfavorevoli. Interruzione dell'esecuzione degli ordini: L'elaborazione degli ordini in batch può essere interrotta, influenzando più utenti. Gas griefing: L'elaborazione di dati di revert malformati può consumare gas eccessivo.

La causa principale: 1. Parametri di lunghezza non controllati: Il protocollo si fida del valore di lunghezza fornito nei dati di revert senza convalida 2. Mancanza di controlli sui limiti: Nessuna verifica che la lunghezza dichiarata corrisponda alla dimensione effettiva dei dati

La Mitigazione: 1. Valida sempre la lunghezza dei dati di Revert 2. Implementa limiti di lunghezza massima

Siamo orgogliosi di aver contribuito a garantire la sicurezza di @GMX_IO grazie a questa scoperta. Quando è assolutamente necessario essere sicuri, Sherlock è la scelta giusta.