Acum cateva zile Cercetătorii de la Universitatea Cambridge au lansat publicarea o tehnică de substituire subtilă a codurilor rău intenționat în codul sursă al aplicației.
Metoda de atac a pregătit asta Este deja listat sub CVE-2021-42574 Vine sub numele Trojan Source și se bazează pe formarea unui text care arată diferit de compilator/interpret și de persoana care vizualizează codul.
Despre Trojan Source
Metoda se bazează pe aplicarea caracterelor speciale Unicode în comentariile de cod, care modifică ordinea de afișare a textului bidirecțional. Cu ajutorul acestor personaje de control, unele părți ale textului pot fi afișate de la stânga la dreapta, în timp ce altele de la dreapta la stânga.
În practica de zi cu zi, aceste caractere de control pot fi folosite, de exemplu, pentru a insera șiruri de caractere ebraice sau arabe într-un fișier de cod. Cu toate acestea, dacă utilizați aceste caractere pentru a combina linii cu direcții diferite de text pe aceeași linie, pasajele de text afișate de la dreapta la stânga se pot suprapune textului normal existent afișat de la stânga la dreapta.
Cu această metodă, un construct rău intenționat poate fi adăugat la cod, dar apoi faceți textul cu această construcție invizibil atunci când vizualizați codul, adăugând caracterele afișate de la dreapta la stânga în următorul comentariu sau în interiorul literalului, ceea ce va avea ca rezultat un rezultat de caractere complet diferite suprapuse pe inserția rău intenționată. Un astfel de cod va fi în continuare corect din punct de vedere semantic, dar va fi interpretat și afișat diferit.
Am descoperit modalități de a manipula codificarea fișierelor de cod sursă, astfel încât utilizatorii și compilatorii să vadă o logică diferită. O metodă deosebit de pernicioasă folosește caractere de suprascriere a direcționalității Unicode pentru a afișa codul ca o anagramă a adevăratei sale logici. Am verificat că acest atac funcționează împotriva C, C ++, C #, JavaScript, Java, Rust, Go și Python și bănuim că va funcționa împotriva majorității altor limbaje moderne.
În timpul examinării codului, dezvoltatorul se va confrunta cu ordinea vizuală a personajelor și va vedea un comentariu suspect într-un editor text, interfață web sau IDE, dar compilatorul și interpretul vor folosi ordinea logică a caracterelor și vor gestiona codul rău intenționat așa cum este, indiferent de textul bidirecțional din comentariu. Mai multe editori de cod populari (VS Code, Emacs, Atom), precum și interfețele pentru vizualizarea codului în depozite (GitHub, Gitlab, BitBucket și toate produsele Atlassian) sunt afectate.
Există mai multe modalități de a folosi metoda pentru a implementa acțiuni rău intenționate: adăugați o expresie "return" ascunsă, care duce la terminarea prematură a execuției funcției; concluzia în comentariu a expresiilor care sunt în mod normal considerate constructe valide (de exemplu, pentru a dezactiva verificările importante); atribuirea altor valori de șir care duc la eșecuri de validare a șirurilor.
În plus, a fost propusă o altă opțiune de atac (CVE-2021-42694), care implică utilizarea de homoglife, simboluri care apar similare ca aspect, dar diferă ca semnificație și au coduri Unicode diferite. Aceste caractere pot fi folosite în unele limbi în nume de funcții și variabile pentru a induce în eroare dezvoltatorii. De exemplu, puteți defini două funcții cu nume care nu se pot distinge care efectuează acțiuni diferite. Fără o analiză detaliată, nu puteți înțelege imediat care dintre aceste două funcții este numită într-un anumit loc.
Ca măsură de protecție, se recomandă implementarea în compilatoare, interprete și instrumente de asamblare care acceptă caractere Unicode, arătând o eroare sau avertisment indiferent dacă există caractere de control nepereche în comentarii, literale șir sau identificatori care schimbă direcția de ieșire. Aceste caractere trebuie de asemenea interzise în mod explicit în specificațiile limbajului de programare și trebuie luate în considerare în editorii de cod și interfețele pentru lucrul cu depozitele.
Pe lângă asta vulnerabilitățile au început deja să fie remediate pregătit pentru GCC, LLVM / Clang, Rust, Go, Python și binutils. GitHub, Bitbucket și Jira sunt deja în pregătire pentru o soluție împreună cu GitLab.
În cele din urmă Dacă sunteți interesat să aflați mai multe despre asta, puteți consulta detaliile din următorul link.