Kërkuesit nga Universiteti i Kembrixhit publikuan një teknike të padukshme për të futur kod malware në kodin burimor të rishikuar. Metoda e përgatitur e sulmit (CVE-2021-42574) paraqitet me emrin Trojan Source dhe bazohet në krijimin e tekstit që duket ndryshe për kompilatorin/interpretuesin dhe njeriun që shikon kodin. Shembuj të përdorimit të metodës janë demonstruar për kompilerë dhe interpretues të ndryshëm, të ofruar për gjuhët C, C++ (gcc dhe clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go dhe Python.
Metoda bazohet në përdorimin e karaktereve speciale Unicode në komentet e kodit që ndryshojnë rendin e shfaqjes së teksteve me drejtim të dyfishtë. Me ndihmën e këtyre simboleve udhëzuese, disa pjesë të tekstit mund të shfaqen nga majtas në djathtas, ndërsa pjesë të tjera nga djathta në majtas. Në praktikën përditshme, këto simbole udhëzuese mund të përdoren, për shembull, për të futur në një skedar kodi rreshta në hebraisht ose arabisht. Por nëse kombinohen rreshta me drejtime të ndryshme në një rresht, me ndihmën e simboleve të përmendura, copat e tekstit të shfaqura nga djathta në majtas mund të mbulojnë tekstin normal që shfaqet nga majtas në djathtas.
Duke përdorur këtë metodë, në kod mund të shtohet një konstruksion i dëmshëm, por pastaj të bëhet teksti me këtë konstrukcion të padukshëm gjatë rishikimit të kodit, përmes shtimit në një koment që vjen pas tij ose brenda literalit të simboleve që shfaqen nga djathta në majtas, gjë që do të çonte në mbulimin e injeksionit të dëmshëm me simbole të tjera. Ky kod do të mbetet semantikisht korrekt, por do të interpretohet dhe shfaqet ndryshe.

Gjatë shqyrtimit të kodit, programuesi mund të ndeshet me renditjen vizuale të karaktereve dhe të shohë në një editor modern, web-interfejs apo IDE një koment të padashur. Megjithatë, kompajleri dhe interpretuese do të përdorin renditjen logjike të karaktereve dhe do të trajtojnë insertimin e dëmshëm ashtu siç është, pa marrë parasysh tekstin me dy drejtim në koment. Problemi është i prirur në shumë redaktues të njohur të kodit (VS Code, Emacs, Atom), si dhe në ndërfaqet për shikimin e kodit në depo (GitHub, Gitlab, BitBucket dhe të gjitha produktet Atlassian).

Ekzistojnë disa mënyra për të përdorur metodën për të realizuar veprime të dëmshme: shtimi i shprehjes së fshehtë "return", e cila çon në përfundimin e ekzekutimit të funksionit para kohe; vendosja në koment të shprehjeve që duket normalisht si konstruksione aktive (për shembull, për të çaktivizuar kontrolle të rëndësishme); caktimi i vlerave të tjera string që çojnë në dështimin e kontrolleve të stringjeve.
Për shembull, një sulmues mund të propozojë një ndryshim që përfshin rreshtin: if access_level != "user{U+202E} {U+2066}// Kontrolloni nëse është admin{U+2069} {U+2066}" {"}
e cila do të shfaqet në ndërfaqe për rishikim si if access_level != «user» { // Kontrollo nëse admin
PĂ«rveç kĂ«saj, Ă«shtĂ« propozuar njĂ« variant tjetĂ«r sulmi (CVE-2021-42694), i lidhur me pĂ«rdorimin e omoglifĂ«ve, simboleve qĂ« duken tĂ« ngjashme nĂ« pamje, por ndahen nĂ« kuptim dhe kanĂ« kode tĂ« ndryshme unicode (pĂ«r shembull, simboli «É» ngjan me «a», «ɥ» â «g», «ɩ» â «l»). Simbole tĂ« tilla mund tĂ« pĂ«rdoren nĂ« disa gjuhĂ« nĂ« emrat e funksioneve dhe variablave pĂ«r tĂ« mashtruar zhvilluesit. PĂ«r shembull, mund tĂ« pĂ«rcaktohen dy funksione me emra tĂ« pabesueshĂ«m, qĂ« kryejnĂ« veprime tĂ« ndryshme. Pa njĂ« analizĂ« tĂ« detajuar, nuk mund tĂ« kuptohet menjĂ«herĂ« se cili nga kĂ«to dy funksione thirret nĂ« njĂ« vend tĂ« caktuar.

Si masë mbrojtjeje, rekomandohet të implementohet në kompajlerët, interpretorët dhe mjetet e ndërtimit që mbështesin simbolet Unicode, një dalje gabimi ose paralajmërimi në rastin e pranishmërisë së simboleve të kontrollit të çiftë, që ndryshojnë drejtimin e daljes (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E dhe U+200F). Këto simbole gjithashtu duhet të ndalohen qartë në specifikimet e gjuhëve të programimit dhe duhet të merren parasysh në redaktorët e kodit dhe ndërfaqet për punën me depozita.
Shtesa 1: Korrigjimet për eliminimin e vulnerabilitetit janë përgatitur për GCC, LLVM/Clang, Rust, Go, Python dhe binutils. Problemi është gjithashtu rregulluar nga GitHub, Bitbucket dhe Jira. Aktualisht po përgatitet një korrigjim për GitLab. Për identifikimin e kodit problematik, sugjerohet të përdoret komandë: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Shtesa 2: Russ Cox, një nga zhvilluesit e sistemit operativ Plan 9 dhe gjuhës së programimit Go, kritikoi vëmendjen e tepruar ndaj metodës së sulmit të përshkruar, e cila është njohur prej kohësh (Go, Rust, C++, Ruby) dhe nuk është marrë seriozisht. Sipas Cox, problemi kryesor ka të bëjë me saktësinë e paraqitjes së informacionit në redaktorët e kodit dhe në ndërfaqet web, dhe zgjidhet duke përdorur mjete dhe analizues të saktë gjatë rishikimit. Prandaj, përveç tërheqjes së vëmendjes ndaj sulmeve konjukturale, do të ishte më e arsyeshme të fokusoheshim në përmirësimin e proceseve të rishikimit të kodit dhe varësive.
Ras Koks gjithashtu mendon se kompilatorët nuk janë vendi ku duhet të zgjidhet problemi, pasi ndalimi i simboleve të rrezikshme në nivelin e kompilatorit lë një sasi të madhe mjetesh ku përdorimi i këtyre simboleve mbetet i lejueshëm, të tilla si sistemet e ndërtimit, assemblerët, menaxherët e paketave dhe disa parsera të konfigurimeve dhe të dhënave. Si shembull, projekti Rust, i cili ndalon përpunimin e kodit LTR/RTL në kompilator, por nuk ka shtuar një zgjidhje në menaxherin e paketave Cargo, çka lejon të bëhet një sulm i ngjashëm përmes skedarit Cargo.toml. Po ashtu, skedarët si BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml dhe requirements.txt mund të jenë burime sulmi.
Burimi: opennet.ru
