Análisis de vulnerabilidades del compilador Solidity y estrategias de respuesta

El compilador es una de las partes fundamentales de los sistemas informáticos modernos. Es un programa de computadora cuya función principal es convertir el código fuente escrito en un lenguaje de programación de alto nivel, que es fácil de entender y escribir para los humanos, en código de instrucciones ejecutables por la CPU de la computadora o por una máquina virtual de bytecode.

La mayoría de los desarrolladores y expertos en seguridad suelen centrarse en la seguridad del código de las aplicaciones, pero pueden pasar por alto los problemas de seguridad del propio compilador. De hecho, el compilador, como programa informático, también tiene vulnerabilidades de seguridad, y estas vulnerabilidades pueden representar un riesgo de seguridad grave en ciertas circunstancias. Por ejemplo, al compilar y analizar la ejecución del código JavaScript en el frontend, el navegador puede ser vulnerable a ataques que aprovechan fallos en el motor de análisis de JavaScript, lo que permite que los atacantes ejecuten código remoto al acceder a páginas web maliciosas, controlando finalmente el navegador o incluso el sistema operativo de la víctima.

El compilador de Solidity no es una excepción. Según las advertencias de seguridad del equipo de desarrollo de Solidity, existen vulnerabilidades de seguridad en varias versiones diferentes del compilador de Solidity.

Vulnerabilidad del compilador de Solidity

El papel del compilador de Solidity es convertir el código de contrato inteligente escrito por los desarrolladores en código de instrucciones de la Máquina Virtual de Ethereum (EVM). Este código de instrucciones de EVM se empaqueta y se sube a Ethereum a través de transacciones, y finalmente es analizado y ejecutado por la EVM.

Es necesario distinguir entre las vulnerabilidades del compilador de Solidity y las vulnerabilidades del propio EVM. Las vulnerabilidades del EVM se refieren a los problemas de seguridad que surgen cuando la máquina virtual ejecuta instrucciones. Dado que los atacantes pueden cargar cualquier código en Ethereum, este código finalmente se ejecutará en cada programa de cliente P2P de Ethereum, si hay vulnerabilidades de seguridad en el EVM, afectará a toda la red Ethereum, lo que podría causar un ataque de denegación de servicio completo (DoS) o incluso ser completamente controlado por los atacantes. Sin embargo, debido a que el diseño del EVM es relativamente simple y el código central no se actualiza con frecuencia, la probabilidad de que surjan los problemas mencionados es baja.

Una vulnerabilidad del compilador de Solidity se refiere a problemas que ocurren cuando el compilador convierte Solidity en código EVM. A diferencia de escenarios como los navegadores que compilan y ejecutan JavaScript en la computadora del usuario cliente, el proceso de compilación de Solidity solo se realiza en la computadora del desarrollador del contrato inteligente y no se ejecuta en Ethereum. Por lo tanto, las vulnerabilidades del compilador de Solidity no afectan a la red de Ethereum en sí.

Una de las principales amenazas de las vulnerabilidades del compilador de Solidity es que puede llevar a que el código EVM generado no coincida con las expectativas del desarrollador del contrato inteligente. Dado que los contratos inteligentes en Ethereum generalmente involucran activos de criptomonedas de los usuarios, cualquier error en el contrato inteligente causado por el compilador puede resultar en pérdidas de activos para los usuarios, lo que puede tener consecuencias graves.

Los desarrolladores y los auditores de contratos pueden enfocarse en problemas de implementación lógica del código del contrato, así como en problemas de seguridad a nivel de Solidity como reentradas y desbordamientos de enteros. Sin embargo, para las vulnerabilidades del compilador de Solidity, es difícil detectarlas solo a través de la auditoría de la lógica del código fuente del contrato. Se necesita analizar conjuntamente la versión específica del compilador y los patrones de código específicos para determinar si el contrato inteligente se ve afectado por vulnerabilidades del compilador.

Ejemplo de vulnerabilidad del compilador de Solidity

A continuación, se presentan varios casos reales de vulnerabilidades en compiladores de Solidity, que muestran su forma específica, causas y peligros.

