Pesquisadores da Universidade de Cambridge publicaram uma técnica para a inserção invisível de código malicioso em textos-fonte revisados. O método de ataque desenvolvido (CVE-2021-42574) é chamado de Trojan Source e baseia-se na geração de texto que se apresenta de maneira diferente para o compilador/interpreter e para a pessoa que lê o código. Exemplos de aplicação do método foram demonstrados para diversos compiladores e intérpretes utilizados em linguagens como C, C++ (gcc e clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go e Python.
O método baseia-se no uso de caracteres Unicode especiais nos comentários do código que alteram a ordem de exibição do texto bidirecional. Com esses caracteres de controle, partes do texto podem ser exibidas da esquerda para a direita, enquanto outras podem ser exibidas da direita para a esquerda. Na prática, esses caracteres de controle podem ser usados, por exemplo, para inserir linhas em hebraico ou árabe em um arquivo de código. No entanto, ao combinar strings com diferentes direções de texto em uma única linha, os caracteres mencionados podem fazer com que trechos exibidos da direita para a esquerda sobreponham o texto normal exibido da esquerda para a direita.
Usando esse método, é possível adicionar uma construção maliciosa ao código, mas em seguida tornar o texto com essa construção invisível ao visualizar o código, ao adicionar em um comentário subsequente ou dentro de um literal caracteres que são exibidos da direita para a esquerda, o que resultará na sobreposição da inserção maliciosa por caracteres completamente diferentes. Esse código permanecerá semanticamente correto, mas será interpretado e exibido de maneira diferente.
Durante a revisão do código, o desenvolvedor encontrará a ordem visual de exibição dos caracteres e verá um comentário que não desperta suspeitas 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 processarão a inserção maliciosa como está, sem prestar atenção ao texto bidirecional no comentário. Vários editores de código populares (VS Code, Emacs, Atom) e interfaces para visualização de código em repositórios (GitHub, Gitlab, BitBucket e todos os produtos Atlassian) estão vulneráveis a esse problema.
Destacam-se várias formas de utilização do método para a realização de ações maliciosas: adição de uma expressão oculta 'return', que leva ao término da execução da função precocemente; comentário de expressões que normalmente seriam visíveis como construções válidas (por exemplo, para desativar verificações importantes); atribuição de outros valores de string que resultam em falhas de verificação.
Por exemplo, o atacante pode propor uma modificação que inclua a linha: if access_level != 'user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}' {
que será exibida na interface para revisão como if access_level != 'user' { // Check if admin
Adicionalmente, foi proposta mais uma variante de ataque (CVE-2021-42694), relacionada ao uso de homógrafos, símbolos que parecem semelhantes em aparência, mas diferem em significado e possuem códigos unicode diferentes (por exemplo, o símbolo 'ɑ' se assemelha ao 'a', 'ɡ' se assemelha ao 'g', 'ɩ' se assemelha ao 'l'). Esses símbolos podem ser usados em algumas linguagens nos nomes de funções e variáveis para induzir os desenvolvedores ao erro. Por exemplo, podem ser definidas duas funções com nomes indistinguíveis, mas que realizam ações diferentes. Sem uma análise detalhada, não é possível saber imediatamente qual dessas duas funções é chamada em um local específico.
Como medida de proteção, recomenda-se implementar, em compiladores, interpretadores e ferramentas de construção que suportam símbolos Unicode, uma saída de erro ou aviso na presença de caracteres de controle ímpares que mudam 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) em comentários, literais de string ou identificadores. Esses símbolos também devem ser explicitamente proibidos nas especificações das linguagens de programação e devem ser levados em consideração em editores de código e interfaces para trabalho com repositórios.
Adendo 1: Correções para a vulnerabilidade foram preparadas para GCC, LLVM/Clang, Rust, Go, Python e binutils. A questão também foi resolvida pelo GitHub, Bitbucket e Jira. Está em andamento a preparação de uma correção para o GitLab. Para detectar o código problemático, foi sugerido usar o comando: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Adendo 2: Russ Cox, um dos desenvolvedores do sistema operacional Plan 9 e da linguagem de programação Go, criticou a atenção excessiva dada ao método de ataque descrito, que já é amplamente conhecido (Go, Rust, C++, Ruby) e não é levado a sério. De acordo com Cox, o problema se refere principalmente à precisão da exibição de informações em editores de código e interfaces web, o que pode ser resolvido utilizando ferramentas e analisadores de código apropriados durante a revisão. Portanto, em vez de chamar a atenção para ataques puramente teóricos, seria mais apropriado focar na melhoria dos processos de revisão de código e dependências.
Russ Cox também acredita que os compiladores não são o local adequado para resolver o problema, já que ao proibir caracteres perigosos no nível do compilador, ainda haverá um grande número de ferramentas onde o uso desses caracteres permanece permitido, como sistemas de build, assembladores, gerenciadores de pacotes e diversos parsers de configuração e dados. Por exemplo, o projeto Rust proibiu o processamento de código LTR/RTL no compilador, mas não incluiu uma correção no gerenciador de pacotes Cargo, o que permite realizar um ataque semelhante através do arquivo Cargo.toml. Da mesma forma, fontes de ataque podem ser arquivos como BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml e requirements.txt.
Fonte: opennet.ru
