Análise de vulnerabilidades do compilador Solidity e medidas de resposta

O compilador é um dos componentes básicos dos sistemas modernos de computação, cuja função é transformar o código fonte em linguagem de programação de alto nível em código de instrução executável pelo computador. Embora desenvolvedores e profissionais de segurança geralmente se preocupem com a segurança do código de aplicações, o próprio compilador, como programa de computador, também pode apresentar vulnerabilidades de segurança, o que, em certas circunstâncias, pode trazer riscos de segurança graves.

Por exemplo, quando o navegador compila e executa código JavaScript, pode haver a execução remota de código devido a vulnerabilidades no motor de análise, permitindo que um atacante ganhe controle sobre o navegador da vítima ou até mesmo sobre o sistema operacional. Além disso, pesquisas mostram que bugs em compiladores C++ também podem levar a consequências graves, como a execução remota de código.

O compilador Solidity também possui vulnerabilidades de segurança. De acordo com o alerta de segurança da equipe de desenvolvimento, problemas de segurança foram encontrados em várias versões do compilador Solidity.

O papel do compilador Solidity é transformar o código do contrato inteligente em código de instrução da Ethereum Virtual Machine (EVM). É necessário distinguir entre as vulnerabilidades do compilador Solidity e as vulnerabilidades da própria EVM. Vulnerabilidades da EVM referem-se a problemas de segurança que ocorrem durante a execução das instruções da máquina virtual, que podem afetar toda a rede Ethereum. Já as vulnerabilidades do compilador Solidity referem-se a problemas que ocorrem ao transformar Solidity em código EVM, que não afetam diretamente a rede Ethereum, mas podem levar a um código EVM gerado que não corresponde às expectativas do desenvolvedor.

Uma vez que os contratos inteligentes geralmente envolvem ativos de criptomoedas dos usuários, quaisquer bugs causados pelo compilador podem ter consequências graves. É difícil detectar vulnerabilidades do compilador apenas auditando o código-fonte do contrato, sendo necessário analisar em conjunto com versões específicas e padrões de código.

Abaixo, através de alguns casos reais, são mostradas as formas específicas, causas e perigos das vulnerabilidades do compilador Solidity.

SOL-2016-9 HighOrderByteCleanStorage

A vulnerabilidade existe em versões anteriores do compilador Solidity (>=0.1.6 <0.4.4).

Considere o seguinte código:

solidez contrato C { uint32 a = 0x1234; uint32 b = 0; função f() pública { a += 1; } função run() public view retorna (uint) { return b; } }

A variável b não foi modificada, a função run() deve retornar o valor padrão 0. Mas no código gerado pelo compilador da versão com falha, run() retornará 1.

Isto deve-se ao fato de que o EVM utiliza elementos de pilha de 32 bytes, enquanto o Solidity suporta tipos inferiores a 32 bytes, como uint32. O compilador precisa realizar uma operação de limpeza nos bits mais altos para garantir a correção dos dados. Durante um estouro de adição, o compilador não limpou corretamente os bits mais altos, resultando na gravação do bit de estouro no armazenamento, sobrescrevendo a variável b.

SOL-2022-4 Efeitos Colaterais de Memória em InlineAssembly

A vulnerabilidade existe nas versões do compilador >=0.8.13 <0.8.15.

Considere o seguinte código:

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

O compilador, durante o processo de otimização, analisa o fluxo de controle e o fluxo de dados, a fim de reduzir o tamanho do código e otimizar o consumo de gás. No entanto, essa otimização pode facilmente levar a bugs.

Neste exemplo, o compilador erroneamente considera que a escrita na memória 0 do primeiro bloco de assembly é redundante, removendo-a, o que faz com que a função f() retorne 0 em vez do correto 0x42.

SOL-2022-6 Overflow de Cabeçalho de Recodificação Abi com Limpeza de Array Estático

A vulnerabilidade afeta compiladores da versão >= 0.5.8 e < 0.8.16.

Considere o seguinte código:

solidity contrato C { função f(string[1] calldata a) pública pura retorna (string memória) { return abi.decode(abi.encode(a), (string[1]))[0]; } }

Em condições normais, esse código deve retornar o valor da variável a "aaaa". Mas na versão com vulnerabilidade retornará uma string vazia "".

Isto deve-se ao facto de o Solidity, ao realizar a operação abi.encode em arrays do tipo calldata, ter eliminado incorretamente alguns dados, resultando na modificação de dados adjacentes e causando inconsistências nos dados após a codificação e decodificação.

É importante notar que, durante chamadas externas e emissão de eventos, ocorre uma codificação implícita com abi.encode, portanto, a probabilidade de surgimento desse tipo de vulnerabilidade é bastante alta.

Sugestões de Segurança

Para os desenvolvedores:

• Utilize uma versão mais recente do compilador Solidity, os problemas de segurança conhecidos são geralmente menores.
• Melhorar os casos de teste unitários, aumentar a cobertura do código, ajuda a descobrir problemas causados pelo compilador.
• Evite o uso de assembly embutido, operações complexas de codificação e decodificação de ABI, e não utilize cegamente novos recursos e funcionalidades experimentais.

Para o pessoal de segurança:

• Não ignore os riscos que o compilador pode introduzir durante a auditoria, correspondente ao item de verificação SWC-102.
• No processo SDL, impulsionar a atualização da versão do compilador, considerando a introdução de verificações automáticas.
• Avaliar o impacto real das vulnerabilidades do compilador, sem entrar em pânico excessivo.

Alguns recursos práticos:

• Blog de alertas de segurança oficial do Solidity
• Lista de bugs no repositório Solidity
• Lista de bugs dos compiladores de várias versões
• Aviso de vulnerabilidade do compilador na página de contrato do Etherscan

Em suma, as vulnerabilidades do compilador Solidity podem levar a comportamentos reais dos contratos inteligentes que não correspondem às expectativas, e tanto desenvolvedores quanto profissionais de segurança devem estar atentos a isso e tomar as medidas adequadas para reduzir os riscos.