Pesquisadores da Universidade de Cambridge publicaram uma técnica para inserir silenciosamente código malicioso em código-fonte revisado por pares. O método de ataque preparado (CVE-2021-42574) é apresentado sob o nome Trojan Source e é baseado na formação de texto que parece diferente para o compilador/interpretador e para a pessoa que visualiza o código. Exemplos do método são demonstrados para vários compiladores e interpretadores fornecidos para C, C++ (gcc e clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go e Python.
O método é baseado no uso de caracteres Unicode especiais em comentários de código que alteram a ordem de exibição do texto bidirecional. Com a ajuda de tais caracteres de controle, algumas partes do texto podem ser exibidas da esquerda para a direita, enquanto outras - da direita para a esquerda. Na prática cotidiana, esses caracteres de controle podem ser usados, por exemplo, para inserir linhas de código em hebraico ou árabe em um arquivo. Mas se você combinar linhas com diferentes direções de texto em uma linha, usando os caracteres especificados, as passagens de texto exibidas da direita para a esquerda poderão se sobrepor ao texto normal existente exibido da esquerda para a direita.
Usando este método, você pode adicionar uma construção maliciosa ao código, mas depois tornar o texto com esta construção invisível ao visualizar o código, adicionando no comentário a seguir ou dentro dos caracteres literais mostrados da direita para a esquerda, o que levará a completamente diferentes caracteres sendo sobrepostos na inserção maliciosa. Esse código permanecerá semanticamente correto, mas será interpretado e exibido de forma diferente.
Ao revisar o código, um desenvolvedor será confrontado com a ordem visual dos caracteres e verá um comentário não suspeito em um editor de texto moderno, interface web ou IDE, mas o compilador e o interpretador usarão a ordem lógica dos caracteres e irão processar a inserção maliciosa como está, sem prestar atenção ao texto bidirecional nos comentários. O problema afeta vários editores de código populares (VS Code, Emacs, Atom), bem como interfaces para visualização de código em repositórios (GitHub, Gitlab, BitBucket e todos os produtos Atlassian).
Existem várias maneiras de usar o método para implementar ações maliciosas: adicionar uma expressão de “retorno” oculta, que leva à conclusão da função antes do tempo; comentar expressões que normalmente seriam visíveis como construções válidas (por exemplo, para desabilitar verificações importantes); atribuir outros valores de string que levam a falhas na validação de string.
Por exemplo, um invasor pode propor uma alteração que inclua a linha: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
que será exibido na interface de revisão como se access_level != “user” { // Verifique se admin
Além disso, foi proposta outra variante de ataque (CVE-2021-42694), associada ao uso de homóglifos, caracteres que são semelhantes na aparência, mas diferem no significado e possuem códigos Unicode diferentes (por exemplo, o caractere “ɑ” lembra “ a”, “ɡ” - “g”, “ɩ” - “l”). Caracteres semelhantes podem ser usados em algumas linguagens em nomes de funções e variáveis para enganar os desenvolvedores. Por exemplo, podem ser definidas duas funções com nomes indistinguíveis que executam ações diferentes. Sem uma análise detalhada, não fica imediatamente claro qual dessas duas funções é chamada em um local específico.
Como medida de segurança, é recomendado que compiladores, interpretadores e ferramentas de montagem que suportam caracteres Unicode exibam um erro ou aviso se houver caracteres de controle não pareados em comentários, literais de string ou identificadores que alteram a direção da saída (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E e U+200F). Tais caracteres também devem ser explicitamente proibidos nas especificações de linguagens de programação e devem ser respeitados em editores de código e interfaces de repositórios.
Adendo 1: Patches de vulnerabilidade foram preparados para GCC, LLVM/Clang, Rust, Go, Python e binutils. GitHub, Bitbucket e Jira também corrigiram o problema. Uma correção para o GitLab está em andamento. Para identificar o código problemático, sugere-se usar o comando: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202B\u202C\u202D\u2066E\u2067\u2068\u2069\uXNUMX]' /path/to/ fonte
Adendo 2: Russ Cox, um dos desenvolvedores do sistema operacional Plan 9 e da linguagem de programação Go, criticou a atenção excessiva ao método de ataque descrito, que é conhecido há muito tempo (Go, Rust, C++, Ruby) e não foi levado a sério . Segundo Cox, o problema diz respeito principalmente à exibição correta das informações em editores de código e interfaces web, o que pode ser resolvido com o uso de ferramentas e analisadores de código corretos durante a revisão. Portanto, em vez de chamar a atenção para ataques especulativos, seria mais apropriado focar na melhoria dos processos de revisão de código e dependências.
Ras Cox também acredita que os compiladores não são o lugar certo para resolver o problema, pois ao banir símbolos perigosos no nível do compilador, resta uma enorme camada de ferramentas nas quais o uso desses símbolos permanece aceitável, como sistemas de construção, montadores, gerenciadores de pacotes e vários analisadores de configuração e dados. Como exemplo, é dado o projeto Rust, que proibiu o processamento de código LTR/RTL no compilador, mas não adicionou uma correção ao gerenciador de pacotes Cargo, que permite um ataque semelhante através do arquivo Cargo.toml. Da mesma forma, arquivos como BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml e requisitos.txt podem se tornar fontes de ataques.
Fonte: opennet.ru