Аналіз вразливості переповнення цілого числа в модулі безпеки Move

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

Мова Move перед виконанням байт-коду проходить верифікацію одиниць коду, цей процес складається з чотирьох етапів. У цій статті обговорюється вразливість, яка виникає на етапі reference_safety.

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

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

Мова Move підтримує два типи посилань: незмінні посилання (&) та змінні посилання (&mut). Незмінні посилання використовуються для читання даних, змінні посилання — для їх модифікації. Такий дизайн сприяє підвищенню безпеки та читабельності коду.

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

Під час верифікації буде порівнюватися стан до та після виконання базового блоку (pre state і post state), а результати будуть об'єднані для оновлення стану блоку. Якщо стан змінюється і поточний блок має зворотній край, що вказує на наявність циклу, базовий блок буде виконуватися повторно, поки стан не перестане змінюватися або не виникне помилка.

Уразливість виникає під час перевірки, чи змінився результат join. Коли сума довжини параметрів функції та довжини локальних змінних перевищує 256, використання типу u8 для представлення локального індексу може призвести до переповнення цілого числа. Хоча мова Move має процес перевірки кількості locals, він лише перевіряє кількість локальних змінних, не включаючи довжину параметрів.

Ця уразливість переповнення цілого числа може призвести до атаки відмови в обслуговуванні ( DoS ). Зловмисники можуть створити циклічний код, використовуючи переповнення для зміни стану блоку, що призведе до того, що нова локальна мапа буде відрізнятися від попередньої. Коли функція execute_block виконується знову, якщо індекс, до якого звертаються команди, не існує в новій локальній мапі AbstractState, це викличе паніку, що призведе до збою всього вузла.

Для демонстрації цього вразливості ми надаємо PoC, який можна відтворити в git. Цей PoC містить базовий блок з безумовною інструкцією переходу, який може багаторазово викликати функції execute_block і join. Завдяки ретельно налаштованим параметрам і кількості локальних змінних, можна зменшити довжину нової локальної карти до 8, а потім при другому виконанні викликати panic.

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

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