Анализ уязвимости переполнения целых чисел в языке Move

Введение

После глубокого изучения Aptos Moveevm мы обнаружили новую уязвимость переполнения целого числа. Процесс активации этой уязвимости относительно более интересен, ниже мы проведем глубокий анализ этой уязвимости и представим некоторые фоновые знания о языке Move. Через объяснение этой статьи, я уверен, вы получите более глубокое понимание языка Move.

Язык Move проверяет кодовые единицы перед выполнением байт-кода. Процесс проверки делится на 4 этапа, и этот уязвимость возникает на этапе reference_safety.

Безопасность ссылок в Move

Язык Move поддерживает два типа ссылок: неизменяемые ссылки (&) и изменяемые ссылки (&mut). Неизменяемые ссылки используются для чтения данных из структуры, в то время как изменяемые ссылки предназначены для изменения данных. Использование соответствующего типа ссылки помогает поддерживать безопасность и идентифицировать модули чтения.

В модуле безопасности ссылок Move будут по функции сканироваться байт-кодовые инструкции базовых блоков, чтобы проверить, что все операции со ссылками законны. Основные этапы проверки безопасности ссылок включают выполнение базовых блоков, генерацию конечного состояния, объединение предыдущих и последующих состояний и т. д.

Анализ уязвимостей

Уязвимость возникает в функции join_, которая ссылается на модуль безопасности. Когда сумма длины параметров функции и длины локальных переменных превышает 256, использование типа u8 для представления локальных переменных может привести к переполнению целого числа.

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

От переполнения целого числа до атаки DoS

Используя эту уязвимость переполнения целого числа, злоумышленник может создать циклический кодовый блок, изменяющий состояние блока. Когда функция execute_block выполняется снова, если индекс, к которому нужно получить доступ, отсутствует в новой локальной карте AbstractState, это приведет к атаке DoS.

В модуле reference safety операции MoveLoc/CopyLoc/FreeRef могут вызвать такую ситуацию. Например, в функции copy_loc, если LocalIndex не существует, это приведет к панике, что в свою очередь приведет к崩溃 всего узла.

Воспроизведение уязвимости

Этот уязвимость можно воспроизвести в git с помощью следующего кода PoC:

двигать публичная функция test(a: u64, b: u64, c: u64, d: u64) { пусть x = 0; цикл { если (x == 1) { перерыв }; х = х + 1; } }

Шаги для запуска DoS следующие:

1. При первом выполнении функции execute_block параметры и локальные переменные установлены как SignatureIndex(0), что приводит к num_locals равному 264. После выполнения функции join_ новая длина локальной карты становится 8.

2. При втором выполнении функции execute_block выполняется первая инструкция кода move copyloc(57). Поскольку в этот момент locals имеет длину 8, offset 57 не существует, что приводит к тому, что функция get(57).unwrap() возвращает None, что в конечном итоге вызывает панику.

Резюме

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

Что касается языка Move, мы рекомендуем добавить больше проверочных кодов во время выполнения, чтобы предотвратить неожиданные ситуации. В настоящее время безопасность проверяется в основном на этапе верификации, но как только проверка обходит, недостаточная безопасность на этапе выполнения может привести к более серьезным проблемам.

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