Глубина анализа уязвимости ссылок языка Move

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

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

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

Процесс верификации начинается с вызова функции безопасной верификации, которая вызывает analyze_function. В analyze_function осуществляется верификация каждого базового блока. Базовый блок — это последовательность кода, которая не содержит ветвлений, кроме входа и выхода.

Язык Move определяет основные блоки, проходя по байт-коду, находя все последовательности инструкций ветвления и циклов. Типичный пример основного блока кода Move IR может содержать 3 основных блока, определяемых инструкциями BrTrue, Branch и Ret.

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

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

В процессе верификации будет выполняться код базового блока, генерируется пост-состояние, затем предшествующее состояние и пост-состояние объединяются для обновления состояния блока, и условия, связанные с этим блоком, передаются в последующие блоки. Этот процесс похож на идею "Моря Узлов" в V8 turbofan.

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

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

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

Чтобы проверить этот уязвимость, мы написали PoC. Этот блок кода в PoC содержит безусловную инструкцию перехода, которая при каждом выполнении последней инструкции возвращается к первой инструкции, поэтому этот блок кода будет многократно вызывать функции execute_block и join.

Настроив соответствующие параметры, мы можем изменить длину нового locals map на 8. При втором выполнении функции execute_block, из-за недостаточной длины locals, произойдет паника.

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

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