Інтерпретація аналізу про великих технічних спеціалістів щодо інциденту з атакою хакерів на протокол Cetus.

Звичайна версія: простий «переклад» тлумачення технічного про @CetusProtocol

Аналіз інцидентів хакерських атак:

Цей напад виявив класичну проблему переповнення цілих чисел, яка проявляється у вигляді обриву даних під час процесу перетворення типів.

Технічні деталі розбору:

1. Локалізація вразливості: проблема виникає у механізмі перетворення типів функції get_amount_by_liquidity, примусове перетворення з u256 на u64 призводить до втрати старших даних.

2. Процес атаки:

1. Зловмисник передає величезний обсяг параметра кількості ліквідності через функцію add_liquidity;

2、система викликає функцію get_delta_b для розрахунку необхідної кількості токенів B;

3. У процесі обчислення два числа типу u128, що перемножуються, теоретичний результат має бути типу u256;

Ключовий дефект: при поверненні функції результат u256 примусово перетворюється на u64, що призводить до обриву старших 128 біт даних.

3. Використання ефекту: раніше для карбування обсягу ліквідності потрібно було багато токенів, тепер достатньо дуже малої кількості токенів. Зловмисники отримують величезні частки ліквідності за дуже низьку ціну, а потім реалізують арбітраж фонду, знищуючи частину ліквідності.

Просте порівняння: це як використовувати калькулятор, який може показувати лише 8 цифр, щоб обчислити 1 мільярд × 1 мільярд; результат у 20 цифр може показувати лише останні 8, а перші 12 цифр просто зникають. Зловмисники використовують цю уразливість "втрати точності обчислень".

Потрібно чітко зазначити: цей漏洞 не має відношення до базової архітектури безпеки @SuiNetwork, безпека мови Move "слава" поки що залишається надійною. Чому?

Мова Move дійсно має суттєві переваги у управлінні ресурсами та безпеці типів, що дозволяє ефективно запобігати проблемам безпеки на низькому рівні, таким як подвійні витрати, витік ресурсів тощо. Але в даному випадку протоколу Cetus виникла помилка математичних обчислень на рівні прикладної логіки, а не дефект дизайну самої мови Move.

Конкретно, хоча система типів Move є суворою, для операцій явного приведення типів (explicit casting) все ще потрібно покладатися на правильне судження розробника. Коли програма активно виконує перетворення типу з u256 на u64, компілятор не може визначити, чи це навмисний дизайн, чи логічна помилка.

Крім того, цей інцидент безпеки не має нічого спільного з основними базовими функціями Sui, такими як механізм консенсусу, обробка транзакцій і управління станами. Sui Network лише сумлінно виконує інструкції транзакцій, надіслані протоколом Cetus, і вразливість випливає з логічних недоліків самого протоколу прикладного рівня.

Сказати прямо, жодна найсучасніша мова програмування не може повністю виключити логічні помилки на рівні застосунку. Move може запобігти більшості ризиків безпеки на нижньому рівні, але не може замінити розробника в перевірці меж бізнес-логіки та захисту від переповнення математичних операцій.

Виправлення:

Поговорив з про, раніше в технічному аналізі хакерської атаки на @CetusProtocol були виявлені неточності в конкретних деталях, тому ця інформація коригується.

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

Просто побачивши явище помилки в математичних обчисленнях, я припустив, що це проблема перетворення типів, але насправді це проблема перевірки меж інших функцій. Насправді, мова Move має строгий механізм перевірки для перетворення з u256 на u64 та інші типи, такі явні перетворення дійсно підлягають перевірці безпеки в нормальних умовах.

Конкретні місця вразливостей і механізми технічної реалізації необхідно виправити, як зазначено нижче.

Справжня проблема виникає в механізмі перевірки переповнення функції get\_delta\_a:

1. Функція: обчислення необхідної кількості токенів A при додаванні вказаної ліквідності;

2）Ключовий недолік: у функції checked\_shlw є помилка кодування в перевірці на переповнення, що не змогла зупинити недійсні великі значення ліквідності;

3. Використання атаки: Хакери конструюють спеціальні значення ліквідності, обходять перевірку на недійсність, врешті-решт завдяки механізму округлення div\_round кількість необхідних токенів A стає 14).

Атакуюча дія: виготовити величезну ліквідність за допомогою 1 токена A, а потім висмоктати кошти з пулу.