Solana corregge silenziosamente un bug che avrebbe potuto consentire agli aggressori di coniare e rubare determinati token

Un aggressore esperto avrebbe potuto falsificare prove non valide che il verificatore on-chain avrebbe comunque accettato. Ciò avrebbe consentito azioni non autorizzate come la creazione di token illimitati o il prelievo di token da altri account.

La Fondazione Solana ha rivelato una vulnerabilità precedentemente sconosciuta nel suo sistema di token incentrato sulla privacy che avrebbe potuto consentire agli aggressori di creare false prove a conoscenza zero, consentendo la coniazione o il prelievo non autorizzato di token.

La vulnerabilità è stata segnalata per la prima volta il 16 aprile tramite l'avviso di sicurezza di Anza su GitHub, accompagnato da una proof-of-concept funzionante. Gli ingegneri dei team di sviluppo Solana, Anza, Firedancer e Jito, hanno verificato il bug e hanno iniziato a lavorare immediatamente alla correzione, come riportato in un'autopsia. pubblicato sabato,

Il problema nasce dal programma ZK ElGamal Proof, che verifica le prove a conoscenza zero (ZKP) utilizzate nei trasferimenti riservati Token-22 di Solana. Questi token di estensione consentono la gestione di saldi e trasferimenti privati crittografando gli importi e utilizzando prove crittografiche per convalidarli.

Le ZKP sono un metodo crittografico che consente a qualcuno di dimostrare di conoscere o avere accesso a qualcosa, come una password o l'età, senza rivelare l'oggetto stesso.

Nelle applicazioni Cripto , possono essere utilizzati per dimostrare la validità di una transazione senza mostrare importi o indirizzi specifici (che potrebbero altrimenti essere sfruttati da malintenzionati per pianificare exploit).

Il bug si è verificato perché alcuni componenti algebrici mancavano nel processo di hashing durante la trasformazione Fiat-Shamir, un metodo standard per rendere non interattive le dimostrazioni a conoscenza zero. (Non interattivo significa trasformare un processo di andata e ritorno in una dimostrazione una tantum verificabile da chiunque.)

Un aggressore esperto potrebbe creare prove non valide che il verificatore on-chain accetterebbe comunque.

Ciò avrebbe consentito azioni non autorizzate, come la creazione di un numero illimitato di token o il prelievo di token da altri account.

Pertanto, la vulnerabilità non ha interessato i token SPL standard né la logica principale del programma Token-2022.

Le patch sono state distribuite privatamente agli operatori dei validatori a partire dal 17 aprile. Una seconda patch è stata distribuita più tardi quella sera per risolvere un problema correlato in un'altra parte del codice base.

Entrambe sono state esaminate dalle società di sicurezza terze Asymmetric Research, Neodyme e OtterSec. Entro il 18 aprile, la maggioranza dei validatori aveva adottato la correzione.

Secondo l'autopsia, non ci sono indicazioni che il bug sia stato sfruttato e tutti i fondi restano al sicuro.