CVE-2024-24563 in Vyper
Riassunto
di VulDB • 29/06/2026
Vyper è un linguaggio di smart contract in stile Python per la Ethereum Virtual Machine. Gli array possono essere indicizzati tramite un intero con segno (signed integer), sebbene siano definiti esclusivamente per interi senza segno (unsigned integers). Il typechecker non genera errori quando rileva l'utilizzo di `int` come indice per un array; consente infatti l'uso di interi con segno come indici degli array. La vulnerabilità è presente in diverse forme in tutte le versioni, incluse la 0.3.10 e successive. Per gli interi viene utilizzata la rappresentazione a complemento a due (2's complement). Poiché l'array era dichiarato molto grande, il controllo dei limiti supererà i valori negativi: questi verranno semplicemente interpretati come numeri molto grandi. Al momento della pubblicazione, non esiste una versione corretta del software.
Esistono tre possibili classi di vulnerabilità: comportamento imprevedibile, accesso a elementi inaccessibili e denial of service (DoS). Classe 1: Se è possibile indicizzare un array con un intero negativo senza causare il revert dell'operazione, ciò molto probabilmente non era previsto dallo sviluppatore e tali accessi possono comportare comportamenti imprevedibili per lo smart contract. Classe 2: Se uno smart contract prevede una condizione invariante nella forma `assert index = x`, questa dovrebbe essere accessibile solo tramite indici validi; tuttavia, l'uso di indici negativi può aggirare tale controllo. Classe 3: Se l'indice dipende dallo stato dello smart contract, ciò comporta un rischio di denial of service. Se lo stato del contratto può essere manipolato in modo da forzare l'indice a diventare negativo, l'accesso all'array andrà sempre incontro a revert (poiché molto probabilmente l'array non è dichiarato estremamente grande). Tuttavia, tutti questi scenari sono altamente improbabili; il comportamento più probabile rimane un revert durante il controllo dei limiti dell'array.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.