Cercetătorii de la Universitatea Cambridge au publicat o tehnică de inserție invizibilă a codului malițios în textele originale supuse revizuirii. Metoda de atac pregătită (CVE-2021-42574) este denumită Trojan Source și se bazează pe formarea unui text care arată diferit pentru compilatorul/interpretorul care îl procesează și pentru persoana care vizualizează codul. Exemplele de aplicare a metodei sunt demonstrate pentru diferite compilatoare și interpretoare disponibile pentru limbajele C, C++ (gcc și clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go și Python.
Metoda se bazează pe utilizarea unor simboluri Unicode speciale în comentariile de cod, care schimbă ordinea de afișare a textului bidirecțional. Prin utilizarea acestor simboluri de control, unele părți ale textului pot fi afișate de la stânga la dreapta, iar altele de la dreapta la stânga. În practică, aceste simboluri de control pot fi folosite, de exemplu, pentru inserarea în fișierele de cod a unor linii în ebraică sau arabă. Însă, dacă se combină linii cu direcții diferite de text într-o singură linie, folosind aceste simboluri, fragmentele de text afișate de la dreapta la stânga pot suprapune textul normal, afișat de la stânga la dreapta.
Folosind această metodă, se poate adăuga o construcție malițioasă în cod, dar apoi textul cu această construcție poate fi făcut invizibil la vizualizarea codului, prin adăugarea în comentariul următor sau în interiorul unui literl a simbolurilor afișate de la dreapta la stânga, ceea ce va duce la suprapunerea pe inserția malițioasă a unor simboluri complet diferite. Codul similar va rămâne semnificativ corect, dar va fi interpretat și afișat diferit.
În timpul revizuirii codului, dezvoltatorul se va confrunta cu ordinea vizuală de afișare a caracterelor și va observa într-un editor de text modern, interfață web sau IDE un comentariu care nu ridică suspiciuni, dar compilatorul și interpretul vor folosi ordinea logică a caracterelor și vor procesa inserția malițioasă ca atare, neacordând atenție textului bidirecțional din comentarii. Problema afectează diverse editoare de cod populare (VS Code, Emacs, Atom), precum și interfețele pentru vizualizarea codului în repozitorii (GitHub, Gitlab, BitBucket și toate produsele Atlassian).
Sunt evidențiate mai multe metode de utilizare a metodei pentru a desfășura acțiuni malițioase: adăugarea unei expresii ascunse «return», care duce la finalizarea execuției funcției prematur; ascunderea în comentarii a expresiilor, care în mod normal sunt vizibile ca structuri active (de exemplu, pentru a dezactiva verificări importante); atribuirea de alte valori string care duc la eșecul verificării string-urilor.
De exemplu, atacatorul ar putea propune o modificare care include linia: if access_level != «user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}» {
care va fi afișată în interfața de revizuire ca if access_level != «user» { // Check if admin
În plus, a fost propusă o altă variantă de atac (CVE-2021-42694), legată de utilizarea omoglifelor, simboluri care par identice ca aspect, dar diferă în semnificație și au coduri unicode diferite (de exemplu, simbolul «ɑ» seamănă cu «a», «ɡ» — cu «g», «ɩ» — cu «l»). Aceste simboluri pot fi utilizate în anumite limbaje pentru a induce în eroare dezvoltatorii cu privire la numele funcțiilor și variabilelor. De exemplu, pot fi definite două funcții cu nume indistinguibile care execută acțiuni diferite. Fără o analiză detaliată, nu se va înțelege imediat care dintre aceste două funcții este apelată într-un anumit loc.
Ca măsură de protecție, se recomandă implementarea în compilatoare, interpretoare și instrumente de construcție care suportă simboluri Unicode, a unui mesaj de eroare sau avertisment atunci când există în comentarii, literale string sau identificatori simboluri de control impare care schimbă direcția de ieșire (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). Aceste simboluri ar trebui să fie, de asemenea, explicit interzise în specificațiile limbajelor de programare și să fie luate în considerare în editorii de cod și interfețele de lucru cu repozitoarele.
Adăugare 1: Corecțiile pentru eliminarea vulnerabilității au fost pregătite pentru GCC, LLVM/Clang, Rust, Go, Python și binutils. Problema a fost rezolvată și de GitHub, Bitbucket și Jira. Se lucrează la pregătirea corecției pentru GitLab. Pentru a identifica codul problematic, s-a propus utilizarea comenzii: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Supplement 2: Russ Cox, one of the developers of the Plan 9 operating system and the Go programming language, criticized the excessive attention paid to the described attack method, which has long been known (Go, Rust, C++, Ruby) and was not taken seriously. In Cox's opinion, the problem primarily concerns the accurate display of information in code editors and web interfaces, and can be addressed through the use of proper tools and code analyzers during reviews. Therefore, rather than drawing attention to hypothetical attacks, it would be more appropriate to focus on improving the processes of code and dependency reviews.
Russ Cox also believes that compilers are not the right place to address this issue, as banning dangerous characters at the compiler level leaves a huge range of tools where the use of these characters remains permissible, such as build systems, assemblers, package managers, and various data and configuration parsers. For example, the Rust project banned the processing of LTR/RTL code in the compiler but did not implement a fix in the Cargo package manager, allowing for a similar attack through the Cargo.toml file. Similarly, sources of attacks can include files such as BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml, and requirements.txt.
Sursa: opennet.ro
