di Aptos Labs e OtterSec

La rete Aptos utilizza il linguaggio del contratto intelligente Move come modello di programmazione sottostante. Sebbene Move sia progettato per un ecosistema di contratti intelligenti sicuri, un'implementazione errata di Move stesso può mettere a repentaglio tali proprietà. In Aptos Labs, ci impegniamo a rendere Move il più sicuro possibile, insieme alla community. Stiamo investendo sia in strumenti per la scrittura di contratti intelligenti corretti (ad esempio il Move Prover, sviluppato prevalentemente da Aptos), sia nella correttezza dei componenti core di runtime come la Move Virtual Machine. In questo articolo descriviamo come, insieme ai nostri partner, raggiungiamo quest'ultimo tramite auditing, bug bounty, fuzzing e rafforzamento della sicurezza dell'implementazione sottostante.

Cosa stiamo mettendo in sicurezza?

La sicurezza di Move si basa su alcune proprietà di base. Queste proprietà sono definite in termini di bytecode consumato dal motore di esecuzione di Move e sono indipendenti dalla lingua di origine:

• Sicurezza del tipo : ogni valore ha un tipo univoco e non falsificabile. Ad esempio, non è possibile prendere un valore di tipo "indirizzo" e trasformarlo in un token rilevante per la sicurezza di tipo "firmatario".
• Incapsulamento modulare : le risorse nell'archiviazione possono essere manipolate solo dal codice all'interno dei moduli che dichiarano tali risorse. Solo le funzioni con visibilità corrispondenti possono essere chiamate cross-module.
• Proprietà e durata : il sistema di abilità di Move impone che un valore non venga copiato, eliminato, archiviato o utilizzato come chiave a meno che l'abilità corrispondente non sia dichiarata per il tipo di valore.
• Sicurezza dei riferimenti : i riferimenti non sopravvivono ai valori a cui puntano. Un riferimento mutabile è di proprietà esclusiva, in modo tale che l'aliasing non sia possibile.

Di seguito le domande che ci interessano:

1. Il verificatore bytecode è completo e garantisce che tutte le proprietà di cui sopra siano soddisfatte per ogni programma? Questo è importante perché la violazione di una qualsiasi delle proprietà di cui sopra può potenzialmente comportare la perdita di beni.
2. Un dato programma Move bytecode può mandare in crash il motore di esecuzione? Poiché in una macchina a stati replicati tutti i nodi eseguono gli stessi programmi, questo può essere utilizzato per arrestare la rete.
3. Un dato programma può far sì che il motore di esecuzione esaurisca le risorse (memoria o tempo)? Questo può essere sfruttato per attacchi DoS che rallentano o sospendono la rete.

Al centro dello sviluppo di codice privo di bug ci sono pratiche di ingegneria del software disciplinate abbinate agli strumenti giusti. In Aptos, stiamo seguendo il rigoroso processo di revisione obbligatoria del codice e continui test e integrazione, combinati con le migliori pratiche dell'ecosistema Rust. Oltre a questi aspetti tradizionali, applichiamo anche le seguenti misurazioni per mantenere Move sicuro come è stato progettato per essere.

Revisione e consulenza

Una delle misurazioni più rispettate nel settore per acquisire fiducia nelle reti blockchain è l'auditing. In Aptos Labs, abbiamo incaricato Certik ( rapporto ) e Holburn di controllare la macchina virtuale Move. Sono state riscontrate molteplici criticità, una delle quali nella categoria sicurezza di tipo.

Oltre all'audit esterno, Aptos Labs ha guidato e organizzato uno sforzo di auditing della comunità, incentrato sul verificatore di bytecode . Gli ingegneri di Mysten Labs, Starcoin e società di auditing come MoveBit e OtterSec hanno collaborato con gli ingegneri di Aptos per questo sforzo, investendo circa 6 settimane di tempo di auditing. I risultati di ciò sono raccolti in questo foglio di calcolo , che fa riferimento a dozzine di documenti creati durante questo audit. Questo sforzo di auditing ha individuato e risolto diversi problemi prima che Aptos arrivasse su mainnet.

Ultimo, ma non meno importante, abbiamo una stretta collaborazione con OtterSec . Il team di OtterSec ha eseguito revisioni manuali del codice e sviluppato una tecnologia di fuzzing per vari obiettivi, identificando molteplici problemi critici sia nel codice del framework Move VM che in Aptos. Hanno anche guidato gli sforzi per aggiungere una logica ridondante di difesa in profondità alla Move VM (vedi sotto), influenzando il nostro lavoro di progettazione in corso per mitigare ulteriori perdite di vulnerabilità dei fondi.

Taglia bug

Aptos Labs esegue un programma di bug bounty . Per bug critici del tipo che possono portare alla perdita di beni, vengono offerti premi fino a $ 1.000.000. Allo stesso modo, i crash bug possono essere ricompensati con un massimo di $ 100.000.

Con il programma bounty, abbiamo lavorato a stretto contatto con un talentuoso gruppo di ricercatori di sicurezza per trovare e correggere i bug. Alcuni di questi bug erano nella categoria critica, mentre altri bug sono stati rilevati in crash utilizzando fuzzers.

Aptos Labs ha mantenuto i suoi impegni in merito alle ricompense per i bug e sono state pagate ricompense significative. Inoltre, Aptos Labs ha continuato a utilizzare l'esperienza dei whitehat che abbiamo incontrato tramite il programma di taglie e intende continuare a lavorare insieme a questa comunità.

Fuzzing

Il programma bounty ci ha motivato a investire noi stessi nel fuzzing presso Aptos Labs. Il codice Move VM è stato modificato per implementare il tratto fuzzing "Arbitrary" Rust nei punti rilevanti, consentendo così l'uso di "cargo fuzz" per generare e convalidare dinamicamente moduli bytecode. Abbiamo alcuni lavori continui in esecuzione con questi obiettivi fuzzing.

Ridondanza

Un modo per ottenere un'ulteriore garanzia di sicurezza è tramite la ridondanza. Abbiamo aggiunto una cosiddetta modalità paranoica alla Move VM, che applica l'indipendenza dai tipi e le altre regole sopra menzionate al momento dell'esecuzione. Mentre il verificatore bytecode controlla già tali proprietà quando il codice entra nel sistema, la modalità paranoica verifica nuovamente gli stessi controlli durante il tempo di esecuzione del bytecode. La modalità paranoica è stata ampiamente discussa all'interno della comunità di Move, con gli ingegneri di Aptos alla guida del progetto. Per ulteriori informazioni vedere questo PR (versione finale) e questo PR (versione intermedia).

Qual è il prossimo?

In Aptos Labs, ci impegniamo a rendere Move il più sicuro possibile e abbiamo investito molto in quest'area. Qui abbiamo descritto gli sforzi in corso in materia di auditing, bug bounty, fuzzing e hardening condotti da noi e dai nostri partner. Andando avanti, prevediamo di continuare a investire in questo spazio. Continueremo a offrire un programma di bug bounty, coinvolgeremo revisori della sicurezza affidabili e guideremo lo sviluppo di strumenti per rafforzare la sicurezza, ad esempio la tecnologia fuzzing.