Интерпретация анализа про по поводу атаки Хакера на протокол 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 просто добросовестно выполнила инструкции по транзакциям, представленные протоколом Cetus, а уязвимость возникла из логического дефекта самого прикладного протокола.

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

Корректировка:

Поговорил с про, ранее проведенный технический анализ хакерской атаки на @CetusProtocol содержал неточности в конкретных деталях, поэтому делаю это исправление.

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

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

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

Настоящая проблема заключается в том, что механизм проверки переполнения функции get\_delta\_a не работает:

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

2. Ключевой дефект: в функции checked\_shlw ошибка кодирования в проверке переполнения не смогла предотвратить недопустимые значения большой ликвидности;

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

Эффект атаки: использовать 1 токен A для создания огромной ликвидности, а затем высосать фондовый пул.