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