Аналіз вразливості переповнення цілого числа в безпечній перевірці посилань Move

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

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

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

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

Move мова підтримує два типи посилань: незмінні посилання & та змінні посилання &mut. Незмінні посилання використовуються для читання даних, змінні посилання - для зміни даних. Розумне використання типів посилань допомагає підтримувати безпеку та ідентифікувати модулі читання.

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

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

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

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

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

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

Як лідери в дослідженні безпеки мови Move, ми продовжимо поглиблене дослідження питань безпеки Move і надалі поділимось більше знахідками.