SOL-2016-9 HighOrderByteCleanStorage

La vulnerabilidad existe en las versiones tempranas del compilador Solidity (>=0.1.6 <0.4.4).

Considera el siguiente código:

solidez contrato C { uint32 a = 0x1234; uint32 b = 0; función f() pública { a += 1; } función run() público vista devuelve (uint32) { return b; } }

la variable de almacenamiento b no ha sido modificada, por lo tanto, la función run() debería devolver el valor predeterminado 0. Sin embargo, en el código generado por el compilador de la versión con vulnerabilidades, run() devolverá 1.

Si no se comprende la vulnerabilidad del compilador, es difícil para los desarrolladores comunes detectar los errores en el código anterior mediante una revisión de código simple. Este es solo un ejemplo simple, que no causará consecuencias particularmente graves. Pero si la variable b se utiliza para la verificación de permisos, la contabilidad de activos y otros propósitos, esta inconsistencia con lo esperado podría provocar problemas muy graves.

La razón de este extraño fenómeno radica en que EVM utiliza una máquina virtual basada en pila, donde cada elemento de la pila tiene un tamaño de 32 bytes (, es decir, el tamaño de la variable uint256 ). Por otro lado, cada ranura del almacenamiento subyacente también tiene un tamaño de 32 bytes. A nivel del lenguaje Solidity, se admiten tipos de datos como uint32 y otros menores de 32 bytes; el compilador, al tratar este tipo de variables, necesita realizar las operaciones de limpieza apropiadas en los bits altos ( clean up ) para garantizar la corrección de los datos. En la situación anterior, cuando la suma produce un desbordamiento entero, el compilador no realizó correctamente la limpieza de los bits altos del resultado, lo que llevó a que el bit 1 de los bits altos se escribiera en el almacenamiento, cubriendo finalmente la variable a y modificando el valor de la variable b a 1.

SOL-2022-4 InlineAssemblyMemorySideEffects

Considera el siguiente código:

solidez contrato C { function f() public pure returns (uint) { ensamblaje { mstore(0, 0x42) } uint x; ensamblaje { x := mload(0) } return x; } }

La vulnerabilidad existe en compiladores de versiones >=0.8.13 <0.8.15. El compilador Solidity, al convertir el lenguaje Solidity en código EVM, no solo realiza una traducción simple. También lleva a cabo un análisis profundo del flujo de control y de datos, implementando varios procesos de optimización de compilación para reducir el tamaño del código generado y optimizar el consumo de gas durante el proceso de ejecución. Este tipo de operaciones de optimización son comunes en los compiladores de varios lenguajes de alto nivel, pero debido a la complejidad de los casos a considerar, también es fácil que aparezcan errores o vulnerabilidades de seguridad.

La vulnerabilidad del código anterior proviene de este tipo de operaciones de optimización. Supongamos que existe un código en una función que modifica los datos en la dirección de memoria 0, pero no hay ningún lugar posterior que use esos datos, entonces, en realidad, se puede eliminar directamente el código que modifica la memoria 0, ahorrando gas y sin afectar la lógica del programa posterior.

