Este informe analiza en detalle los detalles técnicos, las causas fundamentales y las posibles formas de ataque de la vulnerabilidad central de DoS en la Máquina virtual TON, al tiempo que muestra la solución eficiente propuesta por el equipo de TonBit.
Recientemente, el sistema de Máquina virtual de TON Network ha experimentado una importante actualización de seguridad. El equipo de seguridad TonBit de BitsLab detectó y ayudó a solucionar con éxito una vulnerabilidad crítica que podría haber llevado a la agotamiento de recursos en la Máquina virtual de TON, posiblemente explotando el mecanismo de recursión en el procesamiento de Continuation. Este defecto podría haber sido aprovechado por contratos maliciosos, causando fallas en el sistema e inestabilidad de la red.
Si esta vulnerabilidad es explotada maliciosamente, puede provocar que todos los nodos de validación se caigan sin necesidad de gastar un TON, lo que amenaza directamente la disponibilidad de la red. En este incidente, TonBit, con su excelente capacidad técnica, localizó rápidamente la vulnerabilidad y propuso una solución innovadora que reemplaza la recursividad por la iteración ajustando el flujo de control interno de la máquina virtual, lo que ha creado un entorno más seguro para los usuarios de TON. El equipo oficial de TON agradece especialmente a TonBit por su destacada contribución a la seguridad del ecosistema en su último anuncio de actualización.
En el siguiente informe de seguridad detallado, analizaremos en profundidad las causas, detalles técnicos y soluciones de esta vulnerabilidad. El informe describe detalladamente cómo se utiliza la profundidad de la anidación Continuation para construir una cadena recursiva que provoca un ataque de agotamiento de recursos, así como cómo los contratos maliciosos consumen el espacio de la pila del host mediante la expansión de la pila de llamadas. Al mismo tiempo, también presentaremos cómo el equipo de TonBit resolvió completamente este problema mediante la eliminación de defectos de diseño en la cadena recursiva y el uso de un mecanismo de iteración colaborativo. Esta solución no solo mejora significativamente la estabilidad de la red TON, sino que también brinda una importante referencia para la seguridad subyacente de la industria blockchain.
Estudio de caso: Vulnerabilidad de DoS en TON VM y medidas de mitigación relacionadas
Introducción
Este informe describe una vulnerabilidad de DoS (denegación de servicio) en la Máquina virtual TON y las medidas de mitigación para resolver el problema. Esta vulnerabilidad se debe a la forma en que la Máquina virtual maneja la anidación de Continuation durante la ejecución del contrato. Esta vulnerabilidad permite que contratos maliciosos creen Continuations y las aniden en una Profundidad específica, lo que desencadena una recursión profunda durante la evaluación, agotando el espacio de la pila del host y haciendo que la Máquina virtual se detenga. Para mitigar este problema, la Máquina virtual ha realizado modificaciones en el manejo de Continuations y el flujo de control. Ahora, la Máquina virtual itera activamente la cadena en lugar de realizar llamadas de cola secuencial a través de la cadena de Continuations. Este enfoque garantiza el uso de un espacio de pila de host constante, evitando desbordamientos de pila.
Resumen
Según la documentación oficial, TON VM es una Máquina virtual basada en pilas que utiliza el estilo de Continuation-Passing Style (CPS) como su mecanismo de flujo de control, utilizado para los flujos internos y contratos inteligentes. Los registros de flujo de control son accesibles para los contratos, lo que proporciona flexibilidad.
Teóricamente, la Continuación en TVM se puede dividir en tres categorías:
OrdCont (también conocido como vmc_std), contiene fragmentos de TON ASM que se deben ejecutar y es un objeto de nivel 1 en TVM. Los contratos pueden crearlos explícitamente en tiempo de ejecución y pasarlos para lograr un flujo de control arbitrario.
Continuación extraordinaria (Extraordinary continuations), generalmente contiene OrdCont como componente, creado a través de primitivas de iteración explícita y operaciones implícitas especiales, utilizado para manejar el mecanismo de flujo de control correspondiente.
ArgContExt adicional, encapsula otras Continuation para guardar datos de control.
Durante el proceso de ejecución del contrato, la Máquina virtual entra en un bucle principal, decodificando una letra de cada fragmento del contrato y asignando la operación correspondiente al procesador adecuado. El procesador normal devuelve el control inmediatamente después de ejecutar la operación correspondiente.
Relativamente, la instrucción iterativa utilizará la Continuación proporcionada como componente para crear una Continuación no ordinaria y saltar a la Continuación no ordinaria en el contexto apropiado. La Continuación no ordinaria implementa la lógica al saltar y salta a un componente en función de una condición. Por ejemplo, al utilizar la instrucción WHILE, podemos demostrar este proceso en la Figura 1 (se omiten las posibles salidas).
Figura 1: Lógica de Continuación no común
La razón fundamental
En las versiones de Máquina virtual con vulnerabilidades, estos saltos causarán llamadas de cola dinámicas consecutivas, lo que requiere que la pila del host mantenga un marco de pila para cada salto (como se muestra en la figura 2).
Tomando WhileCont como ejemplo, se omiten otras partes por simplicidad.
Figura 2: Triple salto recursivo para profundizar en la trampa anidada
Idealmente, esto no sería un problema, ya que los componentes normalmente se representan como OrdCont, que solo guarda el contexto actual durante el salto y luego indica a la Máquina virtual que ejecute el fragmento que posee antes que los fragmentos de contrato restantes, sin introducir más recursividad. Sin embargo, en teoría, la Continuación no ordinaria permite que sus componentes accedan al registro cc (c0) en la TVM (es decir, la rama set_c0 mencionada anteriormente). Por lo tanto, el contrato podría abusar de esta función para realizar una recursividad Profundidad (se describe más adelante). En lugar de modificar la implementación de esta función normal, es más claro y sencillo eliminar la recursividad directamente durante el salto de la Continuación no ordinaria.
Al construir una Continuation no ordinaria de nivel superior mediante el uso repetido de Continuations no ordinarias ya adquiridas, se puede crear de forma iterativa una Profundidad anidada de Continuations. Estas Continuations anidadas de Profundidad pueden agotar el espacio de la pila disponible en el host durante la evaluación, lo que puede hacer que el sistema operativo emita una señal SIGSEGV y termine el proceso de la Máquina virtual.
La Figura 3 proporciona una validación conceptual (PoC) del proceso de anidamiento.
Figura 3: Proceso de trampa incrustada
En cada iteración, vemos que el cuerpo se expande con un WhileCont{chkcond=true}. Al ejecutar el cc generado y guardado en la iteración anterior, obtenemos una pila de llamadas similar a esta:
Se puede ver que el espacio de la pila está linealmente relacionado con el nivel de anidamiento (es decir, el número de iteraciones), lo que indica que puede agotar el espacio de la pila.
Sobre el uso en entornos reales
En la cadena de bloques real, la limitación de la tarifa de combustible dificulta la construcción de contratos maliciosos. Debido a la complejidad lineal del proceso de anidación (el diseño del TVM previene efectivamente la construcción más barata a través de la auto-referencia), desarrollar contratos maliciosos prácticamente viables no es fácil. En concreto, una anidación de capa genera una secuencia de llamadas, consumiendo tres marcos de pila principales (320 bytes) en el archivo binario de depuración y dos (256 bytes, las dos últimas llamadas se fusionan en una) en el archivo binario publicado. Para los nodos de verificación que se ejecutan en sistemas operativos POSIX modernos, el tamaño de pila predeterminado es de 8 MiB, lo que es suficiente para admitir anidaciones de más de 30,000 capas en el archivo binario publicado. Aunque aún es posible construir un contrato que agote el espacio de la pila, esto es mucho más difícil que el ejemplo de la sección anterior.
medidas de alivio
Esta corrección modifica el comportamiento de salto en situaciones de anidamiento de Continuation. Podemos ver que la firma de salto de Continuation ha cambiado.
Tomando UntilCont como ejemplo, se omite el resto por simplicidad.
Ya no se llama a VmState::jump para saltar a la siguiente Continuation, lo que significa que se realiza un triple salto recursivo en cada Continuation y se espera que el valor de retorno se propague hacia atrás. Ahora, el salto de Continuation solo resuelve el siguiente nivel de Continuation y luego devuelve el control a la Máquina virtual.
La Máquina virtual itera a través de cada nivel de la continuación de forma colaborativa hasta que encuentra un NullRef, lo que indica que se ha completado la resolución de la cadena (como se implementa en OrdCont o ExuQuitCont). Durante este proceso de iteración, solo se asigna un salto de continuación en la pila principal del host, lo que garantiza un uso constante de la pila.
Conclusión
Para servicios que requieren alta disponibilidad, el uso recursivo puede ser un vector de ataque potencial. Cuando se trata de lógica definida por el usuario, puede ser desafiante forzar la terminación recursiva. Esta vulnerabilidad DoS muestra un caso extremo en el que la funcionalidad normal se abusa accidentalmente bajo condiciones limitadas de recursos (u otras limitaciones). Si la recursión depende de la entrada del usuario, problemas similares pueden ocurrir, lo que es común en las primitivas de flujo de control de la Máquina virtual.
Este informe analiza en detalle los detalles técnicos, las causas fundamentales y las posibles formas de ataque de la vulnerabilidad central de DoS en la Máquina virtual TON, y también muestra la solución eficaz propuesta por el equipo TonBit. Al ajustar el mecanismo de salto recursivo de la Máquina virtual a un enfoque iterativo, TonBit ha tenido éxito en proponer una solución para corregir la vulnerabilidad, ayudando a solucionar esta vulnerabilidad central que podría causar un colapso de la red, proporcionando una seguridad más sólida para el ecosistema TON. Este incidente no solo refleja la profunda acumulación de TonBit en el campo de la seguridad de la tecnología subyacente de blockchain, sino que también muestra su papel importante como proveedor oficial de Seguridad de Garantía (SAP) de TON.
Como socio de seguridad indispensable en el ecosistema TON, TonBit siempre ha estado a la vanguardia de la protección de la estabilidad de la red Bloquear y la seguridad de los activos de los usuarios. Desde la detección de vulnerabilidades hasta el diseño de soluciones, TonBit ha sentado una base sólida para el desarrollo a largo plazo de la red TON gracias a su sólida capacidad tecnológica y su profundo conocimiento del desarrollo de la cadena Bloquear. Además, el equipo de TonBit también sigue trabajando en el fortalecimiento de la seguridad de la arquitectura de red, la protección de datos de los usuarios y la seguridad de los escenarios de aplicación de la cadena Bloquear. En el futuro, TonBit seguirá impulsando el progreso de la tecnología de seguridad con la innovación, proporcionando un apoyo continuo y garantía para el desarrollo saludable del ecosistema TON y toda la industria de la cadena Bloquear. Este descubrimiento de vulnerabilidades y el trabajo de asistencia en la reparación han sido muy reconocidos por TON, lo que ha fortalecido aún más la posición de TonBit en el campo de la seguridad de la cadena Bloquear y ha demostrado su firme compromiso de impulsar el desarrollo del ecosistema de Descentralización.
Sitio web oficial de TonBit:
Cuenta oficial de Twitter de TonBit:
Telegram：
Linkedin:
Blog: #blogs
Requisitos de auditoría de Telegram contacto: @starchou
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
BitsLab descubre una vulnerabilidad crítica en el núcleo TON VM: se detalla la causa raíz de la vulnerabilidad y las medidas de mitigación
Este informe analiza en detalle los detalles técnicos, las causas fundamentales y las posibles formas de ataque de la vulnerabilidad central de DoS en la Máquina virtual TON, al tiempo que muestra la solución eficiente propuesta por el equipo de TonBit.
Recientemente, el sistema de Máquina virtual de TON Network ha experimentado una importante actualización de seguridad. El equipo de seguridad TonBit de BitsLab detectó y ayudó a solucionar con éxito una vulnerabilidad crítica que podría haber llevado a la agotamiento de recursos en la Máquina virtual de TON, posiblemente explotando el mecanismo de recursión en el procesamiento de Continuation. Este defecto podría haber sido aprovechado por contratos maliciosos, causando fallas en el sistema e inestabilidad de la red.
Si esta vulnerabilidad es explotada maliciosamente, puede provocar que todos los nodos de validación se caigan sin necesidad de gastar un TON, lo que amenaza directamente la disponibilidad de la red. En este incidente, TonBit, con su excelente capacidad técnica, localizó rápidamente la vulnerabilidad y propuso una solución innovadora que reemplaza la recursividad por la iteración ajustando el flujo de control interno de la máquina virtual, lo que ha creado un entorno más seguro para los usuarios de TON. El equipo oficial de TON agradece especialmente a TonBit por su destacada contribución a la seguridad del ecosistema en su último anuncio de actualización.
En el siguiente informe de seguridad detallado, analizaremos en profundidad las causas, detalles técnicos y soluciones de esta vulnerabilidad. El informe describe detalladamente cómo se utiliza la profundidad de la anidación Continuation para construir una cadena recursiva que provoca un ataque de agotamiento de recursos, así como cómo los contratos maliciosos consumen el espacio de la pila del host mediante la expansión de la pila de llamadas. Al mismo tiempo, también presentaremos cómo el equipo de TonBit resolvió completamente este problema mediante la eliminación de defectos de diseño en la cadena recursiva y el uso de un mecanismo de iteración colaborativo. Esta solución no solo mejora significativamente la estabilidad de la red TON, sino que también brinda una importante referencia para la seguridad subyacente de la industria blockchain.
Estudio de caso: Vulnerabilidad de DoS en TON VM y medidas de mitigación relacionadas
Introducción
Este informe describe una vulnerabilidad de DoS (denegación de servicio) en la Máquina virtual TON y las medidas de mitigación para resolver el problema. Esta vulnerabilidad se debe a la forma en que la Máquina virtual maneja la anidación de Continuation durante la ejecución del contrato. Esta vulnerabilidad permite que contratos maliciosos creen Continuations y las aniden en una Profundidad específica, lo que desencadena una recursión profunda durante la evaluación, agotando el espacio de la pila del host y haciendo que la Máquina virtual se detenga. Para mitigar este problema, la Máquina virtual ha realizado modificaciones en el manejo de Continuations y el flujo de control. Ahora, la Máquina virtual itera activamente la cadena en lugar de realizar llamadas de cola secuencial a través de la cadena de Continuations. Este enfoque garantiza el uso de un espacio de pila de host constante, evitando desbordamientos de pila.
Resumen
Según la documentación oficial, TON VM es una Máquina virtual basada en pilas que utiliza el estilo de Continuation-Passing Style (CPS) como su mecanismo de flujo de control, utilizado para los flujos internos y contratos inteligentes. Los registros de flujo de control son accesibles para los contratos, lo que proporciona flexibilidad.
Teóricamente, la Continuación en TVM se puede dividir en tres categorías:
OrdCont (también conocido como vmc_std), contiene fragmentos de TON ASM que se deben ejecutar y es un objeto de nivel 1 en TVM. Los contratos pueden crearlos explícitamente en tiempo de ejecución y pasarlos para lograr un flujo de control arbitrario.
Continuación extraordinaria (Extraordinary continuations), generalmente contiene OrdCont como componente, creado a través de primitivas de iteración explícita y operaciones implícitas especiales, utilizado para manejar el mecanismo de flujo de control correspondiente.
ArgContExt adicional, encapsula otras Continuation para guardar datos de control.
Durante el proceso de ejecución del contrato, la Máquina virtual entra en un bucle principal, decodificando una letra de cada fragmento del contrato y asignando la operación correspondiente al procesador adecuado. El procesador normal devuelve el control inmediatamente después de ejecutar la operación correspondiente.
Relativamente, la instrucción iterativa utilizará la Continuación proporcionada como componente para crear una Continuación no ordinaria y saltar a la Continuación no ordinaria en el contexto apropiado. La Continuación no ordinaria implementa la lógica al saltar y salta a un componente en función de una condición. Por ejemplo, al utilizar la instrucción WHILE, podemos demostrar este proceso en la Figura 1 (se omiten las posibles salidas).
Figura 1: Lógica de Continuación no común
La razón fundamental
En las versiones de Máquina virtual con vulnerabilidades, estos saltos causarán llamadas de cola dinámicas consecutivas, lo que requiere que la pila del host mantenga un marco de pila para cada salto (como se muestra en la figura 2).
Tomando WhileCont como ejemplo, se omiten otras partes por simplicidad.
Figura 2: Triple salto recursivo para profundizar en la trampa anidada
Idealmente, esto no sería un problema, ya que los componentes normalmente se representan como OrdCont, que solo guarda el contexto actual durante el salto y luego indica a la Máquina virtual que ejecute el fragmento que posee antes que los fragmentos de contrato restantes, sin introducir más recursividad. Sin embargo, en teoría, la Continuación no ordinaria permite que sus componentes accedan al registro cc (c0) en la TVM (es decir, la rama set_c0 mencionada anteriormente). Por lo tanto, el contrato podría abusar de esta función para realizar una recursividad Profundidad (se describe más adelante). En lugar de modificar la implementación de esta función normal, es más claro y sencillo eliminar la recursividad directamente durante el salto de la Continuación no ordinaria.
Al construir una Continuation no ordinaria de nivel superior mediante el uso repetido de Continuations no ordinarias ya adquiridas, se puede crear de forma iterativa una Profundidad anidada de Continuations. Estas Continuations anidadas de Profundidad pueden agotar el espacio de la pila disponible en el host durante la evaluación, lo que puede hacer que el sistema operativo emita una señal SIGSEGV y termine el proceso de la Máquina virtual.
La Figura 3 proporciona una validación conceptual (PoC) del proceso de anidamiento.
Figura 3: Proceso de trampa incrustada
En cada iteración, vemos que el cuerpo se expande con un WhileCont{chkcond=true}. Al ejecutar el cc generado y guardado en la iteración anterior, obtenemos una pila de llamadas similar a esta:
Se puede ver que el espacio de la pila está linealmente relacionado con el nivel de anidamiento (es decir, el número de iteraciones), lo que indica que puede agotar el espacio de la pila.
Sobre el uso en entornos reales
En la cadena de bloques real, la limitación de la tarifa de combustible dificulta la construcción de contratos maliciosos. Debido a la complejidad lineal del proceso de anidación (el diseño del TVM previene efectivamente la construcción más barata a través de la auto-referencia), desarrollar contratos maliciosos prácticamente viables no es fácil. En concreto, una anidación de capa genera una secuencia de llamadas, consumiendo tres marcos de pila principales (320 bytes) en el archivo binario de depuración y dos (256 bytes, las dos últimas llamadas se fusionan en una) en el archivo binario publicado. Para los nodos de verificación que se ejecutan en sistemas operativos POSIX modernos, el tamaño de pila predeterminado es de 8 MiB, lo que es suficiente para admitir anidaciones de más de 30,000 capas en el archivo binario publicado. Aunque aún es posible construir un contrato que agote el espacio de la pila, esto es mucho más difícil que el ejemplo de la sección anterior.
medidas de alivio
Esta corrección modifica el comportamiento de salto en situaciones de anidamiento de Continuation. Podemos ver que la firma de salto de Continuation ha cambiado.
Tomando UntilCont como ejemplo, se omite el resto por simplicidad.
Ya no se llama a VmState::jump para saltar a la siguiente Continuation, lo que significa que se realiza un triple salto recursivo en cada Continuation y se espera que el valor de retorno se propague hacia atrás. Ahora, el salto de Continuation solo resuelve el siguiente nivel de Continuation y luego devuelve el control a la Máquina virtual.
La Máquina virtual itera a través de cada nivel de la continuación de forma colaborativa hasta que encuentra un NullRef, lo que indica que se ha completado la resolución de la cadena (como se implementa en OrdCont o ExuQuitCont). Durante este proceso de iteración, solo se asigna un salto de continuación en la pila principal del host, lo que garantiza un uso constante de la pila.
Conclusión
Para servicios que requieren alta disponibilidad, el uso recursivo puede ser un vector de ataque potencial. Cuando se trata de lógica definida por el usuario, puede ser desafiante forzar la terminación recursiva. Esta vulnerabilidad DoS muestra un caso extremo en el que la funcionalidad normal se abusa accidentalmente bajo condiciones limitadas de recursos (u otras limitaciones). Si la recursión depende de la entrada del usuario, problemas similares pueden ocurrir, lo que es común en las primitivas de flujo de control de la Máquina virtual.
Este informe analiza en detalle los detalles técnicos, las causas fundamentales y las posibles formas de ataque de la vulnerabilidad central de DoS en la Máquina virtual TON, y también muestra la solución eficaz propuesta por el equipo TonBit. Al ajustar el mecanismo de salto recursivo de la Máquina virtual a un enfoque iterativo, TonBit ha tenido éxito en proponer una solución para corregir la vulnerabilidad, ayudando a solucionar esta vulnerabilidad central que podría causar un colapso de la red, proporcionando una seguridad más sólida para el ecosistema TON. Este incidente no solo refleja la profunda acumulación de TonBit en el campo de la seguridad de la tecnología subyacente de blockchain, sino que también muestra su papel importante como proveedor oficial de Seguridad de Garantía (SAP) de TON.
Como socio de seguridad indispensable en el ecosistema TON, TonBit siempre ha estado a la vanguardia de la protección de la estabilidad de la red Bloquear y la seguridad de los activos de los usuarios. Desde la detección de vulnerabilidades hasta el diseño de soluciones, TonBit ha sentado una base sólida para el desarrollo a largo plazo de la red TON gracias a su sólida capacidad tecnológica y su profundo conocimiento del desarrollo de la cadena Bloquear. Además, el equipo de TonBit también sigue trabajando en el fortalecimiento de la seguridad de la arquitectura de red, la protección de datos de los usuarios y la seguridad de los escenarios de aplicación de la cadena Bloquear. En el futuro, TonBit seguirá impulsando el progreso de la tecnología de seguridad con la innovación, proporcionando un apoyo continuo y garantía para el desarrollo saludable del ecosistema TON y toda la industria de la cadena Bloquear. Este descubrimiento de vulnerabilidades y el trabajo de asistencia en la reparación han sido muy reconocidos por TON, lo que ha fortalecido aún más la posición de TonBit en el campo de la seguridad de la cadena Bloquear y ha demostrado su firme compromiso de impulsar el desarrollo del ecosistema de Descentralización.
Sitio web oficial de TonBit:
Cuenta oficial de Twitter de TonBit:
Telegram：
Linkedin:
Blog: #blogs
Requisitos de auditoría de Telegram contacto: @starchou