Trojanski izvorni napad za uvođenje promjena u kod koje su nevidljive programeru

Istraživači sa Sveučilišta Cambridge objavili su tehniku ​​za tiho umetanje zlonamjernog koda u recenzirani izvorni kod. Pripremljena metoda napada (CVE-2021-42574) predstavljena je pod imenom Trojan Source i temelji se na formiranju teksta koji izgleda različito za kompajlera/interpretera i za osobu koja gleda kod. Primjeri metode demonstrirani su za različite prevoditelje i tumače koji se isporučuju za C, C++ (gcc i clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go i Python.

Metoda se temelji na korištenju posebnih Unicode znakova u komentarima koda koji mijenjaju redoslijed prikaza dvosmjernog teksta. Uz pomoć takvih kontrolnih znakova, neki dijelovi teksta mogu se prikazati slijeva na desno, dok drugi - s desna na lijevo. U svakodnevnoj praksi takvi se kontrolni znakovi mogu koristiti, na primjer, za umetanje linija koda na hebrejskom ili arapskom u datoteku. Ali ako kombinirate retke s različitim smjerovima teksta u jednom retku, koristeći navedene znakove, odlomci teksta prikazani s desna na lijevo mogu se preklapati s postojećim uobičajenim tekstom prikazanim slijeva na desno.

Koristeći ovu metodu, možete dodati zlonamjernu konstrukciju kodu, ali zatim učiniti tekst s tom konstrukcijom nevidljivim pri gledanju koda, dodavanjem u sljedeći komentar ili unutar doslovnih znakova prikazanih s desna na lijevo, što će dovesti do potpunog različiti znakovi koji se nadmeću na zlonamjerno umetanje. Takav kod će ostati semantički ispravan, ali će se drugačije tumačiti i prikazati.

Trojanski izvorni napad za uvođenje promjena u kod koje su nevidljive programeru

Dok pregledava kod, programer će se suočiti s vizualnim redoslijedom znakova i vidjet će nesumnjiv komentar u modernom uređivaču teksta, web sučelju ili IDE-u, ali kompajler i tumač koristit će logički redoslijed znakova i obraditi zlonamjerno umetanje kakvo jest, bez obraćanja pozornosti na dvosmjerni tekst u komentarima. Problem utječe na razne popularne uređivače koda (VS Code, Emacs, Atom), kao i na sučelja za pregled koda u spremištima (GitHub, Gitlab, BitBucket i svi Atlassian proizvodi).

Trojanski izvorni napad za uvođenje promjena u kod koje su nevidljive programeru

Postoji nekoliko načina korištenja metode za provedbu zlonamjernih radnji: dodavanje skrivenog izraza "povratak", što dovodi do završetka funkcije prije vremena; komentiranje izraza koji bi inače bili vidljivi kao valjani konstrukti (na primjer, za onemogućavanje važnih provjera); dodjeljivanje drugih vrijednosti niza koje dovode do neuspjeha provjere niza.

Na primjer, napadač može predložiti promjenu koja uključuje redak: if access_level != "user{U+202E} {U+2066}// Provjerite je li admin{U+2069} {U+2066}" {

koji će biti prikazan u sučelju pregleda kao da access_level != “user” { // Provjerite je li admin

Osim toga, predložena je još jedna varijanta napada (CVE-2021-42694), povezana s upotrebom homoglifa, znakova koji su slični izgledom, ali se razlikuju u značenju i imaju različite unicode kodove (na primjer, znak "ɑ" nalikuje " a”, “ɡ” - “g”, “ɩ” - “l”). Slični znakovi mogu se koristiti u nekim jezicima u imenima funkcija i varijabli kako bi se programeri doveli u zabludu. Na primjer, mogu se definirati dvije funkcije s nerazlučivim nazivima koje izvode različite radnje. Bez detaljne analize nije odmah jasno koja se od ove dvije funkcije poziva na određenom mjestu.

Trojanski izvorni napad za uvođenje promjena u kod koje su nevidljive programeru

Kao sigurnosna mjera, preporučuje se da prevoditelji, tumači i alati za asembler koji podržavaju Unicode znakove prikažu pogrešku ili upozorenje ako postoje neupareni kontrolni znakovi u komentarima, literalnim nizovima ili identifikatorima koji mijenjaju smjer izlaza (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). Takvi bi znakovi također trebali biti izričito zabranjeni u specifikacijama programskog jezika i trebali bi se poštovati u uređivačima koda i sučeljima repozitorija.

Dodatak 1: Zakrpe ranjivosti pripremljene su za GCC, LLVM/Clang, Rust, Go, Python i binutils. GitHub, Bitbucket i Jira također su riješili problem. U tijeku je popravak za GitLab. Za identifikaciju problematičnog koda predlaže se korištenje naredbe: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ izvor

Dodatak 2: Russ Cox, jedan od developera Plan 9 OS-a i programskog jezika Go, kritizirao je pretjeranu pozornost prema opisanoj metodi napada koja je odavno poznata (Go, Rust, C++, Ruby) i nije shvaćana ozbiljno . Prema Coxu, problem se uglavnom odnosi na točan prikaz informacija u uređivačima koda i web sučeljima, što se može riješiti korištenjem ispravnih alata i analizatora koda tijekom pregleda. Stoga, umjesto privlačenja pozornosti na spekulativne napade, bilo bi primjerenije usredotočiti se na poboljšanje procesa pregleda koda i ovisnosti.

Ras Cox također smatra da kompajleri nisu pravo mjesto za rješavanje problema, budući da zabranom opasnih simbola na razini kompajlera ostaje ogroman sloj alata u kojima upotreba tih simbola ostaje prihvatljiva, kao što su sustavi za izgradnju, asembleri, upravitelji paketa i razni konfiguracijski parseri i podaci. Kao primjer je naveden projekt Rust koji je zabranio obradu LTR/RTL koda u kompajleru, ali nije dodao popravak za Cargo package manager koji omogućuje sličan napad preko datoteke Cargo.toml. Slično tome, datoteke kao što su BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml i requirements.txt mogu postati izvori napada.

Izvor: opennet.ru

Dodajte komentar