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

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.