Trojan Source napad radi uvođenja promjena u kodu koje su nevidljive programeru

Istraživači sa Univerziteta Kembridž objavili su tehniku ​​za tiho umetanje zlonamernog koda u recenzirani izvorni kod. Pripremljena metoda napada (CVE-2021-42574) predstavljena je pod nazivom Trojan Source i zasnovana je na formiranju teksta koji izgleda drugačije za kompajlera/interpreatora i osobu koja gleda kod. Primeri metode su demonstrirani za različite kompajlere 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 zasniva na upotrebi posebnih Unicode znakova u komentarima koda koji mijenjaju redoslijed prikaza dvosmjernog teksta. Uz pomoć ovakvih kontrolnih znakova, neki dijelovi teksta mogu se prikazati s lijeva na desno, dok drugi - s desna na lijevo. U svakodnevnoj praksi, takvi kontrolni znakovi se mogu koristiti, na primjer, za umetanje linija koda na hebrejskom ili arapskom u datoteku. Ali ako kombinirate redove s različitim smjerovima teksta u jednom redu, koristeći određene znakove, odlomci teksta prikazani s desna na lijevo mogu se preklapati postojeći obični tekst prikazan s lijeva na desno.

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

Trojan Source napad radi uvođenja promjena u kodu koje su nevidljive programeru

Tokom pregleda koda, programer će se suočiti sa vizuelnim redosledom znakova i videće nesumnjiv komentar u modernom uređivaču teksta, web interfejsu ili IDE, ali će kompajler i interpretator koristiti logički redosled znakova i obraditi zlonamjerno umetanje kakav jest, ne obraćajući pažnju na dvosmjerni tekst u komentarima. Problem pogađa različite popularne uređivače koda (VS Code, Emacs, Atom), kao i interfejse za pregled koda u repozitorijumima (GitHub, Gitlab, BitBucket i svi Atlassian proizvodi).

Trojan Source napad radi uvođenja promjena u kodu koje su nevidljive programeru

Postoji nekoliko načina da se metoda koristi za implementaciju zlonamjernih radnji: dodavanje skrivenog izraza „povratak“, što dovodi do završetka funkcije prije vremena; komentarisanje izraza koji bi normalno bili vidljivi kao valjani konstrukti (na primjer, za onemogućavanje važnih provjera); dodjeljivanje drugih vrijednosti niza koje dovode do neuspjeha validacije niza.

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

koji će biti prikazan u interfejsu za pregled kao da je access_level != “user” { // Provjeri da li je admin

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

Trojan Source napad radi uvođenja promjena u kodu koje su nevidljive programeru

Kao sigurnosna mjera, preporučuje se da prevodioci, interpretatori i alati za sklapanje koji podržavaju Unicode znakove prikažu grešku ili upozorenje ako postoje neupareni kontrolni znakovi u komentarima, literalima niza 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 znakovi bi 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 spremišta.

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

Dodatak 2: Russ Cox, jedan od programera Plan 9 OS i programskog jezika Go, kritizirao je pretjeranu pažnju prema opisanoj metodi napada, koja je odavno poznata (Go, Rust, C++, Ruby) i nije shvaćana ozbiljno . Prema Coxu, problem se uglavnom odnosi na ispravan prikaz informacija u uređivačima koda i web interfejsima, što se može riješiti korištenjem ispravnih alata i analizatora koda tokom pregleda. Stoga, umjesto skretanja pažnje na spekulativne napade, bilo bi primjerenije fokusirati se na poboljšanje koda i procesa pregleda ovisnosti.

Ras Cox također smatra da kompajleri nisu pravo mjesto za rješavanje problema, jer zabranom opasnih simbola na nivou kompajlera ostaje ogroman sloj alata u kojima upotreba ovih simbola ostaje prihvatljiva, kao što su build sistemi, asembleri, menadžeri paketa i razni analizatori konfiguracija i podaci. Kao primjer dat je projekat Rust, koji je zabranio obradu LTR/RTL koda u kompajleru, ali nije dodao ispravku u Cargo paket menadžer, koji omogućava sličan napad preko datoteke Cargo.toml. Slično, fajlovi 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