Solana непомітно виправляє помилку, яка могла дозволити зловмисникам карбувати та красти певні токени

Фонд Solana розкрив раніше невідому вразливість у своїй системі токенів, орієнтованій на конфіденційність, яка могла дозволити зловмисникам підробляти підроблені докази з нульовим розголошенням, що сприяло несанкціонованому випуску або виведенню токенів.

Про вразливість вперше повідомили 16 квітня через рекомендації щодо безпеки Anza на GitHub, разом із робочим підтвердженням концепції. Інженери з команд розробників Solana Anza, Firedancer та Jito підтвердили наявність помилки та негайно почали працювати над її виправленням, згідно з результатами аналізу. опубліковано в суботу,

Проблема виникла через програму ZK ElGamal Proof, яка перевіряє докази з нульовим розголошенням (ZKP), що використовуються в конфіденційних переказах Solana Token-22. Ці токени розширення дозволяють здійснювати приватні баланси та перекази, шифруючи суми та використовуючи криптографічні докази для їх перевірки.

ZKP – це криптографічний метод, який дозволяє комусь довести, що він знає або має доступ до чогось, наприклад, пароля чи віку, не розкриваючи саму річ.

У Крипто їх можна використовувати для підтвердження дійсності транзакції без вказівки конкретних сум чи адрес (які в іншому випадку можуть бути використані зловмисниками для планування експлойтів).

Помилка виникла через те, що деякі алгебраїчні компоненти були відсутні в процесі хешування під час перетворення Фіата-Шаміра — стандартного методу, що робить докази з нульовим розголошенням неінтерактивними. (Неінтерактивність означає перетворення процесу обміну даними на одноразовий доказ, який може перевірити кожен).

Досвідчений зловмисник може підробити недійсні докази, які верифікатор у мережі все одно прийме.

Це дозволило б несанкціоновані дії, такі як випуск необмеженої кількості токенів або виведення токенів з інших облікових записів.

Таким чином, вразливість не вплинула на стандартні токени SPL або основну логіку програми Token-2022.

Патчі були приватно розповсюджені серед операторів валідаторів, починаючи з 17 квітня. Пізніше того ж вечора було випущено другий патч для вирішення пов'язаної проблеми в іншій частині кодової бази.

Обидва були перевірені сторонніми фірмами з безпеки Asymmetric Research, Neodyme та OtterSec. До 18 квітня переважна більшість валідаторів прийняли це виправлення.

Згідно з результатами розтину, немає жодних ознак того, що помилку було використано, і всі кошти залишаються в безпеці.