Esta estrategia de optimización en sí misma no tiene problema, pero en la implementación del código del compilador de Solidity, dicha optimización solo se aplica a un único bloque de assembly. En el código PoC mencionado, la escritura y el acceso a la memoria 0 se encuentran en dos bloques de assembly diferentes, mientras que el compilador solo ha realizado un análisis de optimización en el bloque de assembly por separado. Dado que en el primer bloque de assembly no hay ninguna operación de lectura después de escribir en la memoria 0, se determina que esa instrucción de escritura es redundante y se eliminará, lo que genera un bug. En la versión con vulnerabilidades, la función f( devolverá el valor 0, cuando en realidad el valor correcto que debería devolver el código mencionado es 0x42.

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Considere el siguiente código:

solidez contrato C { función f###string( calldata a[1] externo devuelve )string memoria( { return abi.decode)abi.encode(a(, )string(); } }

La vulnerabilidad afecta a los compiladores de versión >= 0.5.8 < 0.8.16. Normalmente, la variable a devuelta por el código anterior debería ser "aaaa". Pero en la versión con la vulnerabilidad, devolverá una cadena vacía "".

La causa de la vulnerabilidad es que Solidity realiza una operación abi.encode en un array de tipo calldata y, erróneamente, limpia ciertos datos, lo que provoca la modificación de otros datos adyacentes, causando inconsistencias en los datos después de la codificación y decodificación.

Es importante señalar que Solidity, al realizar llamadas externas y emitir eventos, codifica implícitamente los parámetros con abi.encode, por lo que la probabilidad de que aparezca el código de vulnerabilidad mencionado es mayor de lo que podría parecer a simple vista.

![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(

Sugerencias de seguridad

El equipo de seguridad blockchain de Cobo, tras analizar el modelo de amenazas de vulnerabilidades del compilador Solidity y revisar las vulnerabilidades históricas, presenta las siguientes recomendaciones para desarrolladores y personal de seguridad.

) Para los desarrolladores:

• Utiliza una versión más reciente del compilador Solidity. Aunque las versiones nuevas también pueden introducir nuevos problemas de seguridad, los problemas de seguridad conocidos suelen ser menos que en las versiones anteriores.

• Mejorar los casos de prueba unitarios. La mayoría de los errores a nivel de compilador pueden provocar que los resultados de la ejecución del código no coincidan con lo esperado. Este tipo de problemas son difíciles de detectar a través de revisión de código, pero son fáciles de exponer en la fase de pruebas. Por lo tanto, al aumentar la cobertura del código, se pueden evitar al máximo este tipo de problemas.

• Intente evitar el uso de ensamblaje en línea, así como operaciones complejas como la codificación y decodificación de ABI para matrices multidimensionales y estructuras complejas. Evite el uso ciego de nuevas características del lenguaje y funciones experimentales sin una necesidad clara solo para impresionar. Según el análisis del equipo de seguridad de Cobo sobre las vulnerabilidades históricas de Solidity, la mayoría de las vulnerabilidades están relacionadas con ensamblaje en línea, codificadores de ABI y otras operaciones. El compilador tiende a tener más errores al manejar características complejas del lenguaje. Por otro lado, los desarrolladores también pueden cometer errores al usar nuevas características, lo que conduce a problemas de seguridad.

para el personal de seguridad:

• Al realizar una auditoría de seguridad del código Solidity, no se deben ignorar los riesgos de seguridad que puede introducir el compilador de Solidity. En la Clasificación de Debilidades de Contratos Inteligentes ### SWC (, el ítem correspondiente de verificación es SWC-102: Versión de Compilador Obsoleta.

• En el proceso de desarrollo interno de SDL, se insta al equipo de desarrollo a actualizar la versión del compilador de Solidity, y se puede considerar introducir una verificación automática de la versión del compilador en el proceso CI/CD.

• Pero no hay que entrar en pánico excesivo por las vulnerabilidades de los compiladores; la mayoría de las vulnerabilidades de los compiladores solo se activan en patrones de código específicos, y no significa que siempre haya un riesgo de seguridad al compilar contratos con versiones vulnerables del compilador; el impacto real en la seguridad debe evaluarse de acuerdo con las circunstancias del proyecto.

) Recursos útiles:

• Publicaciones de Alertas de Seguridad del equipo de Solidity publicadas regularmente:

• Lista de errores del repositorio oficial de Solidity que se actualiza regularmente:

• Lista de errores del compilador de cada versión:

• En la página de Código del Contrato en Etherscan, el símbolo de signo de exclamación triangular en la esquina superior derecha puede indicar vulnerabilidades de seguridad existentes en la versión del compilador actual.

Resumen

Este artículo comienza con los conceptos básicos de los compiladores, presenta las vulnerabilidades del compilador de Solidity y analiza los posibles riesgos de seguridad que pueden surgir en un entorno de desarrollo de Ethereum. Por último, ofrece a los desarrolladores y al personal de seguridad varias recomendaciones prácticas de seguridad.

![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta]###https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(