BitsLab, дочірня компанія TonBit, виявила основну вразливість ядра TON VM: детальне пояснення кореневої причини вразливості та заходи щодо її пом'якшення
Цей звіт детально аналізує технічні деталі основної уразливості DoS у віртуальній машині TON, її кореневі причини та можливі способи атак, а також демонструє ефективне рішення, запропоноване командою TonBit.
Недавно система віртуальної машини TON мережі отримала важливе оновлення з питань безпеки. Команда безпеки TonBit, належна BitsLab, успішно виявила та допомогла виправити основну уразливість, яка може призвести до вичерпання ресурсів Віртуальної машини TON. Ця уразливість використовує рекурсивний механізм обробки Віртуальною машиною з ітераціями Continuation і може бути зловживана зловмисним контрактом, що призводить до збоїв системи та нестабільності мережі.
Якщо цю уразливість зловживатимуть, можна буде викликати збій всіх вузлів, навіть не витративши 01928374656574839201 TON, безпосередньо загрожуючи доступності мережі. У цьому випадку TonBit швидко виявив уразливість завдяки своїм високим технологічним можливостям і запропонував інноваційний рішення, замінивши рекурсію ітераціями, шляхом налаштування внутрішнього потокового механізму Віртуальної машини. Це дозволило успішно створити безпечне екологічне середовище для користувачів TON. Офіційна команда TON в своєму останньому оновленні виразила особливу вдячність TonBit за видатний внесок у безпеку екосистеми.
У цьому докладі з безпеки ми детально розглянемо причини, технічні деталі та рішення цієї вразливості. Доповідь детально описує, як вразливість використовує вкладеність Глибини Continuation для побудови рекурсивного ланцюжка, який спричиняє вичерпання ресурсів, а також як шкідливий контракт вичерпує стековий простір хоста шляхом розширення стеку викликів. У той же час ми також розповімо, як команда TonBit вирішила цю проблему, змінивши дефект в дизайні рекурсивного ланцюжка на кооперативний ітераційний механізм. Цей виправлення значно покращило стійкість мережі TON і стало важливим джерелом відносно основної безпеки в галузі блокчейн.
Case Study: Уразливість DoS в TON VM та пов'язані заходи пом'якшення
Опис
Цей звіт описує вразливість DoS (відмова в обслуговуванні) в TON Віртуальній машині та заходи її пом'якшення. Ця вразливість виникла через обробку вкладених Continuation під час виконання контракту Віртуальною машиною. Ця вразливість дозволяє зловмисному контракту створювати Continuation, вкладати Глибина у певний спосіб, тим самим спричиняючи глибоку рекурсію під час оцінки, вичерпуючи стековий простір хоста і зупиняючи Віртуальну машину. Для пом'якшення цієї проблеми Віртуальна машина змінила обробку Continuation та потоку управління. Тепер Віртуальна машина більше не використовує ланцюг Continuation для послідовного хвостового виклику, а активно ітерує ланцюг. Цей підхід забезпечує використання постійного стекового простору хоста, запобігаючи переповненню стеку.
Огляд
Згідно з офіційною документацією, TON VM - це стекова віртуальна машина, яка використовує стиль передачі продовження (CPS, стиль передачі продовження) як її механізм керування потоком, що використовується для внутрішніх процесів та смартконтрактів. Регістри керування потоком доступні для контрактів, що забезпечує гнучкість.
В теорії TVM Continuation можна узагальнити на три категорії:
OrdCont (тобто vmc_std), містить TON ASM фрагменти, які необхідно виконати, це об'єкт першого рівня в TVM. Контракти можуть створювати його явно під час виконання та передавати його для реалізації довільних потоків управління.
Незвичайні продовження (Extraordinary continuations) зазвичай містять OrdCont як компонент, створюються за допомогою явних ітераційних примітивів та спеціальних неявних операцій для обробки відповідних механізмів керування потоком.
Додатковий ArgContExt, що упаковує іншу Continuation для збереження контрольних даних.
Під час виконання контракту, Віртуальна машина входить в головний цикл, розкодовуючи кожен символ уривка контракту і надсилаючи відповідну операцію на відповідний обробник. Звичайний обробник повертається одразу після виконання відповідної операції.
Відносно, ітераційна інструкція використовує надане Continuation як компонент, щоб створити незвичайний Continuation, та перейти до незвичайного Continuation в відповідному контексті. Сам незвичайний Continuation реалізує логіку при стрибку та здійснює стрибок до певного компонента в залежності від умови. Наприклад, використовуючи інструкцію WHILE, ми можемо продемонструвати цей процес на рис. 1 (без можливого виходу).
Зображення 1: Незвичайна логіка продовження
Коренева причина
У версіях Віртуальної машини з вразливостями такі переходи призводять до послідовних динамічних хвостових викликів, що вимагає, щоб стек хоста підтримував стековий фрейм для кожного переходу (як показано на рис. 2).
На прикладі WhileCont інші частини припущено у зв'язку з їхньою стислістю.
Рисунок 2: Троїстий перехід рекурсії для глибокого вкладення
Ідеальною ситуацією було б, якщо це не становило проблем, оскільки зазвичай компоненти представлені як OrdCont, його перехід зберігає лише поточний контекст, а потім вказує на виконання фрагменту, який він утримує, перед залишком контракту фрагментів та не викликає більше рекурсії. Однак в теорії дозволяється Не звичайним Continuation складовим отримати доступ до cc (c0) регістру в TVM (тобто гілка set_c0, згадана вище). Тому контракти можуть зловживати цією функцією, щоб виконувати рекурсію Глибина (яка буде описана пізніше). Пряме виключення рекурсії в Не звичайному Continuation під час переходу більш ясне та простіше, ніж змінювати реалізацію цієї загальної функції.
Шляхом повторного використання отриманого незвичайного продовження, щоб побудувати незвичайне продовження на наступному рівні, можна створити вкладене продовження Глибина шляхом ітерації. Ці вкладені продовження Глибина можуть виснажити доступне стекове простір хоста при оцінці, що призводить до виникнення сигналу SIGSEGV від операційної системи та завершення процесу Віртуальна машина.
На рисунку 3 наведено доказ перевірки концепції (PoC) процесу вкладення.
Зображення 3: Процес вбудовуванняпастка
Під час кожної ітерації ми бачимо, що тіло розширилося на одну WhileCont{chkcond=true}. Виконавши cc, згенероване та збережене під час попередньої ітерації, отримаємо стек викликів, подібний до цього:
З очевидно, що стосовно стосу та рівня вкладеності (тобто кількості ітерацій) існує лінійна залежність, що свідчить про можливе вичерпання стекового простору.
Про використання у реальному середовищі
У реальному Блокчейні обмеження на витрати палива ускладнюють створення зловісних контрактів. Через лінійну складність вкладених процесів (TVM ефективно запобігає дешевому створенню через самодовідку), розробка практично придатних зловісних контрактів не є простим завданням. Конкретно, один рівень вкладеності створює послідовність викликів, які витрачають три головних стекових фрейму (320 байтів) у відлагоджувальному бінарному файлі та два (256 байтів, останні два виклики інлайновані в один) у випущеному бінарному файлі. Для перевірки Нода, яка працює на сучасній операційній системі POSIX, розмір стеку за замовчуванням становить 8 МБ, цього достатньо для підтримки вкладеності понад 30 000 рівнів у випущеному бінарному файлі. Хоча все ще можна створити контракт, який вичерпає стековий простір, але це набагато складніше, ніж у попередньому прикладі.
Заходи легкого полегшення
Ця патч вносить зміни до поведінки переходу в умовах вкладеного Continuation. Ми бачимо, що змінений підпис переходу Continuation.
На прикладі UntilCont, інші частини будуть опущені для зручності.
Більше не викликайте VmState::jump, щоб перейти до наступного Continuation, це означає, що на кожному Continuation виконується рекурсивний потрійний перехід і чекається поширення значення назад. Тепер перехід Continuation розглядає лише наступний рівень Continuation, а потім повертає контроль Віртуальна машина.
Віртуальна машина шляхом співпраці ітеративно розкриває кожен рівень continuation, поки не зустріне NullRef, що позначає завершення аналізу ланцюжка (реалізовано в OrdCont або ExuQuitCont). Під час цього ітераційного процесу на головному стеку завжди виділяється лише один перехід continuation, що забезпечує постійне використання стеку.
Висновок
Для послуг, які вимагають високої доступності, рекурсивне використання може стати потенційним вектором атаки. При обробці користувацької логіки може бути викликана складність з примусовим припиненням рекурсії. Ця уразливість ДоС показує екстремальний випадок неправомірного використання нормальної функціональності в умовах обмежених ресурсів (або інших обмежень). Якщо рекурсія залежить від користувацького вводу, подібні проблеми можуть виникнути, що є досить поширеним в контрольному потоці примітивів Віртуальної машини.
Даний звіт детально аналізує технічні деталі основної уразливості DoS у Віртуальній машині TON, кореневі причини та можливі способи атак, а також демонструє ефективне рішення, запропоноване командою TonBit. Шляхом перетворення рекурсивного механізму переходу Віртуальної машини на ітераційну обробку TonBit успішно запропонував вирішення для усунення уразливості, допомігши виправити цю основну уразливість, яка могла спричинити паралізацію мережі, тим самим забезпечивши більш надійний захист для екосистеми TON. Ця подія не лише відображає глибокі досягнення TonBit у сфері безпеки базових технологій блокчейну, але також показує його важливу роль як офіційного постачальника забезпечення безпеки (SAP) для TON.
Як невід'ємний партнер екосистеми TON з безпеки, TonBit завжди перебуває на передньому краї промисловості в питаннях забезпечення стабільності мережі Блокчейн та безпеки активів користувачів. Від виявлення уразливостей до розробки рішень, TonBit, завдяки своїм потужним технічним можливостям та глибокому розумінню розвитку Блокчейн, заклав міцні основи для тривалого розвитку мережі TON. У той же час команда TonBit продовжує працювати над архітектурою мережі безпеки, захистом користувачів інформації та підвищенням безпеки сценаріїв застосування Блокчейн. У майбутньому TonBit продовжить підтримувати прогрес технологій безпеки завдяки інноваціям, що надасть постійну підтримку та захист екосистемі TON та всій промисловості Блокчейну. Виявлення цієї вразливості та допомога у виправленні отримали високу оцінку від офіційних представників TON, що додатково сильнішає позицію TonBit у сфері безпеки Блокчейну і свідчить про його рішучу підтримку розвитку децентралізації.
TonBit Офіційний веб-сайт:
Офіційний Twitter TonBit:
Телеграма:
Linkedin:
Блог: #блоги
Для потребу аудиту Telegram звертайтеся до @starchou
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
BitsLab, дочірня компанія TonBit, виявила основну вразливість ядра TON VM: детальне пояснення кореневої причини вразливості та заходи щодо її пом'якшення
Цей звіт детально аналізує технічні деталі основної уразливості DoS у віртуальній машині TON, її кореневі причини та можливі способи атак, а також демонструє ефективне рішення, запропоноване командою TonBit.
Недавно система віртуальної машини TON мережі отримала важливе оновлення з питань безпеки. Команда безпеки TonBit, належна BitsLab, успішно виявила та допомогла виправити основну уразливість, яка може призвести до вичерпання ресурсів Віртуальної машини TON. Ця уразливість використовує рекурсивний механізм обробки Віртуальною машиною з ітераціями Continuation і може бути зловживана зловмисним контрактом, що призводить до збоїв системи та нестабільності мережі.
Якщо цю уразливість зловживатимуть, можна буде викликати збій всіх вузлів, навіть не витративши 01928374656574839201 TON, безпосередньо загрожуючи доступності мережі. У цьому випадку TonBit швидко виявив уразливість завдяки своїм високим технологічним можливостям і запропонував інноваційний рішення, замінивши рекурсію ітераціями, шляхом налаштування внутрішнього потокового механізму Віртуальної машини. Це дозволило успішно створити безпечне екологічне середовище для користувачів TON. Офіційна команда TON в своєму останньому оновленні виразила особливу вдячність TonBit за видатний внесок у безпеку екосистеми.
У цьому докладі з безпеки ми детально розглянемо причини, технічні деталі та рішення цієї вразливості. Доповідь детально описує, як вразливість використовує вкладеність Глибини Continuation для побудови рекурсивного ланцюжка, який спричиняє вичерпання ресурсів, а також як шкідливий контракт вичерпує стековий простір хоста шляхом розширення стеку викликів. У той же час ми також розповімо, як команда TonBit вирішила цю проблему, змінивши дефект в дизайні рекурсивного ланцюжка на кооперативний ітераційний механізм. Цей виправлення значно покращило стійкість мережі TON і стало важливим джерелом відносно основної безпеки в галузі блокчейн.
Case Study: Уразливість DoS в TON VM та пов'язані заходи пом'якшення
Опис
Цей звіт описує вразливість DoS (відмова в обслуговуванні) в TON Віртуальній машині та заходи її пом'якшення. Ця вразливість виникла через обробку вкладених Continuation під час виконання контракту Віртуальною машиною. Ця вразливість дозволяє зловмисному контракту створювати Continuation, вкладати Глибина у певний спосіб, тим самим спричиняючи глибоку рекурсію під час оцінки, вичерпуючи стековий простір хоста і зупиняючи Віртуальну машину. Для пом'якшення цієї проблеми Віртуальна машина змінила обробку Continuation та потоку управління. Тепер Віртуальна машина більше не використовує ланцюг Continuation для послідовного хвостового виклику, а активно ітерує ланцюг. Цей підхід забезпечує використання постійного стекового простору хоста, запобігаючи переповненню стеку.
Огляд
Згідно з офіційною документацією, TON VM - це стекова віртуальна машина, яка використовує стиль передачі продовження (CPS, стиль передачі продовження) як її механізм керування потоком, що використовується для внутрішніх процесів та смартконтрактів. Регістри керування потоком доступні для контрактів, що забезпечує гнучкість.
В теорії TVM Continuation можна узагальнити на три категорії:
OrdCont (тобто vmc_std), містить TON ASM фрагменти, які необхідно виконати, це об'єкт першого рівня в TVM. Контракти можуть створювати його явно під час виконання та передавати його для реалізації довільних потоків управління.
Незвичайні продовження (Extraordinary continuations) зазвичай містять OrdCont як компонент, створюються за допомогою явних ітераційних примітивів та спеціальних неявних операцій для обробки відповідних механізмів керування потоком.
Додатковий ArgContExt, що упаковує іншу Continuation для збереження контрольних даних.
Під час виконання контракту, Віртуальна машина входить в головний цикл, розкодовуючи кожен символ уривка контракту і надсилаючи відповідну операцію на відповідний обробник. Звичайний обробник повертається одразу після виконання відповідної операції.
Відносно, ітераційна інструкція використовує надане Continuation як компонент, щоб створити незвичайний Continuation, та перейти до незвичайного Continuation в відповідному контексті. Сам незвичайний Continuation реалізує логіку при стрибку та здійснює стрибок до певного компонента в залежності від умови. Наприклад, використовуючи інструкцію WHILE, ми можемо продемонструвати цей процес на рис. 1 (без можливого виходу).
Зображення 1: Незвичайна логіка продовження
Коренева причина
У версіях Віртуальної машини з вразливостями такі переходи призводять до послідовних динамічних хвостових викликів, що вимагає, щоб стек хоста підтримував стековий фрейм для кожного переходу (як показано на рис. 2).
На прикладі WhileCont інші частини припущено у зв'язку з їхньою стислістю.
Рисунок 2: Троїстий перехід рекурсії для глибокого вкладення
Ідеальною ситуацією було б, якщо це не становило проблем, оскільки зазвичай компоненти представлені як OrdCont, його перехід зберігає лише поточний контекст, а потім вказує на виконання фрагменту, який він утримує, перед залишком контракту фрагментів та не викликає більше рекурсії. Однак в теорії дозволяється Не звичайним Continuation складовим отримати доступ до cc (c0) регістру в TVM (тобто гілка set_c0, згадана вище). Тому контракти можуть зловживати цією функцією, щоб виконувати рекурсію Глибина (яка буде описана пізніше). Пряме виключення рекурсії в Не звичайному Continuation під час переходу більш ясне та простіше, ніж змінювати реалізацію цієї загальної функції.
Шляхом повторного використання отриманого незвичайного продовження, щоб побудувати незвичайне продовження на наступному рівні, можна створити вкладене продовження Глибина шляхом ітерації. Ці вкладені продовження Глибина можуть виснажити доступне стекове простір хоста при оцінці, що призводить до виникнення сигналу SIGSEGV від операційної системи та завершення процесу Віртуальна машина.
На рисунку 3 наведено доказ перевірки концепції (PoC) процесу вкладення.
Зображення 3: Процес вбудовуванняпастка
Під час кожної ітерації ми бачимо, що тіло розширилося на одну WhileCont{chkcond=true}. Виконавши cc, згенероване та збережене під час попередньої ітерації, отримаємо стек викликів, подібний до цього:
З очевидно, що стосовно стосу та рівня вкладеності (тобто кількості ітерацій) існує лінійна залежність, що свідчить про можливе вичерпання стекового простору.
Про використання у реальному середовищі
У реальному Блокчейні обмеження на витрати палива ускладнюють створення зловісних контрактів. Через лінійну складність вкладених процесів (TVM ефективно запобігає дешевому створенню через самодовідку), розробка практично придатних зловісних контрактів не є простим завданням. Конкретно, один рівень вкладеності створює послідовність викликів, які витрачають три головних стекових фрейму (320 байтів) у відлагоджувальному бінарному файлі та два (256 байтів, останні два виклики інлайновані в один) у випущеному бінарному файлі. Для перевірки Нода, яка працює на сучасній операційній системі POSIX, розмір стеку за замовчуванням становить 8 МБ, цього достатньо для підтримки вкладеності понад 30 000 рівнів у випущеному бінарному файлі. Хоча все ще можна створити контракт, який вичерпає стековий простір, але це набагато складніше, ніж у попередньому прикладі.
Заходи легкого полегшення
Ця патч вносить зміни до поведінки переходу в умовах вкладеного Continuation. Ми бачимо, що змінений підпис переходу Continuation.
На прикладі UntilCont, інші частини будуть опущені для зручності.
Більше не викликайте VmState::jump, щоб перейти до наступного Continuation, це означає, що на кожному Continuation виконується рекурсивний потрійний перехід і чекається поширення значення назад. Тепер перехід Continuation розглядає лише наступний рівень Continuation, а потім повертає контроль Віртуальна машина.
Віртуальна машина шляхом співпраці ітеративно розкриває кожен рівень continuation, поки не зустріне NullRef, що позначає завершення аналізу ланцюжка (реалізовано в OrdCont або ExuQuitCont). Під час цього ітераційного процесу на головному стеку завжди виділяється лише один перехід continuation, що забезпечує постійне використання стеку.
Висновок
Для послуг, які вимагають високої доступності, рекурсивне використання може стати потенційним вектором атаки. При обробці користувацької логіки може бути викликана складність з примусовим припиненням рекурсії. Ця уразливість ДоС показує екстремальний випадок неправомірного використання нормальної функціональності в умовах обмежених ресурсів (або інших обмежень). Якщо рекурсія залежить від користувацького вводу, подібні проблеми можуть виникнути, що є досить поширеним в контрольному потоці примітивів Віртуальної машини.
Даний звіт детально аналізує технічні деталі основної уразливості DoS у Віртуальній машині TON, кореневі причини та можливі способи атак, а також демонструє ефективне рішення, запропоноване командою TonBit. Шляхом перетворення рекурсивного механізму переходу Віртуальної машини на ітераційну обробку TonBit успішно запропонував вирішення для усунення уразливості, допомігши виправити цю основну уразливість, яка могла спричинити паралізацію мережі, тим самим забезпечивши більш надійний захист для екосистеми TON. Ця подія не лише відображає глибокі досягнення TonBit у сфері безпеки базових технологій блокчейну, але також показує його важливу роль як офіційного постачальника забезпечення безпеки (SAP) для TON.
Як невід'ємний партнер екосистеми TON з безпеки, TonBit завжди перебуває на передньому краї промисловості в питаннях забезпечення стабільності мережі Блокчейн та безпеки активів користувачів. Від виявлення уразливостей до розробки рішень, TonBit, завдяки своїм потужним технічним можливостям та глибокому розумінню розвитку Блокчейн, заклав міцні основи для тривалого розвитку мережі TON. У той же час команда TonBit продовжує працювати над архітектурою мережі безпеки, захистом користувачів інформації та підвищенням безпеки сценаріїв застосування Блокчейн. У майбутньому TonBit продовжить підтримувати прогрес технологій безпеки завдяки інноваціям, що надасть постійну підтримку та захист екосистемі TON та всій промисловості Блокчейну. Виявлення цієї вразливості та допомога у виправленні отримали високу оцінку від офіційних представників TON, що додатково сильнішає позицію TonBit у сфері безпеки Блокчейну і свідчить про його рішучу підтримку розвитку децентралізації.
TonBit Офіційний веб-сайт:
Офіційний Twitter TonBit:
Телеграма:
Linkedin:
Блог: #блоги
Для потребу аудиту Telegram звертайтеся до @starchou