Investigadores de la Universidad de Cambridge han publicado una técnica para insertar silenciosamente código malicioso en código fuente revisado por pares. El método de ataque preparado (CVE-2021-42574) se presenta bajo el nombre Trojan Source y se basa en la formación de texto que tiene un aspecto diferente para el compilador/intérprete y la persona que ve el código. Se muestran ejemplos del método para varios compiladores e intérpretes suministrados para C, C++ (gcc y clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go y Python.
El método se basa en el uso de caracteres Unicode especiales en comentarios de código que cambian el orden de visualización del texto bidireccional. Con la ayuda de estos caracteres de control, algunas partes del texto se pueden mostrar de izquierda a derecha, mientras que otras, de derecha a izquierda. En la práctica diaria, estos caracteres de control se pueden utilizar, por ejemplo, para insertar líneas de código en hebreo o árabe en un archivo. Pero si combina líneas de diferentes direcciones de texto en una línea usando los caracteres especificados, los pasajes de texto que se muestran de derecha a izquierda pueden superponerse al texto normal existente que se muestra de izquierda a derecha.
Con este método, puede agregar una construcción maliciosa al código, pero luego hacer que el texto con esta construcción sea invisible al ver el código, agregando el siguiente comentario o dentro de los caracteres literales que se muestran de derecha a izquierda, lo que conducirá a una completa Se superponen diferentes caracteres en la inserción maliciosa. Dicho código seguirá siendo semánticamente correcto, pero se interpretará y mostrará de forma diferente.
Mientras revisa el código, un desarrollador se enfrentará al orden visual de los caracteres y verá un comentario no sospechoso en un editor de texto, interfaz web o IDE moderno, pero el compilador y el intérprete utilizarán el orden lógico de los caracteres y procese la inserción maliciosa tal cual, sin prestar atención al texto bidireccional en los comentarios. El problema afecta a varios editores de código populares (VS Code, Emacs, Atom), así como a interfaces para ver código en repositorios (GitHub, Gitlab, BitBucket y todos los productos Atlassian).
Hay varias formas de utilizar el método para implementar acciones maliciosas: agregar una expresión de "retorno" oculta, que lleva a la finalización de la función antes de tiempo; comentar expresiones que normalmente serían visibles como construcciones válidas (por ejemplo, para desactivar comprobaciones importantes); asignar otros valores de cadena que conducen a fallas en la validación de cadenas.
Por ejemplo, un atacante podría proponer un cambio que incluya la línea: if nivel_acceso != "usuario{U+202E} {U+2066}// Compruebe si admin{U+2069} {U+2066}" {
que se mostrará en la interfaz de revisión como si nivel_acceso! = “usuario” { // Verifique si es administrador
Además, se ha propuesto otra variante de ataque (CVE-2021-42694), asociada al uso de homoglifos, caracteres que son similares en apariencia, pero difieren en significado y tienen diferentes códigos Unicode (por ejemplo, el carácter “ɑ” se parece a “ a”, “ɡ” - “g”, “ɩ” - “l”). En algunos idiomas se pueden utilizar caracteres similares en los nombres de funciones y variables para engañar a los desarrolladores. Por ejemplo, se pueden definir dos funciones con nombres indistinguibles que realicen acciones diferentes. Sin un análisis detallado, no queda inmediatamente claro cuál de estas dos funciones se llama en un lugar específico.
Como medida de seguridad, se recomienda que los compiladores, intérpretes y herramientas de ensamblaje que admiten caracteres Unicode muestren un error o advertencia si hay caracteres de control no emparejados en comentarios, literales de cadena o identificadores que cambian la dirección de salida (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E y U+200F). Estos caracteres también deberían estar prohibidos explícitamente en las especificaciones del lenguaje de programación y deberían respetarse en los editores de código y las interfaces de repositorio.
Anexo 1: Se han preparado parches de vulnerabilidad para GCC, LLVM/Clang, Rust, Go, Python y binutils. GitHub, Bitbucket y Jira también solucionaron el problema. Se está realizando una solución para GitLab. Para identificar el código problemático, se sugiere utilizar el comando: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ fuente
Anexo 2: Russ Cox, uno de los desarrolladores del sistema operativo Plan 9 y del lenguaje de programación Go, criticó la excesiva atención prestada al método de ataque descrito, que se conoce desde hace mucho tiempo (Go, Rust, C++, Ruby) y no se toma en serio. . Según Cox, el problema se refiere principalmente a la visualización correcta de la información en los editores de código y las interfaces web, lo que puede resolverse utilizando las herramientas y analizadores de código adecuados durante la revisión. Por lo tanto, en lugar de llamar la atención sobre ataques especulativos, sería más apropiado centrarse en mejorar el código y los procesos de revisión de dependencias.
Ras Cox también cree que los compiladores no son el lugar adecuado para solucionar el problema, ya que al prohibir los símbolos peligrosos a nivel del compilador, queda una enorme capa de herramientas en las que el uso de estos símbolos sigue siendo aceptable, como sistemas de compilación, ensambladores, administradores de paquetes y varios analizadores de configuración y datos. Como ejemplo, se da el proyecto Rust, que prohibió el procesamiento de código LTR/RTL en el compilador, pero no agregó una solución al administrador de paquetes Cargo, que permite un ataque similar a través del archivo Cargo.toml. Del mismo modo, archivos como BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml y requisitos.txt pueden convertirse en fuentes de ataques.
Fuente: opennet.ru