Investigadores da Universidade de Cambridge publicaron unha técnica para inserir silenciosamente código malicioso no código fonte revisado por pares. O método de ataque preparado (CVE-2021-42574) preséntase baixo o nome Trojan Source e baséase na formación de texto que ten un aspecto diferente para o compilador/intérprete e a persoa que ve o código. Demostráronse exemplos do método para varios compiladores e intérpretes proporcionados para C, C++ (gcc e clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go e Python.
O método baséase no uso de caracteres especiais Unicode nos comentarios de código que cambian a orde de visualización do texto bidireccional. Coa axuda destes caracteres de control, algunhas partes do texto pódense mostrar de esquerda a dereita, mentres que outras de dereita a esquerda. Na práctica cotiá, estes caracteres de control pódense usar, por exemplo, para inserir liñas de código en hebreo ou árabe nun ficheiro. Pero se combinas liñas con diferentes direccións de texto nunha mesma liña, usando os caracteres especificados, as pasaxes de texto mostradas de dereita a esquerda poden superpoñer o texto normal existente que se mostra de esquerda a dereita.
Usando este método, pode engadir unha construción maliciosa ao código, pero despois facer que o texto con esta construción sexa invisible ao ver o código, engadindo no seguinte comentario ou dentro dos caracteres literais mostrados de dereita a esquerda, o que levará a superpoñendo diferentes caracteres á inserción maliciosa. Este código permanecerá semanticamente correcto, pero interpretarase e mostrarase de forma diferente.
Mentres revisa o código, un desenvolvedor enfrontarase á orde visual dos caracteres e verá un comentario non sospeitoso nun editor de texto moderno, interface web ou IDE, pero o compilador e o intérprete utilizarán a orde lóxica dos caracteres e procesar a inserción maliciosa tal e como está, sen prestar atención ao texto bidireccional dos comentarios. O problema afecta a varios editores de código populares (VS Code, Emacs, Atom), así como interfaces para ver código en repositorios (GitHub, Gitlab, BitBucket e todos os produtos Atlassian).
Hai varias formas de usar o método para implementar accións maliciosas: engadindo unha expresión "retorno" oculta, o que leva a completar a función antes de tempo; comentando expresións que normalmente serían visibles como construcións válidas (por exemplo, para desactivar verificacións importantes); asignando outros valores de cadea que provocan erros na validación da cadea.
Por exemplo, un atacante pode propoñer un cambio que inclúa a liña: if access_level != "usuario{U+202E} {U+2066}// Comproba se admin{U+2069} {U+2066}" {
que se mostrará na interface de revisión coma se access_level != “usuario” { // Comproba se admin
Ademais, propúxose outra variante de ataque (CVE-2021-42694), asociada ao uso de homoglifos, caracteres que son exteriormente similares no seu deseño, pero que difiren no seu significado e teñen diferentes códigos Unicode (por exemplo, o carácter “ɑ” "a", "ɡ" - "g", "ɩ" - "l"). Tales símbolos pódense usar nalgunhas linguas en nomes de funcións e variables para enganar aos desenvolvedores. Por exemplo, pódense definir dúas funcións con nomes indistinguibles que realizan accións diferentes. Sen unha análise detallada, non está claro de inmediato cal destas dúas funcións se chama nun lugar específico.
Como medida de seguridade, recoméndase que os compiladores, intérpretes e ferramentas de montaxe que admitan caracteres Unicode mostren un erro ou aviso se hai caracteres de control sen emparellar nos comentarios, literais de cadea ou identificadores que cambian a dirección 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). Estes caracteres tamén deberían estar expresamente prohibidos nas especificacións da linguaxe de programación e deberían respectarse nos editores de código e nas interfaces do repositorio.
Anexo 1: Preparáronse parches de vulnerabilidade para GCC, LLVM/Clang, Rust, Go, Python e binutils. GitHub, Bitbucket e Jira tamén solucionaron o problema. Está en curso unha corrección para GitLab. Para identificar o código problemático, suxírese usar o comando: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069\uXNUMX\uXNUMXF\uXNUMXA\uXNUMXB\uXNUMXC\uXNUMXD\uXNUMXE\uXNUMX\uXNUMX\uXNUMX\uXNUMX/]' fonte
Anexo 2: Russ Cox, un dos desenvolvedores do sistema operativo Plan 9 e da linguaxe de programación Go, criticou a excesiva atención ao método de ataque descrito, que se coñece desde hai tempo (Go, Rust, C++, Ruby) e que non se toma en serio. . Segundo Cox, o problema refírese principalmente á visualización correcta da información nos editores de código e nas interfaces web, que se pode resolver utilizando as ferramentas e analizadores de código correctos durante a revisión. Polo tanto, en lugar de chamar a atención sobre ataques especulativos, sería máis apropiado centrarse na mellora dos procesos de revisión de código e dependencia.
Ras Cox tamén considera que os compiladores non son o lugar axeitado para solucionar o problema, xa que ao prohibir símbolos perigosos a nivel de compilador, queda unha enorme capa de ferramentas nas que o uso destes símbolos segue sendo aceptable, como sistemas de compilación, ensambladores, etc. xestores de paquetes e varios analizadores de configuración e datos. Como exemplo, dáse o proxecto Rust, que prohibiu o procesamento de código LTR/RTL no compilador, pero non engadiu unha corrección ao xestor de paquetes Cargo, que permite un ataque similar a través do ficheiro Cargo.toml. Do mesmo xeito, ficheiros como BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml e requirements.txt poden converterse en fontes de ataques.
Fonte: opennet.ru