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

Вступ

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

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

Безпека посилань у Move

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

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

Аналіз вразливостей

Уразливість виникає в функції join_, яка посилається на безпечний модуль. Коли сума довжини параметрів функції та довжини локальних змінних перевищує 256, це може призвести до переповнення цілих чисел через використання типу u8 для представлення локальних змінних.

Хоча в Move є процес перевірки кількості locals, у модулі check bounds перевіряються лише locals, а довжина параметрів не враховується. Здається, розробники усвідомили необхідність перевірки загальної кількості параметрів і локальних значень, але в коді перевіряється лише кількість локальних змінних.

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

Використовуючи цю вразливість переповнення цілого числа, зловмисник може створити циклічний блок коду, щоб змінити стан блоку. Коли функція execute_block виконується повторно, якщо індекс, до якого потрібно звернутися в інструкції, не існує в новій карті AbstractState locals, це призведе до атаки типу 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 параметри та locals були встановлені на SignatureIndex(0), що призвело до num_locals, рівного 264. Після виконання функції join_ довжина нової мапи locals змінилася на 8.

2. Під час другого виконання функції execute_block, виконується перша інструкція коду move copyloc(57). Оскільки на цей момент locals має лише довжину 8, offset 57 не існує, що призводить до того, що функція get(57).unwrap() повертає None, в результаті чого виникає panic.

Підсумок

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

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

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