Studiuesit nga Universiteti i Kembrixhit kanë publikuar një teknikë për futjen në heshtje të kodit me qëllim të keq në kodin burimor të rishikuar nga kolegët. Metoda e përgatitur e sulmit (CVE-2021-42574) paraqitet me emrin Trojan Source dhe bazohet në formimin e tekstit që duket i ndryshëm për përpiluesin/interpretuesin dhe personin që shikon kodin. Shembuj të metodës janë demonstruar për përpilues dhe interpretues të ndryshëm të ofruar për C, C++ (gcc dhe clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go dhe Python.
Metoda bazohet në përdorimin e karaktereve speciale të Unicode në komentet e kodit që ndryshojnë rendin e shfaqjes së tekstit me dy drejtime. Me ndihmën e karaktereve të tilla të kontrollit, disa pjesë të tekstit mund të shfaqen nga e majta në të djathtë, ndërsa të tjerat - nga e djathta në të majtë. Në praktikën e përditshme, karaktere të tilla kontrolli mund të përdoren, për shembull, për të futur linja kodi në hebraisht ose arabisht në një skedar. Por nëse kombinoni rreshta me drejtime të ndryshme teksti në një rresht, duke përdorur karakteret e specifikuara, pjesët e tekstit të shfaqura nga e djathta në të majtë mund të mbivendosen tekstin ekzistues të rregullt të shfaqur nga e majta në të djathtë.
Duke përdorur këtë metodë, mund të shtoni një konstrukt me qëllim të keq në kod, por më pas ta bëni tekstin me këtë konstrukt të padukshëm kur shikoni kodin, duke shtuar në komentin e mëposhtëm ose brenda karaktereve të mirëfillta të treguara nga e djathta në të majtë, gjë që do të çojë në plotësisht karaktere të ndryshme duke u mbivendosur në futjen me qëllim të keq. Një kod i tillë do të mbetet i saktë semantikisht, por do të interpretohet dhe shfaqet ndryshe.
Gjatë rishikimit të kodit, një zhvillues do të përballet me rendin vizual të personazheve dhe do të shohë një koment jo të dyshimtë në një redaktues teksti modern, ndërfaqe në internet ose IDE, por përpiluesi dhe interpretuesi do të përdorin rendin logjik të karaktereve dhe do të përpunoni futjen me qëllim të keq siç është, pa i kushtuar vëmendje tekstit të dyanshëm në komente. Problemi prek redaktuesit e ndryshëm të njohur të kodit (VS Code, Emacs, Atom), si dhe ndërfaqet për shikimin e kodit në depo (GitHub, Gitlab, BitBucket dhe të gjitha produktet Atlassian).
Ka disa mënyra për të përdorur metodën për të zbatuar veprime me qëllim të keq: shtimi i një shprehjeje "kthimi" të fshehur, e cila çon në përfundimin e funksionit para kohe; komentimi i shprehjeve që normalisht do të ishin të dukshme si konstruksione të vlefshme (për shembull, për të çaktivizuar kontrolle të rëndësishme); caktimi i vlerave të tjera të vargut që çojnë në dështime të vërtetimit të vargut.
Për shembull, një sulmues mund të propozojë një ndryshim që përfshin rreshtin: if access_level != "user{U+202E} {U+2066}// Kontrollo nëse admin{U+2069} {U+2066}" {
e cila do të shfaqet në ndërfaqen e rishikimit sikur access_level != "user" { // Kontrolloni nëse admin
Për më tepër, është propozuar një variant tjetër sulmi (CVE-2021-42694), i lidhur me përdorimin e homoglifeve, karaktere që janë të ngjashëm në pamje, por ndryshojnë në kuptim dhe kanë kode të ndryshme unicode (për shembull, karakteri "ɑ" i ngjan " a", "ɡ" - "g", "ɩ" - "l"). Karaktere të ngjashme 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ë padallueshëm që kryejnë veprime të ndryshme. Pa një analizë të hollësishme, nuk është menjëherë e qartë se cili nga këto dy funksione quhet në një vend të caktuar.
Si masë sigurie, rekomandohet që përpiluesit, interpretuesit dhe mjetet e montimit që mbështesin karakteret Unicode të shfaqin një gabim ose paralajmërim nëse ka karaktere kontrolli të paçiftuara në komente, literale vargjesh ose identifikues 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). Karaktere të tilla duhet gjithashtu të ndalohen në mënyrë eksplicite në specifikimet e gjuhës së programimit dhe duhet të respektohen në redaktuesit e kodit dhe ndërfaqet e depove.
Shtojca 1: Arnimet e dobësisë janë përgatitur për GCC, LLVM/Clang, Rust, Go, Python dhe binutils. GitHub, Bitbucket dhe Jira gjithashtu e rregulluan problemin. Një rregullim për GitLab është në proces. Për të identifikuar kodin problematik, sugjerohet të përdorni komandën: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069\uXNUMX\uXNUMX/uXNUMX/' burimi
Shtojca 2: Russ Cox, një nga zhvilluesit e Planit 9 OS dhe gjuhës programuese Go, kritikoi vëmendjen e tepërt ndaj metodës së sulmit të përshkruar, e cila ka qenë prej kohësh e njohur (Go, Rust, C++, Ruby) dhe nuk u mor seriozisht . Sipas Cox, problemi ka të bëjë kryesisht me shfaqjen e saktë të informacionit në redaktuesit e kodit dhe ndërfaqet në ueb, të cilat mund të zgjidhen duke përdorur mjetet e duhura dhe analizuesit e kodit gjatë rishikimit. Prandaj, në vend që të tërhiqni vëmendjen ndaj sulmeve spekulative, do të ishte më e përshtatshme të fokusoheshim në përmirësimin e proceseve të shqyrtimit të kodit dhe varësisë.
Ras Cox beson gjithashtu se përpiluesit nuk janë vendi i duhur për të rregulluar problemin, pasi duke ndaluar simbolet e rrezikshme në nivelin e kompajlerit, mbetet një shtresë e madhe mjetesh në të cilat përdorimi i këtyre simboleve mbetet i pranueshëm, siç janë sistemet e ndërtimit, montuesit, menaxherët e paketave dhe analizuesit dhe të dhënat e ndryshme të konfigurimit. Si shembull, jepet projekti Rust, i cili ndaloi përpunimin e kodit LTR/RTL në përpilues, por nuk shtoi një rregullim në menaxherin e paketave Cargo, i cili lejon një sulm të ngjashëm përmes skedarit Cargo.toml. Në mënyrë të ngjashme, skedarë të tillë si BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml dhe kërkesat.txt mund të bëhen burime sulmesh.
Burimi: opennet.ru