Глибина аналізу вразливостей безпеки посилань мови 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, яка містить граф запозичень (borrow graph) та локальні змінні (locals), щоб забезпечити безпеку посилань у функції.
Під час верифікації буде виконуватись код базового блоку, генеруючи post state, а потім pre state і post state об'єднуються для оновлення стану блоку, і цей стан блоку поширюється на наступні блоки. Цей процес схожий на ідею Sea of Nodes у V8 turbofan.
Вразливість виникає в функції join_. Коли сума довжини параметрів і довжини локальних змінних перевищує 256, через те, що local є типом u8, відбувається переповнення цілого числа. Хоча Move має процес перевірки кількості locals, в модулі перевірки меж лише перевіряються locals, не враховуючи довжину параметрів.
Ця уразливість переповнення цілих чисел може призвести до атаки 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 та в майбутньому поділимося більшою кількістю відкриттів.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
9
Поділіться
Прокоментувати
0/400
ChainMelonWatcher
· 07-16 05:21
Це знову вийшло з ладу, безпека move не дуже хороша!
Переглянути оригіналвідповісти на0
AirdropHunterXiao
· 07-14 01:33
Копай, копай, знову є хороша робота.
Переглянути оригіналвідповісти на0
ChainSherlockGirl
· 07-13 17:05
Ха! Ще один театр безпекових вразливостей у блокчейні, цього разу це велике шоу переповнення цілих чисел на Move~ На мою думку, це, напевно, знову якийсь великий інвестор хоче скористатися нагодою, щоб шортити.
Переглянути оригіналвідповісти на0
SerumSquirter
· 07-13 11:48
Ще одна проблема з безпекою, це кінець.
Переглянути оригіналвідповісти на0
rugged_again
· 07-13 11:46
Знову вийшов з洞, втік.
Переглянути оригіналвідповісти на0
LiquidatedDreams
· 07-13 11:42
Хто ще грає в move?
Переглянути оригіналвідповісти на0
DarkPoolWatcher
· 07-13 11:31
aptos виявився ненадійним, купа вразливостей
Переглянути оригіналвідповісти на0
MondayYoloFridayCry
· 07-13 11:28
Знову чорний move? Тс-тс-тс
Переглянути оригіналвідповісти на0
PretendingSerious
· 07-13 11:22
Ця дірка занадто очевидна, основи розробки не є достатньо міцними.
Уразливість посилання на Move мови: ризик переповнення цілих чисел та рекомендації з запобігання
Глибина аналізу вразливостей безпеки посилань мови 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, яка містить граф запозичень (borrow graph) та локальні змінні (locals), щоб забезпечити безпеку посилань у функції.
Під час верифікації буде виконуватись код базового блоку, генеруючи post state, а потім pre state і post state об'єднуються для оновлення стану блоку, і цей стан блоку поширюється на наступні блоки. Цей процес схожий на ідею Sea of Nodes у V8 turbofan.
Вразливість виникає в функції join_. Коли сума довжини параметрів і довжини локальних змінних перевищує 256, через те, що local є типом u8, відбувається переповнення цілого числа. Хоча Move має процес перевірки кількості locals, в модулі перевірки меж лише перевіряються locals, не враховуючи довжину параметрів.
Ця уразливість переповнення цілих чисел може призвести до атаки 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 та в майбутньому поділимося більшою кількістю відкриттів.