Philip DiSarro segnala due vulnerabilità critiche nell’implementazione CIP-113 di Aiken

Philip DiSarro, fondatore e CEO di Anastasia Labs e autore di CIP-143, ha dichiarato il 24 luglio di aver identificato due vulnerabilità critiche durante la revisione dell’implementazione Aiken del framework di token programmabili CIP-113 di Cardano. Nello stesso thread ha pubblicato benchmark aggiornati che confrontano il codebase di Aiken con l’implementazione Plutarch originale sviluppata da DiSarro e dal team di Input Output. La divulgazione arriva mentre CIP-113 rimane nella fase Last Check e la sua implementazione prosegue con la revisione di sicurezza.

Plutarch registra costi inferiori nei benchmark di CIP-113

Il file di benchmark pubblicato confronta le due implementazioni rispetto al budget massimo di transazione di Cardano pari a 10 miliardi di unità CPU e 14 milioni di unità di memoria. Sia Aiken sia Plutarch infine compilano in Untyped Plutus Core, il codice eseguito dai nodi di Cardano.

Plutarch ha registrato un consumo totale di CPU e memoria inferiore in ciascuno dei cinque scenari evidenziati.

Nel test di trasferimento standard, Aiken ha utilizzato 1.19 volte più CPU e 1.17 volte più memoria rispetto a Plutarch. La differenza maggiore tra gli scenari mostrati è emersa nel test che combina un’azione di sequestro, uno script esterno e 50 input a chiave pubblica, dove Aiken ha consumato 3.23 volte più CPU e 2.36 volte più memoria.

Entrambe le implementazioni sono rimaste entro i limiti di transazione di Cardano nel test 16-swap $NIGHT DEX. Plutarch ha utilizzato il 6.66% del budget CPU disponibile e l’11.68% del budget di memoria, contro il 7.59% e il 15.25% per Aiken.

La pubblicazione di DiSarro ha incluso anche proiezioni lineari su quanti elementi possano rientrare in una singola transazione. Le stime collocavano Plutarch a 658 input rispetto a 162 per Aiken, 472 output rispetto a 334, 36,489 token rispetto a 1,661 e 527 policy rispetto a 160. Questi valori sono proiezioni della capacità degli script derivate dai costi di esecuzione testati e non dalla capacità di throughput misurata su mainnet.

Il confronto degli script compilati ha prodotto script Plutarch più piccoli in sei delle sette categorie. Lo script directoryNodeSpending misurava 331 byte in Plutarch e 1,698 byte in Aiken. L’eccezione è stata programmableLogicGlobal, dove Aiken ha prodotto uno script da 3,157 byte rispetto a 3,437 byte per Plutarch.

CIP-113 aggiunge regole programmabili agli asset nativi di Cardano

CIP-113 propone un framework per aggiungere regole di validazione programmabili agli asset nativi di Cardano senza richiedere una modifica del registro o un hard fork. Gli emittenti potrebbero definire condizioni che si eseguono durante i trasferimenti di token, il minting e il burning.

Le regole possono includere allowlist, denylist, restrizioni ai trasferimenti, time lock e funzioni opzionali di congelamento o sequestro. Il framework è pensato per stablecoin, titoli tokenizzati e asset del mondo reale che richiedono controlli sulla proprietà e sul movimento.

Nell’architettura proposta, i token programmabili sono detenuti su un indirizzo di smart contract condiviso, mentre la proprietà è rappresentata tramite stake credentials. Un registro on chain collega ogni token policy alle sue regole di trasferimento, alla logica di emissione e a eventuali controlli di terze parti autorizzate.

I wallet dovrebbero risolvere le stake credentials per visualizzare correttamente i saldi. Anche gli exchange decentralizzati, gli indexer, gli explorer e altre applicazioni dovrebbero supportare il processo di validazione aggiuntivo prima che gli utenti possano interagire con token programmabili tramite l’infrastruttura Cardano esistente.

Aiken e Plutarch offrono approcci di sviluppo differenti pur compilando nello stesso formato di codice on chain. La documentazione per sviluppatori di Cardano presenta Aiken come un punto di partenza accessibile con test integrati e una sintassi dedicata. Plutarch è un linguaggio embedded basato su Haskell che offre agli sviluppatori un controllo più dettagliato sul codice generato e sui costi di esecuzione.

DiSarro ha scritto CIP-143, Interoperable Programmable Tokens e ha collaborato con il team di Input Output alla sua implementazione di riferimento Plutarch originale. Il repository della Cardano Foundation afferma che gli attuali validator di Aiken sono stati migrati da tale implementazione e adattati al più ampio framework CIP-113.

Il suo coinvolgimento diretto nell’architettura e nella base di codice originali colloca il nuovo confronto dei benchmark nella storia di sviluppo del progetto. CIP-143 è ora contrassegnata come inattiva dopo essere stata incorporata nella candidata CIP-113, che rimane nella fase di revisione Last Check degli editor CIP.

Due vulnerabilità segnalate attendono la divulgazione tecnica

DiSarro ha affermato che la sua revisione dell’implementazione Aiken ha portato alla luce due vulnerabilità critiche sfuggite durante il processo di audit. Il suo thread non ha identificato il codice interessato, i possibili percorsi di attacco, l’impatto potenziale o lo stato della correzione.

Il repository contiene già risultati pubblici dell’audit iniziale, tra cui due issue chiuse etichettate come critiche. Issue 56 descriveva un percorso attraverso il quale i token appena coniati potevano sfuggire alla custodia programmabile durante un’azione di terze parti. Issue 64 affrontava la possibile contaminazione di UTxO non correlati tramite la stessa funzione amministrativa.

Tali risultati sono stati riportati durante l’audit iniziale e non possono essere identificati come le due vulnerabilità che DiSarro ha riferito di aver trovato in seguito senza un’ulteriore divulgazione tecnica.

Preoccupazioni sulla sicurezza sono state sollevate anche nella discussione di revisione di CIP-113. Un contributore ha affermato il 20 luglio che erano state tralasciate più vulnerabilità ad alta gravità e che alcune modifiche proposte all’usabilità introducevano ulteriori problemi di sicurezza. Durante la successiva revisione CIP, i partecipanti hanno concordato che il passo successivo dovrebbe includere un audit più completo mentre la proposta rimane a Last Check.

Il repository della Cardano Foundation afferma che i risultati dell’audit iniziale e di un successivo re audit sono stati corretti sulla branch principale. Tuttavia, il rapporto finale di audit rimane non pubblicato e il repository designa l’implementazione come non adatta all’uso in produzione con asset reali finché non saranno completati il rapporto, test più ampi e ulteriori revisioni da parte di esperti.

Prima che l’implementazione di CIP-113 possa avanzare verso distribuzioni con asset reali, restano in sospeso tre risultati concreti: la pubblicazione del rapporto finale di audit, la divulgazione e la correzione delle due vulnerabilità segnalate da DiSarro e il completamento della più ampia revisione di sicurezza richiesta durante il processo CIP. Tali risultati definiranno quali modifiche al codice e alle specifiche saranno incorporate prima che la proposta venga integrata e l’implementazione sia considerata per l’uso in produzione.