Investigadors de la Universitat de Cambridge han publicat una tècnica per inserir silenciosament codi maliciós al codi font revisat per parells. El mètode d'atac preparat (CVE-2021-42574) es presenta amb el nom Trojan Source i es basa en la formació de text que sembla diferent per al compilador/intèrpret i la persona que visualitza el codi. Es mostren exemples del mètode per a diversos compiladors i intèrprets subministrats per a C, C++ (gcc i clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go i Python.
El mètode es basa en l'ús de caràcters especials Unicode als comentaris del codi que canvien l'ordre de visualització del text bidireccional. Amb l'ajuda d'aquests caràcters de control, algunes parts del text es poden mostrar d'esquerra a dreta, mentre que altres, de dreta a esquerra. A la pràctica quotidiana, aquests caràcters de control es poden utilitzar, per exemple, per inserir línies de codi en hebreu o àrab en un fitxer. Però si combineu línies amb diferents direccions de text en una línia, utilitzant els caràcters especificats, els passatges de text que es mostren de dreta a esquerra poden superposar-se al text normal existent que es mostra d'esquerra a dreta.
Mitjançant aquest mètode, podeu afegir una construcció maliciosa al codi, però després fer que el text amb aquesta construcció sigui invisible quan visualitzeu el codi, afegint al següent comentari o dins dels caràcters literals que es mostren de dreta a esquerra, cosa que donarà lloc a diferents caràcters que es superposen a la inserció maliciosa. Aquest codi es mantindrà semànticament correcte, però s'interpretarà i es mostrarà de manera diferent.
Mentre revisa el codi, un desenvolupador s'enfrontarà a l'ordre visual dels caràcters i veurà un comentari no sospitós en un editor de text, interfície web o IDE modern, però el compilador i l'intèrpret utilitzaran l'ordre lògic dels caràcters i processar la inserció maliciosa tal com és, sense parar atenció al text bidireccional dels comentaris. El problema afecta diversos editors de codi populars (VS Code, Emacs, Atom), així com interfícies per visualitzar codi als repositoris (GitHub, Gitlab, BitBucket i tots els productes Atlassian).
Hi ha diverses maneres d'utilitzar el mètode per implementar accions malicioses: afegint una expressió "retorn" oculta, que condueix a la finalització de la funció abans d'hora; comentar expressions que normalment serien visibles com a construccions vàlides (per exemple, per desactivar comprovacions importants); assignant altres valors de cadena que condueixin a errors de validació de cadena.
Per exemple, un atacant podria proposar un canvi que inclogui la línia: if access_level != "usuari{U+202E} {U+2066}// Comproveu si admin{U+2069} {U+2066}" {
que es mostrarà a la interfície de revisió com si access_level != "usuari" { // Comproveu si admin
Addicionalment, s'ha proposat una altra variant d'atac (CVE-2021-42694), associada a l'ús d'homoglifs, caràcters d'aparença semblant, però de significat diferent i amb codis unicode diferents (per exemple, el caràcter “ɑ” s'assembla a “ a", "ɡ" - "g", "ɩ" - "l"). En alguns idiomes es poden utilitzar caràcters similars en els noms de funcions i variables per enganyar els desenvolupadors. Per exemple, es poden definir dues funcions amb noms indistinguibles que realitzen accions diferents. Sense una anàlisi detallada, no queda clar immediatament quina d'aquestes dues funcions s'anomena en un lloc concret.
Com a mesura de seguretat, es recomana que els compiladors, intèrprets i eines de muntatge que admeten caràcters Unicode mostrin un error o un avís si hi ha caràcters de control no aparellats als comentaris, literals de cadena o identificadors que canvien la direcció de sortida (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E i U+200F). Aquests caràcters també s'han de prohibir explícitament a les especificacions del llenguatge de programació i s'han de respectar als editors de codi i a les interfícies de repositoris.
Addendum 1: S'han preparat pedaços de vulnerabilitat per a GCC, LLVM/Clang, Rust, Go, Python i binutils. GitHub, Bitbucket i Jira també van solucionar el problema. Hi ha una solució per a GitLab. Per identificar el codi problemàtic, es recomana utilitzar l'ordre: 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]' font
Addendum 2: Russ Cox, un dels desenvolupadors del sistema operatiu Plan 9 i del llenguatge de programació Go, va criticar l'atenció excessiva al mètode d'atac descrit, que fa temps que es coneix (Go, Rust, C++, Ruby) i no es va prendre seriosament. . Segons Cox, el problema es refereix principalment a la visualització correcta de la informació en editors de codi i interfícies web, que es pot resoldre mitjançant l'ús de les eines i analitzadors de codi correctes durant la revisió. Per tant, en comptes de cridar l'atenció sobre els atacs especulatius, seria més adequat centrar-se en la millora dels processos de revisió de codi i dependències.
Ras Cox també creu que els compiladors no són el lloc adequat per solucionar el problema, ja que en prohibir els símbols perillosos a nivell de compilador, queda una gran capa d'eines en què l'ús d'aquests símbols segueix sent acceptable, com ara sistemes de compilació, assembladors, etc. gestors de paquets i diversos analitzadors i dades de configuració. Com a exemple, es posa el projecte Rust, que prohibia el processament del codi LTR/RTL al compilador, però no afegeix cap solució al gestor de paquets Cargo, que permet un atac similar a través del fitxer Cargo.toml. De la mateixa manera, fitxers com BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml i requirements.txt poden convertir-se en fonts d'atac.
Font: opennet.ru