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 es convertir el código fuente de lenguajes de programación de alto nivel, que son fáciles de entender y escribir para los humanos, en código de instrucciones ejecutables por la CPU o una máquina virtual de bytes.
La mayoría de los desarrolladores y personal de seguridad suelen centrarse en la seguridad del código de las aplicaciones, pero pueden pasar por alto la seguridad del propio compilador. De hecho, el compilador, como programa informático, también puede tener vulnerabilidades de seguridad, y las vulnerabilidades de seguridad generadas por el compilador pueden conllevar riesgos de seguridad graves en ciertas situaciones. Por ejemplo, durante el proceso de compilación y análisis de la ejecución del código front-end de Javascript, es posible que, debido a vulnerabilidades en el motor de análisis de Javascript, un atacante pueda aprovechar una vulnerabilidad cuando un usuario accede a una página web maliciosa, lo que permite la ejecución remota de código y, en última instancia, el control del navegador o incluso del sistema operativo de la víctima. Estudios han demostrado que los errores en el compilador Clang C++ también pueden llevar a consecuencias graves, como la ejecución remota de código.
El compilador de Solidity no es una excepción, según la alerta de seguridad del equipo de desarrollo de Solidity, hay vulnerabilidades de seguridad en varias versiones diferentes del compilador de Solidity.
Vulnerabilidades del compilador de Solidity
El papel del compilador de Solidity es convertir el código de contratos inteligentes escrito por los desarrolladores en código de instrucciones de la Máquina Virtual de Ethereum (EVM). Este código de instrucciones EVM se empaqueta a través de transacciones y se carga en Ethereum, donde finalmente es analizado y ejecutado por la EVM.
Es necesario distinguir entre las vulnerabilidades del compilador de Solidity y las vulnerabilidades del EVM en sí. Las vulnerabilidades del EVM se refieren a los fallos de seguridad que ocurren cuando la máquina virtual ejecuta instrucciones. Dado que los atacantes pueden subir cualquier código a Ethereum, este código finalmente se ejecutará en cada programa cliente P2P de Ethereum, si hay vulnerabilidades de seguridad en el EVM, afectará a toda la red de Ethereum, lo que podría causar un ataque de denegación de servicio (DoS) e incluso permitir que un atacante controle completamente toda la cadena. 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 ocurran los problemas anteriores es relativamente baja.
Las vulnerabilidades del compilador de Solidity se refieren a fallos que ocurren cuando el compilador convierte Solidity en código EVM. A diferencia de escenarios donde navegadores y otros programas compilan y ejecutan Javascript en la computadora del usuario, el proceso de compilación de Solidity solo ocurre en la computadora del desarrollador de contratos inteligentes y no se ejecuta en Ethereum. Por lo tanto, las vulnerabilidades del compilador de Solidity no afectan directamente a la red de Ethereum.
Una de las principales amenazas de las vulnerabilidades del compilador de Solidity es que pueden 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 suelen involucrar los activos de criptomonedas de los usuarios, cualquier error que el compilador cause en los contratos inteligentes podría resultar en pérdidas de activos para los usuarios, lo que conlleva graves consecuencias.
Los desarrolladores y los auditores de contratos pueden centrarse en los problemas de implementación de la lógica del código del contrato, así como en problemas de seguridad a nivel de Solidity, como la reentrada y el desbordamiento de enteros. Sin embargo, es difícil detectar vulnerabilidades del compilador de Solidity solo a través de la auditoría de la lógica del código fuente del contrato. Es necesario analizar conjuntamente versiones específicas del compilador y patrones de código específicos para determinar si el contrato inteligente se ve afectado por vulnerabilidades del compilador.
Ejemplo de vulnerabilidad del compilador Solidity
A continuación, se presentan varios casos reales de vulnerabilidades en compiladores de Solidity, que muestran las formas específicas, causas y daños de las vulnerabilidades en los compiladores de Solidity.
SOL-2016-9 HighOrderByteCleanStorage
La vulnerabilidad existe en versiones anteriores del compilador Solidity ( >=0.1.6 <0.4.4).
Considera el siguiente código:
solidez
contrato C {
uint32 a = 0x12345678;
uint16 b = 0x1234;
función f() pública {
a = a + 1;
}
function run() public view returns (uint16) {
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 la versión del compilador con vulnerabilidades, run() devolverá 1.
Sin entender la vulnerabilidad del compilador, es difícil para un desarrollador común descubrir el bug presente en el código mencionado a través de una simple revisión de código. El código anterior es solo un ejemplo simple, por lo que no causará un daño especialmente grave. Pero si la variable b se utiliza para la verificación de permisos, contabilidad de activos, etc., esta inconsistencia con lo esperado podría llevar a consecuencias muy graves.
La razón de la anomalía mencionada anteriormente es que EVM utiliza una máquina virtual basada en pilas, cada elemento en la pila tiene un tamaño de 32 bytes (, es decir, el tamaño de la variable uint256 ). Por otro lado, cada slot de almacenamiento subyacente también tiene un tamaño de 32 bytes. Sin embargo, el lenguaje Solidity admite tipos de datos menores de 32 bytes como uint32, y el compilador, al manejar este tipo de variables, necesita realizar una limpieza adecuada de los bits altos (clean up) para garantizar la corrección de los datos. En la situación anterior, cuando la suma produce un desbordamiento de enteros, el compilador no realizó correctamente la limpieza de los bits altos del resultado, lo que provocó que el bit de 1 en la parte alta se escribiera en el almacenamiento, sobrescribiendo finalmente la variable a y modificando el valor de la variable b a 1.
SOL-2022-4 InlineAssemblyMemorySideEffects
La vulnerabilidad existe en los compiladores de la versión >=0.8.13 <0.8.15. El compilador de Solidity, al convertir el lenguaje Solidity en código EVM, no es solo una traducción simple. También realiza un análisis profundo del flujo de control y de los 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 operación de optimización es común en los compiladores de varios lenguajes de alto nivel, pero dado que hay muchas situaciones que considerar, también es propensa a errores o vulnerabilidades de seguridad.
Considera el siguiente código:
solidez
contrato C {
function f() public pure returns (uint256) {
ensamblaje {
mstore(0, 0x42)
}
uint256 x;
ensamblaje {
x := mload(0)
}
return x;
}
}
La vulnerabilidad del código anterior proviene de la optimización de compilación. En ciertos casos, si hay código en la función que modifica los datos en la dirección de memoria 0, pero en ninguna parte posterior se utiliza esos datos, es posible 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 problemas, pero en la implementación del código del compilador de Solidity, dicha optimización solo se aplica dentro de un único bloque de assembly. En el código de ejemplo anterior, 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 un bloque de assembly individual. 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, por lo que se eliminará, lo que generará un error. En la versión con vulnerabilidades, la función f( devolverá el valor 0, mientras que en realidad el código anterior debería devolver el valor correcto 0x42.
La vulnerabilidad afecta a compiladores de versiones >= 0.5.8 < 0.8.16. Considere el siguiente código:
solidez
contrato C {
function f###bytes calldata data( external pure returns )bytes memory( {
bytes4) memoria a = [bytes4[1]data(];
return abi.encode)a(;
}
}
En condiciones normales, el código anterior debería devolver que la variable a es "aaaa". Pero en la versión con vulnerabilidades, devolverá una cadena vacía "".
La causa de la vulnerabilidad es que Solidity, al realizar la operación abi.encode en un array de tipo calldata, realiza incorrectamente una limpieza de ciertos datos, lo que provoca la modificación de otros datos adyacentes, causando una inconsistencia en los datos después de la codificación y decodificación.
Es importante señalar que, al realizar llamadas externas y emitir eventos, Solidity 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.
La vulnerabilidad se adaptó a un conocido problema de blockchain en la competencia de seguridad 0ctf 2022, mostrando el impacto de las vulnerabilidades del compilador en los contratos inteligentes en un escenario de desarrollo real.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(
Consejos de seguridad
Para las amenazas y respuestas a las vulnerabilidades del compilador Solidity, se pueden dar las siguientes recomendaciones:
Para desarrolladores:
Utilice una versión más reciente del compilador de Solidity. Aunque las nuevas versiones 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 sean coherentes con lo esperado. Este tipo de problemas son difíciles de detectar mediante revisiones de código, pero son fáciles de exponer en la fase de pruebas. Por lo tanto, aumentar la cobertura del código puede evitar en gran medida este tipo de problemas.
Evitar en la medida de lo posible el uso de ensamblaje en línea, la codificación y decodificación de ABI para arreglos multidimensionales y estructuras complejas, y otras operaciones complejas. No utilizar características nuevas del lenguaje y funciones experimentales sin una necesidad clara. La mayoría de las vulnerabilidades están relacionadas con operaciones como el ensamblaje en línea y los codificadores de ABI. Los compiladores son más propensos a errores al manejar características complejas del lenguaje. Por otro lado, los desarrolladores también pueden caer en errores al usar nuevas características, lo que puede llevar 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. El ítem correspondiente en la Clasificación de Debilidades de Contratos Inteligentes ) SWC ( es SWC-102: Versión de Compilador Obsoleta.
En el proceso de desarrollo de seguridad interna, se insta al equipo de desarrollo a actualizar la versión del compilador de Solidity y considerar la incorporación de una verificación automática de la versión del compilador en el proceso de CI/CD.
Pero no es necesario preocuparse demasiado por las vulnerabilidades del compilador, la mayoría de las vulnerabilidades del compilador solo se activan en patrones de código específicos. Los contratos compilados con versiones vulnerables del compilador no necesariamente presentan un riesgo de seguridad, es necesario evaluar el impacto real de seguridad según las circunstancias específicas del proyecto.
Algunos recursos útiles:
Alertas de seguridad publicadas regularmente por el equipo de Solidity:
Lista de errores actualizada periódicamente del repositorio oficial de Solidity:
Lista de errores de compiladores de varias versiones:
En Etherscan, el signo de exclamación en triángulo en la esquina superior derecha de la página del contrato -> Código puede indicar vulnerabilidades de seguridad en la versión del compilador actual.
Resumen
Este artículo presenta el concepto de vulnerabilidades en el compilador de Solidity, analiza los riesgos de seguridad que pueden surgir en el entorno de desarrollo de Ethereum y proporciona recomendaciones prácticas de seguridad para desarrolladores y personal de seguridad. Aunque las vulnerabilidades en el compilador no son comunes, su impacto puede ser grave, lo que merece la atención de desarrolladores y personal de seguridad.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
22 me gusta
Recompensa
22
7
Republicar
Compartir
Comentar
0/400
fork_in_the_road
· 07-19 10:48
¿También puede haber vulnerabilidades en el compilador? ¡¿Por qué tanto miedo?!
Ver originalesResponder0
gas_fee_therapist
· 07-19 08:57
Esta vulnerabilidad está escrita de manera bastante clara~
Ver originalesResponder0
GateUser-75ee51e7
· 07-18 18:19
Es mejor encontrar un bug que hacer minería.
Ver originalesResponder0
MetaverseHobo
· 07-16 19:40
¿También falló el compilador? Esta vez estamos preocupados.
Ver originalesResponder0
DeepRabbitHole
· 07-16 19:39
¡Qué mal! ¿Hay tantos errores y aún así juegan a la posición de bloqueo?
Ver originalesResponder0
GasWaster
· 07-16 19:37
¿También hay vulnerabilidades en el compilador? yyds
Ver originalesResponder0
ForkTongue
· 07-16 19:23
Robar dinero con una tarjeta de vulnerabilidad es lo más confiable.
Análisis de vulnerabilidades del compilador Solidity: impacto, casos y estrategias de respuesta
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 es convertir el código fuente de lenguajes de programación de alto nivel, que son fáciles de entender y escribir para los humanos, en código de instrucciones ejecutables por la CPU o una máquina virtual de bytes.
La mayoría de los desarrolladores y personal de seguridad suelen centrarse en la seguridad del código de las aplicaciones, pero pueden pasar por alto la seguridad del propio compilador. De hecho, el compilador, como programa informático, también puede tener vulnerabilidades de seguridad, y las vulnerabilidades de seguridad generadas por el compilador pueden conllevar riesgos de seguridad graves en ciertas situaciones. Por ejemplo, durante el proceso de compilación y análisis de la ejecución del código front-end de Javascript, es posible que, debido a vulnerabilidades en el motor de análisis de Javascript, un atacante pueda aprovechar una vulnerabilidad cuando un usuario accede a una página web maliciosa, lo que permite la ejecución remota de código y, en última instancia, el control del navegador o incluso del sistema operativo de la víctima. Estudios han demostrado que los errores en el compilador Clang C++ también pueden llevar a consecuencias graves, como la ejecución remota de código.
El compilador de Solidity no es una excepción, según la alerta de seguridad del equipo de desarrollo de Solidity, hay vulnerabilidades de seguridad en varias versiones diferentes del compilador de Solidity.
Vulnerabilidades del compilador de Solidity
El papel del compilador de Solidity es convertir el código de contratos inteligentes escrito por los desarrolladores en código de instrucciones de la Máquina Virtual de Ethereum (EVM). Este código de instrucciones EVM se empaqueta a través de transacciones y se carga en Ethereum, donde finalmente es analizado y ejecutado por la EVM.
Es necesario distinguir entre las vulnerabilidades del compilador de Solidity y las vulnerabilidades del EVM en sí. Las vulnerabilidades del EVM se refieren a los fallos de seguridad que ocurren cuando la máquina virtual ejecuta instrucciones. Dado que los atacantes pueden subir cualquier código a Ethereum, este código finalmente se ejecutará en cada programa cliente P2P de Ethereum, si hay vulnerabilidades de seguridad en el EVM, afectará a toda la red de Ethereum, lo que podría causar un ataque de denegación de servicio (DoS) e incluso permitir que un atacante controle completamente toda la cadena. 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 ocurran los problemas anteriores es relativamente baja.
Las vulnerabilidades del compilador de Solidity se refieren a fallos que ocurren cuando el compilador convierte Solidity en código EVM. A diferencia de escenarios donde navegadores y otros programas compilan y ejecutan Javascript en la computadora del usuario, el proceso de compilación de Solidity solo ocurre en la computadora del desarrollador de contratos inteligentes y no se ejecuta en Ethereum. Por lo tanto, las vulnerabilidades del compilador de Solidity no afectan directamente a la red de Ethereum.
Una de las principales amenazas de las vulnerabilidades del compilador de Solidity es que pueden 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 suelen involucrar los activos de criptomonedas de los usuarios, cualquier error que el compilador cause en los contratos inteligentes podría resultar en pérdidas de activos para los usuarios, lo que conlleva graves consecuencias.
Los desarrolladores y los auditores de contratos pueden centrarse en los problemas de implementación de la lógica del código del contrato, así como en problemas de seguridad a nivel de Solidity, como la reentrada y el desbordamiento de enteros. Sin embargo, es difícil detectar vulnerabilidades del compilador de Solidity solo a través de la auditoría de la lógica del código fuente del contrato. Es necesario analizar conjuntamente versiones específicas del compilador y patrones de código específicos para determinar si el contrato inteligente se ve afectado por vulnerabilidades del compilador.
Ejemplo de vulnerabilidad del compilador Solidity
A continuación, se presentan varios casos reales de vulnerabilidades en compiladores de Solidity, que muestran las formas específicas, causas y daños de las vulnerabilidades en los compiladores de Solidity.
SOL-2016-9 HighOrderByteCleanStorage
La vulnerabilidad existe en versiones anteriores del compilador Solidity ( >=0.1.6 <0.4.4).
Considera el siguiente código:
solidez contrato C { uint32 a = 0x12345678; uint16 b = 0x1234;
función f() pública { a = a + 1; }
function run() public view returns (uint16) { 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 la versión del compilador con vulnerabilidades, run() devolverá 1.
Sin entender la vulnerabilidad del compilador, es difícil para un desarrollador común descubrir el bug presente en el código mencionado a través de una simple revisión de código. El código anterior es solo un ejemplo simple, por lo que no causará un daño especialmente grave. Pero si la variable b se utiliza para la verificación de permisos, contabilidad de activos, etc., esta inconsistencia con lo esperado podría llevar a consecuencias muy graves.
La razón de la anomalía mencionada anteriormente es que EVM utiliza una máquina virtual basada en pilas, cada elemento en la pila tiene un tamaño de 32 bytes (, es decir, el tamaño de la variable uint256 ). Por otro lado, cada slot de almacenamiento subyacente también tiene un tamaño de 32 bytes. Sin embargo, el lenguaje Solidity admite tipos de datos menores de 32 bytes como uint32, y el compilador, al manejar este tipo de variables, necesita realizar una limpieza adecuada de los bits altos (clean up) para garantizar la corrección de los datos. En la situación anterior, cuando la suma produce un desbordamiento de enteros, el compilador no realizó correctamente la limpieza de los bits altos del resultado, lo que provocó que el bit de 1 en la parte alta se escribiera en el almacenamiento, sobrescribiendo finalmente la variable a y modificando el valor de la variable b a 1.
SOL-2022-4 InlineAssemblyMemorySideEffects
La vulnerabilidad existe en los compiladores de la versión >=0.8.13 <0.8.15. El compilador de Solidity, al convertir el lenguaje Solidity en código EVM, no es solo una traducción simple. También realiza un análisis profundo del flujo de control y de los 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 operación de optimización es común en los compiladores de varios lenguajes de alto nivel, pero dado que hay muchas situaciones que considerar, también es propensa a errores o vulnerabilidades de seguridad.
Considera el siguiente código:
solidez contrato C { function f() public pure returns (uint256) { ensamblaje { mstore(0, 0x42) } uint256 x; ensamblaje { x := mload(0) } return x; } }
La vulnerabilidad del código anterior proviene de la optimización de compilación. En ciertos casos, si hay código en la función que modifica los datos en la dirección de memoria 0, pero en ninguna parte posterior se utiliza esos datos, es posible 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 problemas, pero en la implementación del código del compilador de Solidity, dicha optimización solo se aplica dentro de un único bloque de assembly. En el código de ejemplo anterior, 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 un bloque de assembly individual. 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, por lo que se eliminará, lo que generará un error. En la versión con vulnerabilidades, la función f( devolverá el valor 0, mientras que en realidad el código anterior debería devolver el valor correcto 0x42.
) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
La vulnerabilidad afecta a compiladores de versiones >= 0.5.8 < 0.8.16. Considere el siguiente código:
solidez contrato C { function f###bytes calldata data( external pure returns )bytes memory( { bytes4) memoria a = [bytes4[1]data(]; return abi.encode)a(; } }
En condiciones normales, el código anterior debería devolver que la variable a es "aaaa". Pero en la versión con vulnerabilidades, devolverá una cadena vacía "".
La causa de la vulnerabilidad es que Solidity, al realizar la operación abi.encode en un array de tipo calldata, realiza incorrectamente una limpieza de ciertos datos, lo que provoca la modificación de otros datos adyacentes, causando una inconsistencia en los datos después de la codificación y decodificación.
Es importante señalar que, al realizar llamadas externas y emitir eventos, Solidity 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.
La vulnerabilidad se adaptó a un conocido problema de blockchain en la competencia de seguridad 0ctf 2022, mostrando el impacto de las vulnerabilidades del compilador en los contratos inteligentes en un escenario de desarrollo real.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(
Consejos de seguridad
Para las amenazas y respuestas a las vulnerabilidades del compilador Solidity, se pueden dar las siguientes recomendaciones:
Para desarrolladores:
Utilice una versión más reciente del compilador de Solidity. Aunque las nuevas versiones 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 sean coherentes con lo esperado. Este tipo de problemas son difíciles de detectar mediante revisiones de código, pero son fáciles de exponer en la fase de pruebas. Por lo tanto, aumentar la cobertura del código puede evitar en gran medida este tipo de problemas.
Evitar en la medida de lo posible el uso de ensamblaje en línea, la codificación y decodificación de ABI para arreglos multidimensionales y estructuras complejas, y otras operaciones complejas. No utilizar características nuevas del lenguaje y funciones experimentales sin una necesidad clara. La mayoría de las vulnerabilidades están relacionadas con operaciones como el ensamblaje en línea y los codificadores de ABI. Los compiladores son más propensos a errores al manejar características complejas del lenguaje. Por otro lado, los desarrolladores también pueden caer en errores al usar nuevas características, lo que puede llevar 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. El ítem correspondiente en la Clasificación de Debilidades de Contratos Inteligentes ) SWC ( es SWC-102: Versión de Compilador Obsoleta.
En el proceso de desarrollo de seguridad interna, se insta al equipo de desarrollo a actualizar la versión del compilador de Solidity y considerar la incorporación de una verificación automática de la versión del compilador en el proceso de CI/CD.
Pero no es necesario preocuparse demasiado por las vulnerabilidades del compilador, la mayoría de las vulnerabilidades del compilador solo se activan en patrones de código específicos. Los contratos compilados con versiones vulnerables del compilador no necesariamente presentan un riesgo de seguridad, es necesario evaluar el impacto real de seguridad según las circunstancias específicas del proyecto.
Algunos recursos útiles:
Alertas de seguridad publicadas regularmente por el equipo de Solidity:
Lista de errores actualizada periódicamente del repositorio oficial de Solidity:
Lista de errores de compiladores de varias versiones:
En Etherscan, el signo de exclamación en triángulo en la esquina superior derecha de la página del contrato -> Código puede indicar vulnerabilidades de seguridad en la versión del compilador actual.
Resumen
Este artículo presenta el concepto de vulnerabilidades en el compilador de Solidity, analiza los riesgos de seguridad que pueden surgir en el entorno de desarrollo de Ethereum y proporciona recomendaciones prácticas de seguridad para desarrolladores y personal de seguridad. Aunque las vulnerabilidades en el compilador no son comunes, su impacto puede ser grave, lo que merece la atención de desarrolladores y personal de seguridad.
![Análisis de vulnerabilidades del compilador Solidity y medidas de respuesta])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(